Date: Sat, 21 Oct 2006 03:58:45 +0200 From: Max Laier <max@love2party.net> To: freebsd-net@freebsd.org Cc: Julian Elischer <julian@elischer.org> Subject: Re: more on pfil and bridging Message-ID: <200610210358.51403.max@love2party.net> In-Reply-To: <453977CA.8020807@elischer.org> References: <453977CA.8020807@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFOX7bXyyEoT62BG0RAq4ZAJ9M4R3acqj1oPTUwQ3/KIr9qf1ZfACeINM8 Apx/qC1ZwJHrk+QuNj1fJYI= =dWYb -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610210358.51403.max>