broadcast udp packets ...

Wes Peters wes at softweyr.com
Thu Jul 17 00:57:18 PDT 2003


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 at softweyr.com                                    http://softweyr.com/



More information about the freebsd-net mailing list