Date: Sat, 29 Apr 2000 12:10:38 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Robert Watson <rwatson@FreeBSD.org> Cc: Archie Cobbs <archie@whistle.com>, committers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004291010.MAA36762@info.iet.unipi.it> In-Reply-To: <Pine.NEB.3.96L.1000428143808.46934C-100000@fledge.watson.org> from Robert Watson at "Apr 28, 2000 02:48:46 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Robert, thanks for your code. Will try to have a look at it during the weekend. I have/need a few comments if you dont mind: > 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 this is interesting. I wonder, though, if your 'bridge0' interface is one for the whole machine, or you have one for each cluster of interfaces as defined in net.link.ether.bridge_cfg > 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 because divert/fwd (at least as defined now) is a functionality above level 2, i think the easy (and maybe most correct) way to implement it is to interpret divert/fwd as a DENY for bridged packet, and when the same packet gets to ip_input() do the required action. The tricky part is that when a bridged packet matches a divert/fwd rule, its tag should be changed by bdg_forward() so that it is passed to ether_input() even if it does not have a local addr. > 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. you are a committer, arent you :) > 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 this was done to avoid changing the interface of ip_input() and ip_output(), which i really don't think we want to change. Yes we can replace the fake mbuf with some other data structure, but other than making the code a bit more readable i don;t think it fundamentally changes things. > 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. the spanning tree is not much complex, it is just boring code to write and debug... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- 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?200004291010.MAA36762>