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