Date: Mon, 25 Dec 2006 12:22:02 -0800 From: Julian Elischer <julian@elischer.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: Max Laier <max@love2party.net>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. Message-ID: <459032EA.1030601@elischer.org> In-Reply-To: <20061224093951.GD49045@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459032EA.1030601>