Re: [ANNOUNCE] ipset 6.6 released

[Mr Dash Four <mr.dash.four@googlemail.com>]

> Userspace changes:
>  - Restore with bitmap:port and list:set types did not work, fixed
>   
Having had the chance to test this now, I can say that it works, and 
what's more - the loading performance is much, much better - all my sets 
now load in about 2-3 seconds, while with the 4.5 version it took in 
excess of 10 minutes, completely hogging my CPU in the process. I 
haven't had the chance yet to judge the matching performance, but this 
is what I will do in the coming days.

I have found a bug, however. :-\

When I have multiple sets of different type to restore, each restore 
file normally ends with "COMMIT" statement for ipset to commit the whole 
transaction, or so I thought. If there is a mistake (syntax or any 
other) somewhere in the restore file, which prevents the restore 
process, ipset already commits everything up to that point, which I 
think is wrong.

For example, if I have this:

n privileged-ports bitmap:port range 1-1023 timeout 0
a privileged-ports 1-1023
n test-ports bitmap:port range 12770-19999 timeout 0
a test-ports 20000-30000
a test-ports 19999
n test-port bitmap:port range 29950-29950 timeout 0
a test-port 29950
COMMIT

There is an obvious error in line 4 above ("a test-ports 20000-30000" - 
this is out of the defined range for this set) - ipset should have 
aborted the whole transaction and not committed anything, but in 
practice, privileged-ports set is already registered and its members are 
already added.

Apart from the obvious error of ipset committing before the actual 
"COMMIT" has taken place, this raises another issue when I actually try 
to reload this file - I will get an error straight away as 
privileged-ports is already registered and that shouldn't be the case. 
Thought to let you know.