Date: Fri, 20 Oct 2006 18:28:42 -0700 From: Julian Elischer <julian@elischer.org> To: FreeBSD Net <net@freebsd.org> Subject: more on pfil and bridging Message-ID: <453977CA.8020807@elischer.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?453977CA.8020807>