addition to ipfw..

[Julian Elischer]

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.