-m state is not working.

-m state is not working.

[Husnu Demir]

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

Hi,

I recently compiled new kernel and tried the following;

# iptables -I FORWARD -p tcp -m state --state NEW -j ACCEPT
iptables: Invalid argument


# uname -a
Linux ng-test 2.6.28.3 #4 SMP Thu Feb 5 08:37:37 EST 2009 x86_64 GNU/Linux

# lsmod
Module                  Size  Used by
xt_state                4608  0
nf_conntrack           64424  1 xt_state
iptable_filter          5440  0
ip_tables              19408  1 iptable_filter
x_tables               23432  2 xt_state,ip_tables
ipv6                  251328  22
sr_mod                 17540  0
e1000e                111728  0
..
..

# modinfo xt_state
filename:       /lib/modules/2.6.28.3/kernel/net/netfilter/xt_state.ko
license:        GPL
author:         Rusty Russell <rusty@rustcorp.com.au>
description:    ip[6]_tables connection tracking state match module
alias:          ipt_state
alias:          ip6t_state
vermagic:       2.6.28.3 SMP mod_unload modversions
depends:        x_tables,nf_conntrack

# iptables -V
iptables v1.4.2


Did I forget to add anything? How can I see what is happing?

thanks.

hdemir.


[-- Attachment #2: hdemir.vcf --]
[-- Type: text/x-vcard, Size: 164 bytes --]

begin:vcard
fn:Husnu Demir
n:Demir;Husnu
email;internet:hdemir@metu.edu.tr
tel;work:+903122103330
tel;fax:+903122103303
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: -m state is not working.

[Patrick McHardy]

Husnu Demir wrote:
> Hi,
> 
> I recently compiled new kernel and tried the following;
> 
> # iptables -I FORWARD -p tcp -m state --state NEW -j ACCEPT
> iptables: Invalid argument
> 
> 
> # uname -a
> Linux ng-test 2.6.28.3 #4 SMP Thu Feb 5 08:37:37 EST 2009 x86_64 GNU/Linux
> 
> # lsmod
> Module                  Size  Used by
> xt_state                4608  0
> nf_conntrack           64424  1 xt_state
> iptable_filter          5440  0
> ip_tables              19408  1 iptable_filter
> x_tables               23432  2 xt_state,ip_tables
> ipv6                  251328  22
> sr_mod                 17540  0
> e1000e                111728  0
> ..
> ..
> 
> # modinfo xt_state
> filename:       /lib/modules/2.6.28.3/kernel/net/netfilter/xt_state.ko
> license:        GPL
> author:         Rusty Russell <rusty@rustcorp.com.au>
> description:    ip[6]_tables connection tracking state match module
> alias:          ipt_state
> alias:          ip6t_state
> vermagic:       2.6.28.3 SMP mod_unload modversions
> depends:        x_tables,nf_conntrack
> 
> # iptables -V
> iptables v1.4.2
> 
> 
> Did I forget to add anything? How can I see what is happing?

I'm guessing you forgot nf_conntrack_ipv4.

Re: -m state is not working.

[Husnu Demir]

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

Yes,

I forgat to add that support :) But xt_state should not be seen if
nf_conntrack_ipv4 is not selected on the kernel config. It is useless without
nf_conntrack_ipv4 support.


Thanks.

hdemir.

Patrick McHardy wrote:
> Husnu Demir wrote:
>> Hi,
>>
>> I recently compiled new kernel and tried the following;
>>
>> # iptables -I FORWARD -p tcp -m state --state NEW -j ACCEPT
>> iptables: Invalid argument
>>
>>
>> # uname -a
>> Linux ng-test 2.6.28.3 #4 SMP Thu Feb 5 08:37:37 EST 2009 x86_64
>> GNU/Linux
>>
>> # lsmod
>> Module                  Size  Used by
>> xt_state                4608  0
>> nf_conntrack           64424  1 xt_state
>> iptable_filter          5440  0
>> ip_tables              19408  1 iptable_filter
>> x_tables               23432  2 xt_state,ip_tables
>> ipv6                  251328  22
>> sr_mod                 17540  0
>> e1000e                111728  0
>> ..
>> ..
>>
>> # modinfo xt_state
>> filename:       /lib/modules/2.6.28.3/kernel/net/netfilter/xt_state.ko
>> license:        GPL
>> author:         Rusty Russell <rusty@rustcorp.com.au>
>> description:    ip[6]_tables connection tracking state match module
>> alias:          ipt_state
>> alias:          ip6t_state
>> vermagic:       2.6.28.3 SMP mod_unload modversions
>> depends:        x_tables,nf_conntrack
>>
>> # iptables -V
>> iptables v1.4.2
>>
>>
>> Did I forget to add anything? How can I see what is happing?
> 
> I'm guessing you forgot nf_conntrack_ipv4.
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe
> netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: hdemir.vcf --]
[-- Type: text/x-vcard, Size: 164 bytes --]

begin:vcard
fn:Husnu Demir
n:Demir;Husnu
email;internet:hdemir@metu.edu.tr
tel;work:+903122103330
tel;fax:+903122103303
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: -m state is not working.

[Christoph Paasch]

Hi,

On Tue February 10 2009, Husnu Demir wrote:
> Yes,
>
> I forgat to add that support :) But xt_state should not be seen if
> nf_conntrack_ipv4 is not selected on the kernel config. It is useless
> without nf_conntrack_ipv4 support.

Well, xt_state doesn't depends on nf_conntrack_ipv4, it can also be use 
nf_conntrack_ipv6 or any other module you write yourself. The thing is that 
without nf_conntrack_ipv4 (or *_ipv6), it uses nf_conntrack_l3proto_generic, 
which won't be tracked, because get_l4proto(...) returns -NF_ACCEPT.

Maybe it would be nice to return NF_ACCEPT,  and then handle it with the 
generic layer 4 protocol handler. (set *protonum = 255 and let *dataoff 
unchanged)

Just a little suggestion.

Have a nice day.

--
Christoph Paasch

www.rollerbulls.be
--

Re: -m state is not working.

[Jan Engelhardt]

On Tuesday 2009-02-10 10:06, Christoph Paasch wrote:
>On Tue February 10 2009, Husnu Demir wrote:
>>
>> I forgat to add that support :) But xt_state should not be seen if
>> nf_conntrack_ipv4 is not selected on the kernel config. It is useless
>> without nf_conntrack_ipv4 support.
>
>Well, xt_state doesn't depends on nf_conntrack_ipv4, it can also be use 
>nf_conntrack_ipv6 or any other module you write yourself. The thing is that 
>without nf_conntrack_ipv4 (or *_ipv6), it uses nf_conntrack_l3proto_generic, 
>which won't be tracked, because get_l4proto(...) returns -NF_ACCEPT.

It [Xtables kernel code] will not use l3proto_generic, because

        if (nf_ct_l3proto_try_module_get(par->match->family) < 0) { 
                printk(KERN_WARNING "can't load conntrack support for " 
                                    "proto=%u\n", par->match->family); 
                return false; 
        } 

already catches the "mistake" (of having forgotten to build the
_ipv4/_ipv6 module), and returns EINVAL to userspace.

In other words: always look into dmesg for messages!


Only nf_conntrack will use l3proto_generic, but nf_conntrack is
independent of Xtables ;-)

Re: -m state is not working.

[Christoph Paasch]

Hi,

On Tue February 10 2009, Jan Engelhardt wrote:
> It [Xtables kernel code] will not use l3proto_generic, because
>
>         if (nf_ct_l3proto_try_module_get(par->match->family) < 0) {
>                 printk(KERN_WARNING "can't load conntrack support for "
>                                     "proto=%u\n", par->match->family);
>                 return false;
>         }
>
> already catches the "mistake" (of having forgotten to build the
> _ipv4/_ipv6 module), and returns EINVAL to userspace.
Ups, didn't knew about that. Thanks... :-)

>
> In other words: always look into dmesg for messages!
>
>
> Only nf_conntrack will use l3proto_generic, but nf_conntrack is
> independent of Xtables ;-)

I'm asking me, why does xt_state needs an l3 handler different from generic? 
(the call to nf_ct_l3proto_try_module_get ensures this)
Why not trying to handle l3 and l4 in a generic way, if there is no other 
module compiled into the kernel, and so being able to access the state via 
xt_state.

In any case, in my opinion, the generic l3 handler doesn't serves anything, 
because it will return -NF_ACCEPT at the call to get_l4proto. Why not 
associate the l4 generic handler to the l3-one? That way, the tracking for 
unknown protocols (or not compiled into the kernel) can continue.

Christoph

P.S.: Jan, did you took a look at the code I sended to you? It's no problem, 
if you didn't had the time...