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?
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
