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