Date: Tue, 15 Jul 2003 19:49:23 -0400 From: Chuck Swiger <cswiger@mac.com> To: Wes Peters <wes@softweyr.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: broadcast udp packets ... Message-ID: <3F149303.1010408@mac.com> In-Reply-To: <200307151548.48778.wes@softweyr.com> References: <200307151709.h6FH9UOW055742@hole.shrew.net> <200307151548.48778.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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? [ ... ] > 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... ] 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? 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. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F149303.1010408>