From owner-freebsd-net@FreeBSD.ORG Thu Jul 17 00:57:18 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 DB93037B401 for ; Thu, 17 Jul 2003 00:57:17 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6A843F3F for ; Thu, 17 Jul 2003 00:57:17 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id E3C101B37E; Thu, 17 Jul 2003 00:57:15 -0700 (PDT) From: Wes Peters Organization: Softweyr LLC To: Chuck Swiger Date: Thu, 17 Jul 2003 00:18:43 -0700 User-Agent: KMail/1.5 References: <200307151709.h6FH9UOW055742@hole.shrew.net> <200307151548.48778.wes@softweyr.com> <3F149303.1010408@mac.com> In-Reply-To: <3F149303.1010408@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307170018.43157.wes@softweyr.com> cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp 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: Thu, 17 Jul 2003 07:57:18 -0000 On Tuesday 15 July 2003 04:49 pm, Chuck Swiger wrote: > Wes Peters wrote: > [ ... ] > > > The idea is, we have listener on each ethernet interface listening > > via a bpf. The listener listens for an 'appliance discovery' > > packet which is broadcast by the console application running on the > > admin's workstation. When we receive this discovery packet, we're > > supposed to reply back with a broadcast packet that says 'here I > > am' so the console can get our MAC address. The console > > application does some special h0h0 magic of it's own then sends us > > back another broadcast message that has IP addresses for all 3 > > interfaces. > > Is "h0h0 magic" another term for ARP and RARP? :-) Have you seen > RFC-903? No, "h0h0 magic" is another term for having asked the user of the box a lot of questions about how he's going to use it and having gotten from him the IP addresses 1, 2, or all 3 of the physical interfaces will use. It's a box that in various configurations can be a host, a bridge, a router, or a proxy, each with a possible private "management" interface, or maybe a DMZ port. > > It's a wonderful idea but it doesn't work. This seems in keeping > > with the spirit of BOOTP, DHCP, et al, but is explicitly designed > > to assign a permanent address to an appliance that cannot know it's > > boot address when configured and cannot really predict which of the > > 3 interfaces it might receive an address from. > > Yes, indeed. Of course, there is the issue of how an IP-based reply > should be addressed to an interface which is UP but does not have an > IP address configured as yet? See RFC 919. > [ ... ] > > > So, in short, the IP address 255.255.255.255 is a special case that > > isn't handled as a special case by the ip_output code. I propose > > to change the code so that a packet sent to destination address > > 255.255.255.255 (aka INADDR_BROADCAST) be handled specially. Any > > such packet will be sent to destination address 255.255.255.255 on > > each interface that is marked UP and BROADCAST, with the ip src > > address set to the currently configured primary ip address of the > > interface, even if this is 0.0.0.0. This special case will not > > call rtalloc or do any other route lookups. > > Agreed with regard to not performing any routing. I don't think of > sending to INADDR_BROADCAST as a special case, so much as a > generalization of sending to the network broadcast address, only for > all networks. Or a single network with no routing and no subnet > mask, which people using pure layer-2 switching instead of layer-3 > routing sometimes do. [Such networks are wacky. You tend to > identify machines by MAC or via non-IP protocols... ] Again, see RFC 919. > One concern I have is thinking about too tricky special cases and not > getting the basics correct. For instance, let's say I only have one > interface up, and it's point-to-point, not broadcast: if something > sends IP traffic to 255.255.255.255, shouldn't a packet go out with > the DST address of the PTP peer? If it's not configured for BROADCASTing, it probably shouldn't get the packet at all. This probably includes all point-to-point links, but the only ptp configuration I have right now is a VPN. The VPN interface does not typically have the interface configured for BROADCAST. > After all, the point of sending to 255.255.255.255 is that you are > notationally trying to "send traffic to all hosts that localhost can > reach" (and "are willing to hear"). The way to "send traffic to all > hosts" on a subnetted network efficiently is via the network > broadcast address, but that doesn't mean that there's nothing to talk > to over a point-to-point link. Please read RFC 919 and see if your interpretation agrees with mine. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/