Re: [ANNOUNCE] ipset 6.11 released

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

> Your request means a third mode, which could lead to even more confusion, 
> because that way one could not check whether the tested address as 
> *element* is added to the set or not.
>   
This is not a feature request, it is a bug fix!

If ipset, for whatever reason, can't (or won't) handle ip range for 
match testing, then such requests should be discarded with the 
appropriate error or warning message on the console given by the ipset 
binary, or, the appropriate functionality should be implemented so that 
such test matches give the right result.

Neither of this currently happens - ipset accepts the ip range value and 
then outputs the wrong result (indicating that there is no match where 
it clearly is). So, what I have highlighted in my previous posts is, 
evidently, *not* a feature request, but a *bug fix*.

> There's no magical element-aggregation in the hash:* types. That is, even 
> if 10.1.0.0/16 is added as an element, 10.1.0.0/24 can be added again as 
> an independent element: either it should be rejected (when the command was 
> issued without the --exist flag) or silently ignored (when was issued with 
> it).
I am not very familiar with the inner intricacies of ipset (I am just a 
user at the end of the day), so I can't comment on whether this ip range 
match could (or should) be implemented, but the way ipset now works is 
wrong, unless you believe that the 10.1.12.0/24 ip range is not matched, 
in its entirety, by the 10.1.0.0/16 one. Not to mention that the above 
bug is a clear *regression* as the v4.x version of the ipset binary was 
able, for whatever reason , to produce matches - successfully - using ip 
ranges like the one I used as an example in my initial post.

> So even to consider your feature requests, it could come only after 
> implementing element-aggregation.
>   
Again, this is *not* a feature request - it is a bug fix and I think I 
already pointed out above why that is so.