* Writing a match that communicates with userspace
@ 2006-07-18 23:22 Rennie deGraaf
2006-07-19 14:15 ` Patrick McHardy
0 siblings, 1 reply; 2+ messages in thread
From: Rennie deGraaf @ 2006-07-18 23:22 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]
I'm trying to write a match module for iptables that needs to call out
to a userspace application (using netlink) for additional information
before deciding if it should match a given packet or not. The delay
before the userspace app. responds could be as much as a second or so;
any longer, and the match should fail. My questions is, how could I
implement such a system?
What I was considering was to put my match() function into some sort of
interruptible wait state after sending the request to userspace, and
having my netlink socket callback wake up the match function. However,
I haven't been able to figure out what sort of concurrency exists in
netfilter (If one I block in match(), does that tie up the whole system
until resuming, or are all packets handled in their own threads?), and
the kernel debugging code complains whenever I call msleep() or mdelay()
from within match(). I'm not sure how to implement this approach
safely, or even if it is possible to do so.
My other thought was to store packets in an internal queue and hotdrop
them after sending the request to userspace, and having my netlink
callback pull them out and reinject them where they left off, but have
no idea how do the reinjecting or how to put an upper bound on the time
packets wait in my internal queue. This design also seems to be quite a
kludge.
I suppose it would be possible for me to shoe-horn my match into a
target, or even move the entire system to userspace and use NFQUEUE, but
that would be even more of a kludge.
Does anyone have any suggestions on how I could design and implement
such a system? I would be grateful for any advice that you can give.
Thanks,
Rennie deGraaf
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Writing a match that communicates with userspace
2006-07-18 23:22 Writing a match that communicates with userspace Rennie deGraaf
@ 2006-07-19 14:15 ` Patrick McHardy
0 siblings, 0 replies; 2+ messages in thread
From: Patrick McHardy @ 2006-07-19 14:15 UTC (permalink / raw)
To: Rennie deGraaf; +Cc: netfilter-devel
Rennie deGraaf wrote:
> I'm trying to write a match module for iptables that needs to call out
> to a userspace application (using netlink) for additional information
> before deciding if it should match a given packet or not. The delay
> before the userspace app. responds could be as much as a second or so;
> any longer, and the match should fail. My questions is, how could I
> implement such a system?
>
> What I was considering was to put my match() function into some sort of
> interruptible wait state after sending the request to userspace, and
> having my netlink socket callback wake up the match function. However,
> I haven't been able to figure out what sort of concurrency exists in
> netfilter (If one I block in match(), does that tie up the whole system
> until resuming, or are all packets handled in their own threads?), and
> the kernel debugging code complains whenever I call msleep() or mdelay()
> from within match(). I'm not sure how to implement this approach
> safely, or even if it is possible to do so.
>
> My other thought was to store packets in an internal queue and hotdrop
> them after sending the request to userspace, and having my netlink
> callback pull them out and reinject them where they left off, but have
> no idea how do the reinjecting or how to put an upper bound on the time
> packets wait in my internal queue. This design also seems to be quite a
> kludge.
>
> I suppose it would be possible for me to shoe-horn my match into a
> target, or even move the entire system to userspace and use NFQUEUE, but
> that would be even more of a kludge.
>
> Does anyone have any suggestions on how I could design and implement
> such a system? I would be grateful for any advice that you can give.
IIRC the geoip match doesn something similar, I guess you can find
some pointers there.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-07-19 14:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-18 23:22 Writing a match that communicates with userspace Rennie deGraaf
2006-07-19 14:15 ` Patrick McHardy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.