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

[Yar Tikhiy]

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