* Re: IDLEDETECT target
2004-08-16 15:04 IDLEDETECT target Timo Teräs
@ 2004-08-19 10:29 ` Harald Welte
0 siblings, 0 replies; 2+ messages in thread
From: Harald Welte @ 2004-08-19 10:29 UTC (permalink / raw)
To: Timo Teräs; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
On Mon, Aug 16, 2004 at 06:04:20PM +0300, Timo Teräs wrote:
> Usually this sort of thing can be accomplished by ppp modules
> PPPIOCGIDLE ioctl. However I need this sort of "IDLE detection" for
> interfaces other than ppp too. And usage of PPIOCGIDLE needs polling
> which I consider bad.
>
> I came up with a couple of choices:
> 1. Use PF_PACKET and filter all packets that will be considered to reset
> the IDLE timer
> 2. Use iptables and QUEUE all packets as above
> 3. Poll match count of some iptable rule
> 4. Write a custom iptables target to send notification when interface
> goes to idle
5. use ULOG target (and only copy packet metadata, using reasonable
buffer size this should give you very little kernel/userspace
transitions) just '-j ULOG --ulog-cprange 0' all packets that reset the
timeout. Set the --ulog-qthreshold to a high value, and make the
'flushtimeout' module parameter as large as possible within your given
granularity. Let's say you use a 128k ulog netlink buffer, you would
fit about 640 of such packets into one buffer before it gets flushed to
userspace. Not ideal, I agree :(
> Options 1 and 2 involve great amounts of kernel to userland traffic.
1) Not if you use a mmap'ed packet socket (there's a mmap ring enabled
libpacp out there)
2) Not if you ulog instead of QUEUE, and you especially don't cause any
packet delays.
> And option 3 would require polling with relatively small interval to
> be accurate enough.
And reading the whole iptables ruleset with such a small interval is not
a cheap operation either (because all per-cpu per-rule counters need to
get added up, etc).
> So looks like the option four is ideal for my situation. I'd propably
> use netlink to send the events when interface seems to be idle. Other
> possibility is to use d-bus if it gets included in vanilla kernel (see
> http://vrfy.org/projects/kdbusd/).
Adding a new netlink family just for this would also definitely not get
into the mainline kernel, since we're slowly but steadily running out of
netlink numbers.
As for d-bus, I haven't heared any core kernel developer's opionion so
far.
> Basically when ever a packet matches the IDLEDETECT target it would
> reset the interfaces idle timer. When the timer would expire a netlink
> message would be sent.
mh. What about basing this on conntrack? whenever a packet matching a
connection arrives, it also resets the timeout of those conntracks.
So using ctnetlink, you could read out the conntrack table in regular
intervals (let's say every 10 seconds). Then you filter out only those
ESTABLISHED connections that you're interested in, and compare their
timeout values with the default timeouts.
If all of them are mor than <itldetimeout> seconds away from the default
timeout, you know that none of those connections have seen a packet so
far.
> If this approach seems to be okay I'd be willing to implement it
> (assuming no one has done this yet). In this case would this be useful
> enough to be included in the patch-o-matic (and possibly even mainstream
> kernel)?
Yes, you can do it your own way. I would include it in patch-o-matic.
But I am still not sure whether it's really worth having yet another
over-specialized target.
> Cheers,
> Timo
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread