more on pfil and bridging

[Julian Elischer]

Max Laier wrote:
> On Saturday 21 October 2006 03:28, Julian Elischer wrote:
>> The more I look at this the more I think that it is broken.
>>
>> Instead of the bridge registering a separate filter queue for itself,
>> it is using the queues set up by the IP stack.
>>
>> It should register its own stack and each filter type should
>> register their own filter functions for that level on the stack.
>>
>> is there a reason that this is not done? If the answer is simply
>> ENOTIME then I will volunteer to go through it and do it properly.
> 
> I guess so.
> 
>> suggested changes:
>>
>> I propose to create filter queues for if_ethersubr.c and if_bridge.c
>> distinguished by slightly different keys. I also propose to rename
>> inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks).
>>
>> I would also look at following the documentation by seeing whether
>> we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET
>> as the key type/key.
> 
> I think if_ethersubr.c and if_bridge.c should pass to the same pfil hook.  
> And I'd vote for the current - very sophisticated - if_bridge.c filtering 
> to stay, at least as opt-in.  Otherwise it will be tricky to support 
> stateful filtering in pf on transparent bridges.

Ather and bridge need to be distinguishable.
Believe me. I do this in a product  and I need to tell them apart.

> 
>> The Direction argument should be expanded to be a generic 'flags'
>> argument where two of the flags are direction.
>> Other flags can be:
>> WAIT_OK:	(It's already defined to be there)
>> HOST_ORDER:	Fields in the header have been swapped to host order.
>>
>> The ipfw code would supply different entry points for bridge
>> and Ethernet supplied packets.
>>
>> the ipfw args struct should grow a 'flags' field that can
>> indicate (for example) that the IP header fields have not been
>> put in host order (or have) and that the packet is from a bridge
>> rather than just being layer2.
>>
>> ipfw would grow a 'bridge' keyword to check that flag.
> 
> I don't think that is necessary.  Right now we also have a mode to pass 
> bridged packets as "normal" L2 packets.  ipfw doesn't discriminate 
> between packets from if_ethersubr.c and if_bridge.c - and I don't see why 
> it should.  If discrimination is required one can still fall back on the 
> L3decap in if_bridge.c - see above.

I really need to distinguish between the two cases.

>