PFIL hooks etc.
Julian Elischer
julian at elischer.org
Fri Oct 20 22:57:52 UTC 2006
I'm looking at some changes to the pfil and ipfw code.
I notice that the pfil changes for link layer and bridge based
filtering have not been completed yet..
(by which I mean that ipfw is still called directly
from those places rather than via pfil. Is anyone working on this?
I have been playing around with filtering bridges and
notice that there is no way for pfil to tell the
called modules (e.g. ipfw) that it was called from a bridge as opposed
to having been called from the ethernet framework.
I see two possible ways this could be done.
1/ adding a filter list head with a different KEY/KEYTYPE
for example
adding a third keytype:
#define PFIL_TYPE_AF 1 /* key is AF_* type */
#define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */
#define PFIL_TYPE_BRIDGE 3 /* key is ignored. Used for bridging */
and making a special filter list for bridging. It would be possible
to use the ifnet associated with the bridge I guess but it would be
hard to find the right queue if you didn't know where the ifnet
for the bridge was.
Possibly another way would be to extend the flags sent
with each packet do contain more than just the direction:
#define PFIL_OUT 0x00000002
#define PFIL_WAITOK 0x00000004
#define PFIL_ALL (PFIL_IN|PFIL_OUT)
+#define PFIL_DIR (PFIL_IN|PFIL_OUT)
+#define PFIL_IPSTACK 0x00000010
+#define PFIL_BRIDGE 0x00000020
+#define PFIL_LINK 0x00000030
+#define PFIL_CALLER 0x000000F0
thus (flags & PFIL_CALLER) can be tested to see who called you.
and (flags & PFIL_DIR) can be tested to get the direction.
thoughts?
Julian
More information about the freebsd-net
mailing list