Hi Jan,

Thanks a lot for your comments!


Great, so this will work.  I had checked the x_tables code and it seemed
that the lifetime of targinfo was sufficient, but I was not sure this
would be safe in the future.  Now, if this changes in the future, my

I need to associate the timers with specific interfaces, because it's
the idle time of the interfaces that the userspace in interested in.  I
didn't find any other way to associate the timers with them, except by
looking at the iniface and outiface values in ipt_ip (and eventually,
with IPv6 properly implemented, in ip6t_ip6).  This is what Patrick
suggested when he checked my previous patch [1] and triggered me to do a
major rework on my module ;)

Do you have any other suggestion on how I can associate the rules to

Sure.  These remained there after I removed some traces.  I'll clean



Do you have any other suggestions on how I could get an interface
associated with the rule? I thought about having the userspace pass the
interface as an option to the rule (like I already do for the timeout
value), but that looked ugly to me, since the interface can already be

Ooops! I've redone this part of the code so many times and in this


I agree.  These names are coming from the original code.  I thought
about changing them to something clearer, but didn't bother to do it
yet, because I was focusing on the actual functionality.  I'll change
the names.

Again, thanks for your comments.  I'll rework and submit v2 soon.

Ah, and please excuse my lameness of mistyping the netdev email address
when I submitted the patch.  I fixed it now.

[1]
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/33934


-- 
Cheers,
Luca.

--

[ message continues ]

-A INPUT -i foo -j do
-A do -j idletimer

A little funny, but actually this would allow me to keep a timer

I have patches ready since a while that decouple ipt_ip
from a rule, so there is no guarantee that such will exist.
--

[ message continues ]

Yes, this is what our userspace apps are doing.  I've formulated my
question in an unclear way.  If you check the rest of the code, I create
sysfs files under the interface's directory and use it as an attribute
to notify the userspace when the timer has expired.

In short, I need to figure out a way to associate each rule with an
interface in sysfs, so I can notify the userspace when the timer has

Okay, if that's the case, then I don't know how to associate the rule
with a specific net object in the kobject tree.  Maybe I have to figure
out a different way to notify the userspace, unless I add the target
option I mentioned above. :/


-- 
Cheers,
Luca.

--

[ message continues ]

How about just using an arbitrary user-supplied name? People can

--

[ message continues ]

I considered this option, but then I didn't find a proper place where to
include the attribute in sysfs, since I cannot add it as part of the
interface (eg. /sys/class/net/wlan0/idletimer) as I was doing before.
The other option would be to make the idletimer as part of the
xt_IDLETIMER module object in sysfs
(ie. /sys/module/xt_IDLETIMER/<user_supplied_name>), but it looks out of
place.  And I think adding it as /sys/class/net/idletimer is most likely
out of the question.

The latest "solution" I came up with, is to associate the idletimer with
every interface that it hits.  Whenever a packet arrives, I check which
interface it came from and add the timer to it (eg.
in /sys/class/net/wlan0/idletimer if the packet came via wlan0).  This
causes a bit extra processing per packet, but in most cases there
shouldn't be too many interfaces in the list, so the search should be
fairly quick.  And if performance becomes a problem, it can be worked
around by adding only one interface per ruleset, so the list will never
grow bigger than one node.

I think these two solutions would work.  I prefer the second one,
because we don't need to add the idletimer attribute in an artificial
place in sysfs.

The problem that remains with either solution is if the interface is
already idle when the rule created.  In that case, the timer won't start
(or at least will not be associated with that interface).  It will only
start when the first packet hits.  The only solution I see for this is
to add the interface name as an option to the target.  Maybe something
like "--autostart=wlan0"?

I'll send a new RFC patch soon with this ideas implemented, to better
express what I mean (C code can be easier to read than English :P)


-- 
Cheers,
Luca.

--

[ message continues ]

You couldn't have done that before either, because the interface name


It follows /sys/class/leds/...


I'm impartial though.
--

[ message continues ]

True.  That's why I was using netdevice_notifiers , so that I would
monitor the interface state and add the idletimer attribute when a timer
was associated with the interface that went up.  But now the rules are

Okay, so this can be done in either place.  I tend to
prefer /sys/class/net/idletimer.

What about my other proposal of creating generic timers and associating
them with certain interfaces whenever we get a hit? I mean, to add the
idletimer attribute to eg. /sys/class/net/wlan0/idletimer when a packet
reaches the target from wlan0?


-- 
Cheers,
Luca.

--

[ message continues ]

Let's forget about this other proposal.  It's not going to be efficient
at all.  It's worse than I thought at first, because we need search all
the associated_ifs in all timers whenever a packet is received.

I'll go for the other solution, which will make things much simpler and
I'll be able to remove the dependency on netdevice_notifiers
completely. :D

-- 
Cheers,
Luca.

--

[ message continues ]

I'm starting to like this more and more too, as my code is getting much
smaller ;)

One quick question, though.  Do you have any ideas on how I can make
sure that the user doesn't supply the same name twice (ie. two rules
with the same user_supplied_name)?

The problem is that the userspace always re-adds all the existing rules
before inserting a new one and only later deletes the old rules. :\


-- 
Cheers,
Luca.

--

[ message continues ]

What's so bad about multiple rules being able to reset the timer?

--

[ message continues ]

Ahhmm... Nothing! Thank you, I think I'm getting code-blind :)

-- 
Cheers,
Luca.

--

[ message continues ]