Re: more on pfil and bridging

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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgpEDJJMikKYr.pgp
Description: PGP signature

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, ... It should register its own stack and each filter type should ... Ather and bridge need to be distinguishable. ... bridged packets as "normal" L2 packets. ...
    (freebsd-net)
  • Re: How to set NIC to promiscuous mode from FilterHook driver
    ... So from your reply I take it you are interested in getting packets destined to other hosts -that are not necessarily originated from the host your filter is running on-. ... As I said in my previous post, setting the adapter to promiscuous mode is not going to help you. ... the filter hook driver I mentioned is as per the msdn ...
    (microsoft.public.development.device.drivers)
  • Re: Traffic control: throttling downloads
    ... The easiest way is if you are just routing, then you can add a qdisc to the lan facing interface and shape traffic as you would for upstream. ... tc filter add dev eth0 protocol ip prio 1 parent ffff: ... The first filter matches tcp packets with length < 128 bytes by using a match of 0x0000 and a mask of 0xff80 starting at byte 2 of the ip packet, which is length - you can only match powers of 2 like this. ... If you want to use normal qdiscs on ingress traffic you have to use ifb. ...
    (comp.os.linux.networking)