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