Re: ipset 6.6 bug: subnet (mis)matching

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

> Current behaviour cannot be modified easily. There's no overlap checking 
> (and aggregation/breaking up) in ipset, so it can't be prevented that 
> someone adds overlapping elements to a set:
>
> add 10.16.0.0/16
> add 10.16.1.0/24
>
> Now if 10.16.1.0/24 is tested as you suggest, one cannot tell whether the 
> explicit network 10.16.1.0/24 is added to the set or the tested elements 
> are just the members of a larger network.
>
> Currently:
>     test 10.16.1.1	=> test explicit and implicit membership
>     test 10.16.1.0/24	=> test explicit membership only
>
> What you propose is to test explicit and implicit membership in all cases.
>   
The way I see it, you can take the base of a set member (10.16.0.0 in my 
case), build up a mask with the range (16), do the same with the range 
being tested and then match them with logical "and". If you get the same 
result as the set member - you have a match, if you don't there isn't a 
(complete) match.

Alternatively, you could loop through the members of the specified range 
to be tested and compare against the set members, but that would be a 
bit slower, though since this is done in userspace (i.e. interactively) 
speed wouldn't be that important compared to the kernel matching where 
good performance is needed.

> My top priority now is to get the kernel in sync with ipset 6.7. It's just 
> a much higher problem, because a lot of features and fixes are missing, 
> even from the newest kernel version.
>   
I am not asking or demanding anything to be implemented/corrected 
immediately - I am simply making you aware of a bug in ipset I found 
last night. If/When you are going to fix it it is for you to decide - 
you are the author of ipset, not me - I am just a user.