Date: Mon, 25 Dec 2006 22:39:51 +0100 From: Max Laier <max@love2party.net> To: Julian Elischer <julian@elischer.org> Cc: Yar Tikhiy <yar@comp.chem.msu.su>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. Message-ID: <200612252239.59737.max@love2party.net> In-Reply-To: <459032EA.1030601@elischer.org> References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1706852.BfUdVVsOLA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 -=20 consider them withdrawn. I still don't like the idea that the code in=20 net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody=20 feels that it does belong there - fine. I hereby resign from this=20 thread. Anyway, I hope everybody is having happy holidays. > If what you are suggesting is that we pass into ipfw an 'offset' > into the packet as well as the packet, then yes I like that idea, > but I didn't see Andre suggest it. > > I can however submit another patch that does that.. > > However I'd like to hear from you a response to the mail > I sent you with a pure cleanup patch that removes mopst occurrances > of mtod() from ipfw.. if you did not get that email I can resend it > to you. > > > There is also work in progress to introduce nested VLANs AKA Q-n-Q. > > They seem to present a challenge to the scheme you are implementing. > > not a permanent problem.. it could be modified to handle it. > but I'll take it into account in the next version if > you think it is a required feature.. what is the maximum > nesting level? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1706852.BfUdVVsOLA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFkEUvXyyEoT62BG0RApkcAJ9E1S63eP7DqN+3zZwRl7Ge4wY6cgCfeFDR 9LuTd4M+g+6WLSRMdIqSVR0= =sx1w -----END PGP SIGNATURE----- --nextPart1706852.BfUdVVsOLA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612252239.59737.max>