IDLEDETECT target

IDLEDETECT target

[Timo Teräs]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

Hi all,

I'm currently planning to write a new target to detect when ever a 
network interface has been idle for a configurable amount of time.

First some background:

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

Options 1 and 2 involve great amounts of kernel to userland traffic. And
option 3 would require polling with relatively small interval to be 
accurate enough.

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/).

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.

Now I'm asking if this is a good idea? And has anyone tried to do such a 
thing before?

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)?

Cheers,
   Timo

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: IDLEDETECT target

[Harald Welte]

[-- 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 --]