more on pfil and bridging

[Julian Elischer]

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.

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.

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.




Julian