From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 04:19:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0786116A4BF for ; Fri, 22 Aug 2003 04:19:39 -0700 (PDT) Received: from hysteria.spc.org (hysteria.spc.org [195.206.69.234]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BEF443FB1 for ; Fri, 22 Aug 2003 04:19:37 -0700 (PDT) (envelope-from bms@hysteria.spc.org) Received: (qmail 18686 invoked by uid 5013); 22 Aug 2003 11:16:36 -0000 Date: Fri, 22 Aug 2003 12:16:36 +0100 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20030822111636.GG1417@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd-net@freebsd.org, fenner@freebsd.org, wes@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: SPC cc: fenner@freebsd.org cc: wes@freebsd.org Subject: Receiving INADDR_BROADCAST packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 11:19:39 -0000 Hi all, Ok, the broadcast sending problem is solved, as far as I'm concerned. However, the reception problem isn't: 14766 broadcast/multicast datagrams dropped due to no socket This despite: wi0: flags=8843 mtu 1500 inet 1.234.56.78 netmask 0xff000000 broadcast 1.255.255.255 udp4 0 0 1.234.56.78.654 *.* I can: a) patch udp_input() to pass INADDR_BROADCAST traffic to all sockets bound to the port and on the interface where the traffic was received. Possibly conditionalise this interface based on a socket-level option. e.g. 'Yes, I'm an interface-bound socket and I'd like undirected broadcasts on my interface thankyou very much'. This would be done in such a way which was 'opt-in' and didn't impact existing applications. b) preserve the existing 4.2BSD kludge of binding to INADDR_ANY and not knowing what interface an undirected broadcast came in on. c) same as b) but use IP_RECVIF to determine which interface the broadcast came in on, and change my network event dispatch code accordingly. d) use a SOCK_RAW socket. e) use BPF. b), d), e) are not solutions. They are cop-outs. Please don't suggest them. Really. I note that Apple are using IP_RECVIF in their mDNS code. The problem there is not the same (they're dealing with multicasts), but similar. I already cache the interface index in my internal RIB and track RTM_IFINFO, RTM_IFANNOUNCE events, so this isn't too big a hit (the fact that this ioctl provides an index, not a name). I'm going to go with solution c) for now, but has anyone considered a)? (Little choice really, we have a code freeze coming up, and I'd like my code to run unchanged on 4.9-RELEASE). BMS