IPSET iptree problem

IPSET iptree problem

[Łukasz Nierychło]

Hello everyone,
I would like to ask you to help me with ipset tool
because it works other way I expect when I use "timeout"
parameter.

look:  (this is OK without "--timeout")
[root@rt ~]# ipset -N ts1 iptree
[root@rt ~]# ipset -A ts1 10.10.10.10
[root@rt ~]# ipset -T ts1 10.10.10.10
10.10.10.10 is in set ts1.
[root@rt ~]# ipset -T ts1 10.10.10.1
10.10.10.1 is NOT in set ts1.
[root@rt ~]# ipset -T ts1 10.10.10.255
10.10.10.255 is NOT in set ts1.

My question is what I did wrong here:
"--timeout" is used:

[root@rt ~]# ipset -N ts2 iptree --timeout 100
[root@rt ~]# ipset -A ts2 20.20.20.20
[root@rt ~]# ipset -T ts2 20.20.20.20
20.20.20.20 is in set ts2.
[root@rt ~]# ipset -T ts2 20.20.20.1
20.20.20.1 is in set ts2.
[root@rt ~]# ipset -T ts2 20.20.20.254
20.20.20.254 is in set ts2.
[root@rt ~]# ipset -T ts2 20.20.1.1
20.20.1.1 is NOT in set ts2.

If I use "timeout" then ipset test returns true
to all IPs on subnet 20.20.20.0/24.

Shouldn't this work the same way ( as without "timeout" )?
Is this ok  ?

my linux = kernel-2.6.21.1
+ set patch (pom-ng-20070513)
+ ipset-20070514

Help me please
£ukasz Nierych³o

Re: IPSET iptree problem

[Łukasz Nierychło]

Hello Craig,

The answer is no. :(
I think it is something with garbage colector because if
you modify line 32 in file:
/usr/src/linux/net/ipv4/netfilter/ip_set_iptree.c
#define IPTREE_GC_TIME 5*60

to:
#define IPTREE_GC_TIME 1*60

(and recompile kernel modules)

this funny feature is available for one minute instead of 5
( after modules ip_set and ip_set_iptree are loaded
into memory )

After IPTREE_GC_TIME all is ok for some unknown period of
time, but finally this malfunction comes again.

£ukasz Nierych³o

> £ukasz (and Jozsef),
> I am experiencing the same problem you cited below.
> The funny thing is that I am almost sure that it was working for several  
> weeks, but now I see the exact behavior in your email.
> Did you ever find a solution to this?

Re: IPSET iptree problem

[Jozsef Kadlecsik]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 902 bytes --]

On Thu, 23 Aug 2007, Łukasz Nierychło wrote:

> I think it is something with garbage colector because if
> you modify line 32 in file:
> /usr/src/linux/net/ipv4/netfilter/ip_set_iptree.c
> #define IPTREE_GC_TIME 5*60
>
> to:
> #define IPTREE_GC_TIME 1*60
>
> (and recompile kernel modules)
>
> this funny feature is available for one minute instead of 5
> ( after modules ip_set and ip_set_iptree are loaded
> into memory )
>
> After IPTREE_GC_TIME all is ok for some unknown period of
> time, but finally this malfunction comes again.

Thank you the reports, on the weekend I'll be able to debug it.
Please stay tuned.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: IPSET iptree problem

[Jozsef Kadlecsik]

Hi,

On Thu, 23 Aug 2007, Jozsef Kadlecsik wrote:

>> After IPTREE_GC_TIME all is ok for some unknown period of
>> time, but finally this malfunction comes again.
>
> Thank you the reports, on the weekend I'll be able to debug it.
> Please stay tuned.

Hm, I'm unable to reproduce it. There *was* an endian-related bug in 
the iptree type, but even that could not cause such behaviour.

Please give a try to the upcoming release, which you can get
as http://ipset.netfilter.org/ipset-2.6.23-rc3.patch.

If you still see the bug, please do the following:

- recompile ipset in the kernel with debugging enabled, i.e. change

#if 0
#define IP_SET_DEBUG
#endif

   to

#if 1
#define IP_SET_DEBUG
#endif

   in <kernel-src>/include/linux/netfilter_ipv4/ip_set.h

- then after recompiling issue the following commands and report the
   resulted kernel logs:

# ipset -N viruses iptree --timeout 100
# ipset -A viruses 172.16.14.12
# ipset -T viruses 172.16.14.12
# ipset -T viruses 172.16.14.111
# ipset -n -L viruses

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: IPSET iptree problem

[Sami Farin]

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

On Mon, Aug 27, 2007 at 18:40:36 +0200, Jozsef Kadlecsik wrote:
> On Mon, 27 Aug 2007, nofast@welnowiec.net wrote:
>
>> I preformed two tests, one shortly after boot and another few minutes 
>> later.
>> The results are different.
>> I hope this will help you.
>
> It did helped: please give a try to the new version as
> http://ipset.netfilter.org/ipset-2.6.23-rc3.patch2.

Your mask_to_bits function results into infinite loop if called
with parameter 1, for example.

If you care only about first set bit, i.e. you do not bother checking
is netmask valid, you can use:

static inline unsigned int mask_to_bits(ip_set_ip_t mask)
{
  if (mask == 0) return 0;
  return 33 - ffs(mask);
}

-- 
Do what you love because life is too short for anything else.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IPSET iptree problem

[Jozsef Kadlecsik]

On Mon, 27 Aug 2007, Sami Farin wrote:

> Your mask_to_bits function results into infinite loop if called
> with parameter 1, for example.
>
> If you care only about first set bit, i.e. you do not bother checking
> is netmask valid, you can use:
>
> static inline unsigned int mask_to_bits(ip_set_ip_t mask)
> {
>  if (mask == 0) return 0;
>  return 33 - ffs(mask);
> }

ipset does not allow to pass '1' as the parameter to this function.
But you are right, a malicious root user is able to form a request
which can contain not properly handled values.

I can't recall why I did not use ffs at the first place.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary