Re: [ANNOUNCE] ipset 6.11 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 ( in my example - i.e. looping from until 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" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Netfilter Development]     [Linux Kernel Networking Development]     [Linux Networking Development]     [Linux Kernel Development]     [Linux Resources]     [LARTC]     [Bugtraq]     [Consulting]     [Free Internet Dating]     [Yosemite Forum]     [Photo]

Add to Google Powered by Linux