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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
