Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Oct 2003 11:52:47 -0400
From:      Barney Wolff <barney@databus.com>
To:        Wes Peters <wes@softweyr.com>
Cc:        net@freebsd.org
Subject:   Re: Help Broadcasting a UDP packet on the LAN:URGENT
Message-ID:  <20031023155247.GA6635@pit.databus.com>
In-Reply-To: <200310230155.55363.wes@softweyr.com>
References:  <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031021214932.GA659@saboteur.dek.spc.org> <20031021222307.GA80895@pit.databus.com> <200310230155.55363.wes@softweyr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 23, 2003 at 01:55:55AM -0700, Wes Peters wrote:
> 
> To me it's not a matter of "boot code" vs. general usefulness so much as 
> it's just obviously the right way to do it.  We use all-ones packets well 
> after boot to have our appliances identify each other on the network and 
> share configuration information, and it's not always evident which 
> network interface(s) they should be using to do this.

What are you going to do when IPv6 comes into more general use, since
it has no broadcast address?

> The current code binds to each of the interfaces and blats out a packet, 
> but it just seems obvious that the all-ones address implies all attached 
> interfaces because you have a per-network broadcast address if you want 
> to do per-interface broadcasts.

Yes.  I would have expected AODV to use the net-broadcast address.  I
suspect that they did it to take advantage of the prohibition on
forwarding packets with 255.255.255.255 dest - but that could have been
done just as well by sending with ttl=1.

The general answer to all of these issues is to use multicast rather
than broadcast, as will be required anyway with IPv6.

> I've been working with Bruce on this and there are parts that still worry 
> me.  If you want to poke holes in the thinking we've been doing, I'm 
> always happy to have another set of eyeballs on the design and I'm sure 
> Bruce will too.  Interactions with VLANs, for instance.  If you send an 
> all-ones broadcast on an interface that has one or more VLANs configured, 
> do you repeat them "on" each VLAN as well?  Ugh.  What about 
> point-to-point links?  Are those always considered gateways to a foreign 
> network, or just another form of locally attached network?

The multicast notion would suggest that this be handled as a special
case of multicast, with a pseudo group that can't occur naturally.
That way you get "for free" to control which interfaces should send
the broadcast, based on group membership.

The whole VLAN thing is nasty, but I'd say that the general issue is
does the box itself have a virtual interface on the VLAN, or is it
merely switching on it.  If the former, you send packets and process
received packets up the stack.  If the latter, you just do what any
switch/bridge would do, because "you" (ie, higher layers) are not really
on that layer-3 network.

On point-to-point, I've never been really happy that the two ends can
have addresses in different nets, but some people do it that way.
I always prefered to define a /30 (or /31 if the code allows) for the
link itself.  But that difference solves the issue of whether the p2p
link should be treated as local or not - if the far end is on a
different subnet, it's remote; same subnet, it's local.

> I'm pretty certain the code won't be all that difficult if we just fully 
> understand the problem before we jump in, but I'm also pretty certain we 
> don't fully understand the problem, let alone the solution.  ;^)

Allowing packets to 255.255.255.255 out an interface, $1.98.  Deciding
which interfaces to send on, priceless.

Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031023155247.GA6635>