[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.01.1005281001550.11570@obet.zrqbmnf.qr>
Date: Fri, 28 May 2010 10:05:56 +0200 (CEST)
From: Jan Engelhardt <jengelh@...ozas.de>
To: Luciano Coelho <luciano.coelho@...ia.com>
cc: "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kaber@...sh.net" <kaber@...sh.net>, Timo Teras <timo.teras@....fi>
Subject: Re: [RFC] netfilter: WIP: Xtables idletimer target implementation
On Friday 2010-05-28 07:25, Luciano Coelho wrote:
>
>Do you have any other suggestion on how I can associate the rules to
>specific interfaces?
-A INPUT -i foo -j do
-A do -j idletimer
A little funny, but actually this would allow me to keep a timer
for a group of interfaces rather than just per-if.
>> >+static int xt_idletimer_checkentry(const struct xt_tgchk_param *par)
>> >+{
>> >+ const struct xt_idletimer_info *info = par->targinfo;
>> >+ const struct ipt_entry *entryinfo = par->entryinfo;
>> >+ const struct ipt_ip *ip = &entryinfo->ip;
>>
>> I'm not sure spying on ipt_ip is a long-term viable solution.
>
>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
>defined as part of the ruleset.
I have patches ready since a while that decouple ipt_ip
from a rule, so there is no guarantee that such will exist.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists