Date: Fri, 28 Apr 2000 14:48:46 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Archie Cobbs <archie@whistle.com> Cc: committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <Pine.NEB.3.96L.1000428143808.46934C-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1000428141910.46934B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Per my comment a little bit ago, please find patches that clean up the bridge/ipfw code a little at: http://www.watson.org/~robert/bridge.patch Because I'm travelling, I haven't had a chance to build or use the code in a few weeks, so don't guaranty it will apply cleanly. I also threw in by bridge0 interface support, which allows BPF to be used to monitor packets across the bridge rather than individual interfaces, which I've found useful for debugging. Caveats apply as a bridge can't accurately present the ordering and dropping of packets on various segments, but I've still found it useful. This restructures the bridge.c code to seperate out IP filtering code, as well as open up the possibility for hooks for other types of filtering. I also inserted a few comments pointing out possible limitations in the code, and emulated the existing ipfw/bridge bugpool. In particular, the following bugs still apply: o IPFW divert/fwd are not implemented These are both troubled due to the code paths associated with bridging vs. packet forwarding vs. local delivery, and the possibility of duplicate delivery. I'm beginning to suspect that the real solution here is the ability to construct arbitrary virtual topologies of interfaces in kernel, and then bind services to virtual interfaces and topologies. I.e., bind IP services to a virtual bridge interface instead of to individual interfaces, as that might be more intellectually pleasing from the perspective of avoiding duplicate delivery, as well as maintaining source interface (which is important for bridging so as to not send the packet back out the source port, which is bad). o IPFW DUMMYNET still implicit ACCEPT When using IPFW and DUMMYNET with BRIDGE, PIPE commands implicitely ACCEPT after the packet has suffered from traffic shaping. This is bad, should be in our ERRATA for various releases, and probably fixed. If fixed, it should be documented as such. BTW, on the DUMMYNET front, my feeling is that rather than using mbuf queueing routines for managing queues, it would be better/easier to use some sort of DUMMYNET queue structure that maintained meta-data, as opposed to the current insertion of DUMMYNET data at the front of the mbuf. The current behavior causes some unpleasentness as the bridge code can't easily determine what type of packet it is based on the front of the mbuf due to the header. Moving to providing ETHERTYPE as an argument to the bridge code would substantially fix this, but I think storing DUMMYNET data somewhere other than the mbuf makes sense for a variety of reasons. On an unrelated note, it would be a good idea if we did real spanning tree stuff--I have a copy of the appropriate IEEE spec, but haven't had a chance to review it for complexity/et al as yet due to travel. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000428143808.46934C-100000>