Date: Thu, 23 Oct 2003 11:37:39 -0700 From: Wes Peters <wes@softweyr.com> To: Barney Wolff <barney@databus.com> Cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT Message-ID: <200310231137.39590.wes@softweyr.com> In-Reply-To: <20031023155247.GA6635@pit.databus.com> References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <200310230155.55363.wes@softweyr.com> <20031023155247.GA6635@pit.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 23 October 2003 08:52 am, Barney Wolff wrote:
> 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?
Good question. I hope that happens in my lifetime; I've only got 30 or 40
years left in me.
> > 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.
Hopefully IPv6 routers will get multicast routing right, too. You
certainly can't count on that in the IPv4 realm. Even when the routers
do support it, the network administrators usually don't, because they can
barely grok IP routing to start with.
> > 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.
Bruce's design allows you to specify which interfaces participate in the
"all ones" group with a sockopt (or was it sysctl?) That seems like a
reasonable compromise between the logical viewpoint of "it's an all
interfaces broadcast" and a security stance where you don't want
broadcasts to go to ALL interfaces.
> 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.
Ah, excellent. I agree the VLAN implementation we have has a lot of
warts. I don't have the dedicated time to tear into it myself, but I try
to help other enterprising souls who want to take it on where I can. The
last two both exploded, but I have high hopes for Bruce. ;^)
> 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.
And if not, the link itself is usually an isolated network. That'll do.
> > 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.
For everything else, there's MasterClue. Thanks for the help.
--
Where am I, and what am I doing in this handbasket?
Wes Peters wes@softweyr.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310231137.39590.wes>