Date: Mon, 11 Dec 2006 16:04:32 -0800 From: Julian Elischer <julian@elischer.org> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: addition to ipfw.. Message-ID: <457DF210.10403@elischer.org> In-Reply-To: <200612120045.41425.max@love2party.net> References: <457DCD47.5090004@elischer.org> <457DD658.7010707@freebsd.org> <457DE28D.1010106@elischer.org> <200612120045.41425.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: > On Monday 11 December 2006 23:58, Julian Elischer wrote: >> Andre Oppermann wrote: >>> Julian Elischer wrote: >>>> in ipfw layer 2 processing, the packet is passed to the firewall >>>> as if it was a layer 3 IP packet but the ether header is also made >>>> available. >>>> >>>> I would like to add something similar in the case where a vlan tag >>>> is also on the packet.. >>>> >>>> basically I have a change where: >>>> >>>> If we are processing layer 2 packets (in ether or bridge code) >>>> AND a sysctl says to do it, >>>> and it is a vlan packet, >>>> >>>> Then the vlan header is also held back so that the packet can be >>>> processed and examined as an IP packet. It is >>>> (in the same way the ether header is) reattached when the packet is >>>> accepted. >>>> >>>> This allows me to filter packets that are traversing my bridge, >>>> even though they are encapsulated in a vlan. >>>> >>>> I have patches to allow this. I need this function. does anyone >>>> else? >>> Please have the ipfw code examine the vlan tag in the mbuf instead of >>> fiddling with the mbuf contents. >> The ipfw will be ignoring the vlan contents.. the patch is to move the >> 'start of ip header' pointer past the vlan header.. (if asked) so that >> it can identifu the IP packet. >> >> part of the patch is to make sure all the code uses this pointer >> instead of the case now where some code uses it and some uses mtod(). >> >> This could be used in conjunction with vlan keyword that would look at >> the vlan header, but that is a different feature.. > > I understand you do have a patch? Let's see it, so we are clear what we > are talking about. I think that w/o a ipfw feature to identify the vlan > number, it is pretty useless. Of course, it would enable you to do some > basic sanity checks, but real filtering needs to know the vlan it is > concerned with. BTW, what speaks against plugging the bridge into the > vlan on either side and bridge the vlan interfaces together? The ability to look inside a vlan is separate from the ability to select ON the vlan. This is for a device that wants to appear as a bump on the wire. It just wants to filter out packets that have some characteristics.. If you can select on a vlan with another command (e.g. a skipto) then the two are orthogonal. I don't know ahead of time what vlans are in use across the trunk I'm filtering and there may be many.. So making a separate vlan interface for each vlan that I find (what all 4096 of them?) and filtering that separatly is not feasible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457DF210.10403>