Due to the restarting bug (add the first element again) and failing as it
is already added, the resizing happened once.
OK, I'll wait for this to be fixed then.
As I wrote, for a few weeks I won't have time to deal with adding new
features.
No worries, I was just not sure why was this dropped as port ranges used
to be part of other sets implemented in this version, not to mention
that these features existed across the board in earlier ipset versions too.
In the meantime I may be sticking with 4.5 until this is implemented as
I have boxes which I cannot upgrade to the new version of ipset due to
constrains with the kernel, so I do not have the appetite, nor desire,
to spend long hours altering my entire build just because the hash:net
set in the new ipset version can't handle ip ranges - it would be a
nightmare to maintain two different build paths simply because of that
single issue. I suspect that was the reason why iptree(map) sets got
"converted" to hash:ip instead of hash:net.
ipset -L on a iptreemap type set tells different - it contains a single
element - 10.1.0.0/16 - and that's it! It is even better because I could use
both forms - cidr and ranges alike - and it shows me the ip address ranges
when I list the actual set. In that respect iptreemap's implementation is much
better than what currently exists with hash:net set in 6.4!
iptreemap is clever enough to collapse the successive elements into ranges
in the output. But internally all network, range added to an iptreemap
type is expanded into the individual IP addresses.
Maybe that would explain the massive amount of time it takes to load all
these address ranges and hog my entire system in the process?
--
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
