pf user tags: maximum lifespan / accessibility

[adrian ilarion ciobanu]

Hello,

My problem:

I need to tag packets from both IPFW and PF for later processing by
another PFIL filter (let's call it FILTY).
I need this because IPFW and PF can be successfully used to some
extent to take care of a big part of my packet
matching rules  and it would be stupid to implement again the same
thing in FILTY instead of taking it further from where IPFW/PF left.

While IPFW's user-settable tag is later available as  mbuf's m_tag_id
and I can see it in FILTY, I can't say I can do the same thing with
PF's user-settable tag, ofcourse.
But I was expecting to find my tag set somewhere (if matched) in the
mbuf_tag's payload, besides pf_mtag data. Later I realized that
expecting this was an error since pf_mtags were
there way before user-settable tags were introduced.

IPFW: : user-settable tags are available for later querying from outside IPFW
PF: user-settable tags aren't available for later querying from
outside PF. Probably there's a good reason for this: could be that it
would be hard to do, or just plain stupid
or nobody would ever use it. Or its just crazy. Altho filter markers
are very handy for passing infos between subsystems but PF want's it
only for its own usage.


If I am getting something wrong, bang my head and please point me to
the right direction. If not,

My question: <<EOQ
Is it safe to prepend a new mbuf_tag containing the matched
user-settable tagnames, eventually removed by the tag's destination
filter?
Thinking to the worst fix one could ever think of: maintaining a local
patch for my needs. Or should
I just stop thinking about including PF in my equation?
EOQ


As far as I can see, IPFW and PF don't mind working with the same
tag_id. Made a simple testcase (the cookied tag is from IPFW ofc,
dmesg output):

PFIL_IN exec order: pf ipfw

1297349438.74018 tag[0] = { .m_tag_id=21, .m_tag_len=0,
.m_tag_cookie=1148380143 }
1297349438.74018 tag[1] = { .m_tag_id=21, .m_tag_len=24, .m_tag_cookie=0 }
tag[1] PF_payload={.hdr=0,rtableid=0,qid=0,.tag=1,.flags=0,.routed=0,.af=0

PFIL_IN exec order: ipfw pf

1297349630.571720 tag[0] = { .m_tag_id=21, .m_tag_len=24, .m_tag_cookie=0 }
tag[0] PF_payload={.hdr=0,rtableid=0,qid=0,.tag=1,.flags=0,.routed=0,.af=0
1297349630.571720 tag[1] = { .m_tag_id=21, .m_tag_len=0,
.m_tag_cookie=1148380143 }


It's a little bit weird here (at least for me) because I tho 21 is
some sort of "reserved" tag id for PF.
Should this rule of thumb be respected by other filters (e.g. ipfw
shouldn't accept a tag id of 21 from user side)?
Do other kernel subsystems mind sometime when finding more than one
tag with id of PACKET_TAG_PF? ( I believe I just asked a second
question)
I'm thinking  a scenario when a subsystem checks for a m_tag_first
with id PACKET_TAG_PF supposedly originating from PF to get
pf_mtag data but it gets instead a IPFW (or other's filter)
zero-length thingie. I think I just was the victim of a short
derailment from my original subject, sorry.



thank you!

p.s. if needed:
FreeBSD godel 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Mon Feb  7
11:05:16 EET 2011     root at godel:/usr/obj/usr/src/sys/GENERIC  amd64