From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 08:52:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 809CF16A4B3 for ; Thu, 23 Oct 2003 08:52:49 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B45E43FB1 for ; Thu, 23 Oct 2003 08:52:48 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9NFqlYL006952; Thu, 23 Oct 2003 11:52:47 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9NFqlAE006951; Thu, 23 Oct 2003 11:52:47 -0400 (EDT) (envelope-from barney) Date: Thu, 23 Oct 2003 11:52:47 -0400 From: Barney Wolff To: Wes Peters Message-ID: <20031023155247.GA6635@pit.databus.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310230155.55363.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 15:52:49 -0000 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.