more on pfil and bridging

[Max Laier]

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.

> 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.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20061021/1dd5d042/attachment.pgp