[root@test1 ~]# ipset n test hash:net family inet timeout 0
[root@test1 ~]# ipset a test 10.16.0.0-10.16.255.255
[root@test1 ~]# ipset l test
Name: test
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536 timeout 0
Size in memory: 16832
References: 0
Members:
10.16.0.0/16 timeout 0
[root@test1 ~]# ipset t test 10.16.224.0/24
10.16.224.0/24 is NOT in set test.
[root@test1 ~]# ipset t test 10.16.224.1
10.16.224.1 is in set test.
That is plainly wrong!
No, that's a feature: it makes possible to check from userspace how the
kernel would match an IP address in the set.
You can't be serious! How could this be a "feature"?! It is a bug, clearly!
The /24 subnet (10.16.224.0-10.16.224.255) clearly covers the single IP
address (10.16.224.1) and the test should be positive in both cases, as
the /16 member of the set (10.16.0.0-10.16.255.255) covers both the
single IP address as well as the /24subnet range tested. Apparently,
that seems not to be the case. How am I suppose to test subnet ranges then?
I presume if I have 10.16.224.0/24 as a member and do a test with
10.16.0.0/16 that would also return a negative match, isn't that the case?
Maybe it's badly worded in
the manpage: "When testing entries, if a host address is tested, then the
kernel tries to match the host address in the networks added to the set
and reports the result accordingly."
That's all well and good for hosts, but ip ranges should either be
tested properly or testing of those should be disabled altogether
(which, if introduced, would be a severe restriction for me - I am not
going to run a couple of thousand "ipset t" tests just to see that all
of the single IP addresses in the range I am interested in match - that
simply isn't going to happen!).
--
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
