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. 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? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
pgp6phtoGhtlT.pgp
Description: PGP signature
