From owner-freebsd-net Sat Apr 29 3: 9:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id BD28F37B76B; Sat, 29 Apr 2000 03:09:47 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA36762; Sat, 29 Apr 2000 12:10:38 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004291010.MAA36762@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: from Robert Watson at "Apr 28, 2000 02:48:46 pm" To: Robert Watson Date: Sat, 29 Apr 2000 12:10:38 +0200 (CEST) Cc: Archie Cobbs , committers@FreeBSD.org, freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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