Date: Tue, 26 Dec 2006 07:38:01 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org, Andre Oppermann <andre@freebsd.org>, Julian Elischer <julian@elischer.org> Subject: Re: [was] addition to ipfw (read vlans from bridge).. Message-ID: <20061226043800.GC81280@comp.chem.msu.su> In-Reply-To: <200612252239.59737.max@love2party.net> References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <200612252239.59737.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 25, 2006 at 10:39:51PM +0100, Max Laier wrote: > On Monday 25 December 2006 21:22, Julian Elischer wrote: > > Yar Tikhiy wrote: > > > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > > >> Taking to heart comments by Andre and Max (Laier), > > >> I have redone this patch in a different manner. > > >> > > >> The aim is to be able to see inside vlans when bridging. > > >> Now, this is a 6.x patch to bridge.c because that is what we > > >> are using, but I will make a similar patch to if_bridge.c > > >> for 6 and 7 if this meets with approval. > > >> > > >> > > >> Basically if it is a vlan packet, take off the whole vlan header > > >> instead of just the ether header, but pass to ipfw, an ether header > > >> with the real protocol field substituted in. > > >> when finishing put back everything we removed before. > > >> > > >> > > >> The only addition I'd do to this would be to add a sysctl > > >> to turn it on if people thought it would be break POLA too much > > >> to have it work by default. > > > > > > Excuse me, but I'd like to second Andre's opinion. We should stop > > > fiddling with the mbuf contents in favour of teaching ipfw (or the > > > interface code between bridge and ipfw) of 802.1q (or its > > > generalisation.) Now that the 802.1q VLAN technology has been well > > > integrated in the general Ethernet framework by IEEE, there is very > > > litte sense left in such hacks. If ipfw is to stay L2-agnostic, > > > then let's just pass the offset of the IP header into the mbuf to > > > it. The 802.1q header is so nice and simple and easy to parse at > > > any level. So this patch can be OK in 6.x for the only sake of > > > preserving the pfil ABI, but it should die along with it. An > > > extended interface is apparently called for in HEAD. > > > > You are the one who complained that it should not be done in ipfw, > > and that we should do it the same way we currently handled the > > removal and re-addition of the ethernet header. So that's what I did. > > (in the bridge code), by teaching the ethernet header handling code > > to handle vlan tags as well. > > I'm not sure if you are mistaking Yar for me here. As for my concerns - > consider them withdrawn. I still don't like the idea that the code in > net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody > feels that it does belong there - fine. I hereby resign from this > thread. IMO ipfw should be taught of VLAN internals only if we are going to implement L2 filtering in it. But if not, a simple offset of the IP header computed at the link layer of the stack would do. That would allow for different VLAN or whatever encapsulations as well. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061226043800.GC81280>