Re: more on pfil and bridging

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.


_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: PF, bridge, states and window scaling problem
    ... My problem comes with the filter rules. ... the bridge use TCP window scaling. ... but not matched by the rest of the packets ... statefull firewall has an unpredictable behaviour on bridges. ...
    (freebsd-questions)
  • MAC bridging and sniffing packets with specific Ethertype
    ... We are considering development of a simple bridge base on the Windows ... We want to filter this ... operation allowing to set type of Ethernet packet to be filtered (by ... type of Ethernet packets or the NDIS driver will filter these packets ...
    (microsoft.public.windowsce.embedded)
  • Re: more on pfil and bridging
    ... Instead of the bridge registering a separate filter queue for itself, ... bridged packets as "normal" L2 packets. ...
    (freebsd-net)
  • Re: GMFBridge EOS Problem
    ... graph that consists of a source filter, parser/demux/decoder filter, ... and then the bridge sink filter. ... Only one of the bridge sink's input pins ... BridgeSink::OnEOS method only getting called once where the first EOS ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: PF, bridge, states and window scaling problem
    ... My problem comes with the filter rules. ... the bridge use TCP window scaling. ... pass out quick on vlan0 from anIP/32 to any keep state queue ul_client ... Try adding the flags switch as mentioned above. ...
    (freebsd-questions)