The latter itself exhausts the maximal number of elements in the set, so
the error message is normal.
Is this a constraint coming from the "maxelem" value or the hash size?
Could this be corrected by increasing either of these?
The way I look at it, the "old" iptree(map) type sets should be converted to
hash:net, not hash:ip to avoid this error.
That's too late, I can't change the mapping from hash:ip to hash:net.
(And if the mapping pointed to hash:net, you were surprised then that
after adding say 192.68.0.0/24 to the set, you couldn't delete 192.68.0.1
from it. :-)
Nope. I am aware that deleting elements in 6.x should be done on the
whole range when added, not just a single ip address (I am now clear as
to why that happens and I think it makes sense in the way it is designed).
If you are to provide "backward" compatibility (or compatibility of any
sort) with iptree(map) sets then you should make sure that at least
members of that type of set could, at least, register without problem
within the new set to which iptree(map) is converted. It seems to me
that is not the case - with 6.5 at least. If it is difficult to maintain
such compatibility you could do what you have already done with the
"bindings" in previous versions of ipset - just drop it and ask users to
switch to the new type. Frankly, it is not that difficult to switch over
to the new type if one is aware of the implications, so it wouldn't be a
big shock.
--
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
