Re: ipset 6.6 bug: subnet (mis)matching

[Mr Dash Four <mr.dash.four@googlemail.com>]

>> [root@test1 ~]# ipset n test hash:net family inet timeout 0
>> [root@test1 ~]# ipset a test 10.16.0.0-10.16.255.255
>> [root@test1 ~]# ipset l test
>> Name: test
>> Type: hash:net
>> Header: family inet hashsize 1024 maxelem 65536 timeout 0 
>> Size in memory: 16832
>> References: 0
>> Members:
>> 10.16.0.0/16 timeout 0
>> [root@test1 ~]# ipset t test 10.16.224.0/24
>> 10.16.224.0/24 is NOT in set test.
>> [root@test1 ~]# ipset t test 10.16.224.1   
>> 10.16.224.1 is in set test.
>>
>> That is plainly wrong!
>>     
>
> No, that's a feature: it makes possible to check from userspace how the 
> kernel would match an IP address in the set.
You can't be serious! How could this be a "feature"?! It is a bug, clearly!

The /24 subnet (10.16.224.0-10.16.224.255) clearly covers the single IP 
address (10.16.224.1) and the test should be positive in both cases, as 
the /16 member of the set (10.16.0.0-10.16.255.255) covers both the 
single IP address as well as the /24subnet range tested. Apparently, 
that seems not to be the case. How am I suppose to test subnet ranges then?

I presume if I have 10.16.224.0/24 as a member and do a test with 
10.16.0.0/16 that would also return a negative match, isn't that the case?

>  Maybe it's badly worded in 
> the manpage: "When testing entries, if a host address is tested, then the 
> kernel tries to match the host address in the networks added to the set 
> and reports the result accordingly."
>   
That's all well and good for hosts, but ip ranges should either be 
tested properly or testing of those should be disabled altogether 
(which, if introduced, would be a severe restriction for me - I am not 
going to run a couple of thousand "ipset t" tests just to see that all 
of the single IP addresses in the range I am interested in match - that 
simply isn't going to happen!).