[was] addition to ipfw (read vlans from bridge)..

[Max Laier]

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,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20061225/ef8d53f6/attachment.pgp