Skip site navigation (1)Skip section navigation (2)
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>