Re: [ANNOUNCE] ipset 6.11 released

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

>> One other thing: *if* ipset can only accept single IP addresses instead 
>> of IP ranges (I don't believe this to be the case, but anyway, if it 
>> does), then you could process a single IP address in a loop containing 
>> the whole range to be tested (10.1.12.0/24 in my example - i.e. looping 
>> from 10.1.12.0 until 10.1.12.255 inclusive) and bail out as soon as 
>> there is no match, which would then return 'false' (i.e. no match). You 
>> could even speed things up a bit by implementing batch processing of IP 
>> ranges internally (via a single kernel APIs instead of looping via ipset 
>> and calling the kernel API each time for a single IP address check).
>>
>> I know this implementation is a bit crude, but since this testing takes 
>> place in userspace then this delay won't matter *that* much. How doable 
>> is that?
>>     
>
> The userspace testing is passed to the kernel for execution. There's no
> shadow or backup or whatever set in userspace. The sets exist in kernel 
> space and therefore all operations happen there.
>   
So, is the above doable in any shape or form or not?

> Why do you need such tests at all?
>   
Various reasons. Two common uses (at least in my case) would be to test 
ip range against quite a large set of registered subnets (taken from the 
geoip database and sorted using my own criteria). The tested ip range is 
either candidate to 1). ban that network, in which case I do not want 
duplicates if the existing range is already there; or 2) include the ip 
range in a separate set, making sure that it is not already in the 
'banned' set and also that it is not already included in the 'customer' 
set (which although limited, has quite significant number of set members 
- usually small subnets).

Because the ip range in ipset is not working correctly, I had to first 
manually go over the testing ranges. Later on I devised a small shell 
script doing what I just described in my previous post (quoted above), 
but it is quite ugly and inefficient - it would be much better if ip 
range testing in ipset was functioning properly, saving me all this hassle.