ipset v6.latest bugs?

ipset v6.latest bugs?

[Mr Dash Four]

I think I have stumbled upon a couple of ipset bugs. Here is what happens:

[root@test1 ~]# ipset -N test hash:ip
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16512
References: 0
Members:
[root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
ipset v6.4: Element cannot be added to the set: it's already added
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 2048 maxelem 65536
Size in memory: 32896
References: 0
Members:
[root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
ipset v6.4: Element cannot be added to the set: it's already added
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 4096 maxelem 65536
Size in memory: 65664
References: 0
Members:
[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:ip
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16512
References: 0
Members:
[root@test1 ~]# ipset -A test 10.4.0.0/14
ipset v6.4: Element cannot be added to the set: it's already added
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 2048 maxelem 65536
Size in memory: 32896
References: 0
Members:
[root@test1 ~]# ipset -A test 10.4.0.0/14
ipset v6.4: Element cannot be added to the set: it's already added
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 4096 maxelem 65536
Size in memory: 65664
References: 0
Members:


Given the above, the following concern me:

1. The maximum number of elements in hash:ip set is 64k, but when I try 
to add more than that I am warned that the element is "already added". 
The error message displayed is misleading as I am not attempting to add 
an element "already added", but exceeding the range of elements 
permitted in this type of set. I think the error message should reflect 
that. This, presumably, happens when there is an overlap, which usually 
occurs when, for example, integer is used instead of long.

2. There seems to be a huge memory leak - don't know whether this is as 
a result of the error in 1 above. When I add elements to hash:ip set and 
then clear the entire set, the "Size in memory" value of the set doubles 
every time I do that (16512 initially, then 32896, 65664 ...). I have 
tried a similar operation with hash:net set, but there is no memory leak 
there at all.

3. Don't know whether this is a bug, but thought to report it too - 
hash:net, different to hash:ip set, seems unable to accept ip ranges 
(10.4.0.0-10.7.255.255 in my example above) - I get an error every time 
I attempt this operation. Could this behaviour be corrected and I am 
allowed to specify ranges please?

I use the geoip database and all ip addresses there are specified as 
ranges. I cannot use hash:ip as, by its very definition, the set is only 
limited to 64k elements (when ip range is specified, ipset uses internal 
"conversion" and adds each ip address from the specified range as a 
separate element). To use some sort of conversion algorithm to change 
these ip ranges to a cidr-type address (as this is what hash:net insists 
on) is going to take a lot of execution time and additional computer 
resources.

4. The "old" format of iptreemap set is automatically converted to an 
hash:ip set. Why? I think that is wrong, given that such a set could 
contain, in all probability, more than 64k individual ip addresses and 
when that limit is reached no elements could then be added.

I think it makes sense if a "conversion" from the old-style format to 
the new one is attempted, to be done properly (or not attempted at all) 
- the only set, which could possibly be able to handle "old-style" 
iptreemap sets is hash:net, but, as it stands, it does not accept 
ipranges (see 3 above).

As a footnote to this, the ipset I used is the latest snapshot from 
yesterday, 24 April as available from kernel.org (for the ipset kernel 
part) and ipset 6.4 (userspace - stripping the kernel part).

Re: ipset v6.latest bugs?

[Jozsef Kadlecsik]

On Mon, 25 Apr 2011, Mr Dash Four wrote:

> I think I have stumbled upon a couple of ipset bugs. Here is what happens:
> 
> [root@test1 ~]# ipset -N test hash:ip
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 16512
> References: 0
> Members:
> [root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
> ipset v6.4: Element cannot be added to the set: it's already added
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 2048 maxelem 65536
> Size in memory: 32896
> References: 0
> Members:
> [root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
> ipset v6.4: Element cannot be added to the set: it's already added
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 4096 maxelem 65536
> Size in memory: 65664
> References: 0
> Members:
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:ip
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 16512
> References: 0
> Members:
> [root@test1 ~]# ipset -A test 10.4.0.0/14
> ipset v6.4: Element cannot be added to the set: it's already added
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 2048 maxelem 65536
> Size in memory: 32896
> References: 0
> Members:
> [root@test1 ~]# ipset -A test 10.4.0.0/14
> ipset v6.4: Element cannot be added to the set: it's already added
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 4096 maxelem 65536
> Size in memory: 65664
> References: 0
> Members:
> 
> 
> Given the above, the following concern me:
> 
> 1. The maximum number of elements in hash:ip set is 64k, but when I try to add
> more than that I am warned that the element is "already added". The error
> message displayed is misleading as I am not attempting to add an element
> "already added", but exceeding the range of elements permitted in this type of
> set. I think the error message should reflect that. This, presumably, happens
> when there is an overlap, which usually occurs when, for example, integer is
> used instead of long.

The default hash size is relatively small: 1024. Therefore it's exhausted 
quite fast when adding so many elements and the hash type tries to solve 
the issue by doubling the hash. However, with the given input you use, it 
is not taken into account that some of the first elements are already 
successfully added to the set, and after resizing, the adding starts with 
the first element again. That is why it fails with a misleading error 
message. It's a non-critical bug, I'll fix it this week.
 
> 2. There seems to be a huge memory leak - don't know whether this is as a
> result of the error in 1 above. When I add elements to hash:ip set and then
> clear the entire set, the "Size in memory" value of the set doubles every time
> I do that (16512 initially, then 32896, 65664 ...). I have tried a similar
> operation with hash:net set, but there is no memory leak there at all.

No, there's no memory leak there: if you check the list of the elements 
you can see that more and more elements could successfully be added to the 
growing hash.
 
> 3. Don't know whether this is a bug, but thought to report it too - hash:net,
> different to hash:ip set, seems unable to accept ip ranges
> (10.4.0.0-10.7.255.255 in my example above) - I get an error every time I
> attempt this operation. Could this behaviour be corrected and I am allowed to
> specify ranges please?

No, because what would be the network you'd want to add to the set then? 
Every /24 in the given range? Or every /16? Or the set type should convert 
the range to a network and add that to the set? And if that can't be 
covered by one network, then add a combination of networks which cover the 
range exactly?
 
> I use the geoip database and all ip addresses there are specified as ranges. I
> cannot use hash:ip as, by its very definition, the set is only limited to 64k
> elements (when ip range is specified, ipset uses internal "conversion" and
> adds each ip address from the specified range as a separate element). To use
> some sort of conversion algorithm to change these ip ranges to a cidr-type
> address (as this is what hash:net insists on) is going to take a lot of
> execution time and additional computer resources.
> 
> 4. The "old" format of iptreemap set is automatically converted to an hash:ip
> set. Why? I think that is wrong, given that such a set could contain, in all
> probability, more than 64k individual ip addresses and when that limit is
> reached no elements could then be added.

Hm, iptreemap should have been limited to 64k elements... That was an 
error on my part, that I forgot to limit that type.

hash:ip type allows more than 64k elements, when defined with a 
non-default "maxelem" parameter.

> I think it makes sense if a "conversion" from the old-style format to the new
> one is attempted, to be done properly (or not attempted at all) - the only
> set, which could possibly be able to handle "old-style" iptreemap sets is
> hash:net, but, as it stands, it does not accept ipranges (see 3 above).
> 
> As a footnote to this, the ipset I used is the latest snapshot from yesterday,
> 24 April as available from kernel.org (for the ipset kernel part) and ipset
> 6.4 (userspace - stripping the kernel part).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset v6.latest bugs?

[Mr Dash Four]

> It's a non-critical bug, I'll fix it this week.
>   
OK, thanks.

>> 2. There seems to be a huge memory leak - don't know whether this is as a
>> result of the error in 1 above. When I add elements to hash:ip set and then
>> clear the entire set, the "Size in memory" value of the set doubles every time
>> I do that (16512 initially, then 32896, 65664 ...). I have tried a similar
>> operation with hash:net set, but there is no memory leak there at all.
>>     
>
> No, there's no memory leak there: if you check the list of the elements 
> you can see that more and more elements could successfully be added to the 
> growing hash.
>   
Yeah, but the set is empty!

It is flushed, so why is it that after the set is cleared (and there are 
no elements in that set!), it still occupies 4 times as much memory it 
had initially with the same number of elements, i.e. zero? If this isn't 
a memory leak it is a very bad practice I would think.

I have just (tried) to add a single /14 net, what's going to happen if I 
add more, much more to it, and then flush the entire set? Would it be 
still occupying that amount of memory then?

>> 3. Don't know whether this is a bug, but thought to report it too - hash:net,
>> different to hash:ip set, seems unable to accept ip ranges
>> (10.4.0.0-10.7.255.255 in my example above) - I get an error every time I
>> attempt this operation. Could this behaviour be corrected and I am allowed to
>> specify ranges please?
>>     
>
> No, because what would be the network you'd want to add to the set then? 
>   
My understanding of hash:net is that it could have various subnets 
registered there; 10.0.4.0/14, 192.1.10.0/24 etc. So, instead of adding 
these by specifying the cidr addresses would it be possible to specify 
their ranges - "10.4.0.0-10.7.255.255" and "192.1.10.0-192.1.10.255" in 
this case? I indicated the reasons for this in my previous post.

> Every /24 in the given range? Or every /16? Or the set type should convert 
> the range to a network and add that to the set? And if that can't be 
> covered by one network, then add a combination of networks which cover the 
> range exactly?
>   
If there are "overlapping" cidr ranges, like with 10.0.0.0-10.0.0.9 
(which, in cidr terms, is "10.0.0.0/29" and "10.0.0.8/31") then 
obviously there will be two elements added - "10.0.0.0/29" and 
"10.0.0.8/31", so I do not understand where the problem is?

>> 4. The "old" format of iptreemap set is automatically converted to an hash:ip
>> set. Why? I think that is wrong, given that such a set could contain, in all
>> probability, more than 64k individual ip addresses and when that limit is
>> reached no elements could then be added.
>>     
>
> Hm, iptreemap should have been limited to 64k elements...
 From my understanding, iptree has this limitation. iptreemap is like 
"hash:net on steroids" :-) (if my understanding of hash:net is correct, 
of course) - I can register any subnet from any subnet range (this is 
the primary reason I use it for storing these, seemingly random, net 
ranges from the geoip database) - it is perfect for the job, save for 
the initial loading time, and its performance is also superb.

>  That was an 
> error on my part, that I forgot to limit that type.
>
> hash:ip type allows more than 64k elements, when defined with a 
> non-default "maxelem" parameter.
>   
So, for the number of disparate net ranges I pick from the geoip 
database (about 30k ranges, not single ip addresses!) what type of set 
should I choose then and can I also specify ip ranges instead of using 
the cidr ip address notation?

Re: ipset v6.latest bugs?

[Jozsef Kadlecsik]

On Mon, 25 Apr 2011, Mr Dash Four wrote:

> > It's a non-critical bug, I'll fix it this week.
> >   
> OK, thanks.
> 
> > > 2. There seems to be a huge memory leak - don't know whether this is as a
> > > result of the error in 1 above. When I add elements to hash:ip set and
> > > then
> > > clear the entire set, the "Size in memory" value of the set doubles every
> > > time
> > > I do that (16512 initially, then 32896, 65664 ...). I have tried a similar
> > > operation with hash:net set, but there is no memory leak there at all.
> > 
> > No, there's no memory leak there: if you check the list of the elements you
> > can see that more and more elements could successfully be added to the
> > growing hash.
> >   
> Yeah, but the set is empty!
> 
> It is flushed, so why is it that after the set is cleared (and there are no
> elements in that set!), it still occupies 4 times as much memory it had
> initially with the same number of elements, i.e. zero? If this isn't a memory
> leak it is a very bad practice I would think.

Hashes are never shrunk. The hash was initiated with the size 1024. Then 
it was doubled, again and again. Even after deleting all the elements, the 
base structures are there, emptied, ready to occupy new elements.
 
> I have just (tried) to add a single /14 net, what's going to happen if I add
> more, much more to it, and then flush the entire set? Would it be still
> occupying that amount of memory then?

Even if you flush the set, there's a real difference in memory usage 
between having an empty set with hash size 1024 or say 16384.

If you don't need a large set anymore, swap it with a smaller one.
 
> > > 3. Don't know whether this is a bug, but thought to report it too -
> > > hash:net,
> > > different to hash:ip set, seems unable to accept ip ranges
> > > (10.4.0.0-10.7.255.255 in my example above) - I get an error every time I
> > > attempt this operation. Could this behaviour be corrected and I am allowed
> > > to
> > > specify ranges please?
> > 
> > No, because what would be the network you'd want to add to the set then?   
> My understanding of hash:net is that it could have various subnets registered
> there; 10.0.4.0/14, 192.1.10.0/24 etc. So, instead of adding these by
> specifying the cidr addresses would it be possible to specify their ranges -
> "10.4.0.0-10.7.255.255" and "192.1.10.0-192.1.10.255" in this case? I
> indicated the reasons for this in my previous post.
> 
> > Every /24 in the given range? Or every /16? Or the set type should convert
> > the range to a network and add that to the set? And if that can't be covered
> > by one network, then add a combination of networks which cover the range
> > exactly?
> >   
> If there are "overlapping" cidr ranges, like with 10.0.0.0-10.0.0.9 (which, in
> cidr terms, is "10.0.0.0/29" and "10.0.0.8/31") then obviously there will be
> two elements added - "10.0.0.0/29" and "10.0.0.8/31", so I do not understand
> where the problem is?

The problem is that at some point the conversion has to be done.
It can be done before feeding the data to ipset too. 
 
> > > 4. The "old" format of iptreemap set is automatically converted to an
> > > hash:ip
> > > set. Why? I think that is wrong, given that such a set could contain, in
> > > all
> > > probability, more than 64k individual ip addresses and when that limit is
> > > reached no elements could then be added.
> > >     
> > 
> > Hm, iptreemap should have been limited to 64k elements...
> From my understanding, iptree has this limitation. iptreemap is like "hash:net
> on steroids" :-) (if my understanding of hash:net is correct, of course) - I
> can register any subnet from any subnet range (this is the primary reason I
> use it for storing these, seemingly random, net ranges from the geoip
> database) - it is perfect for the job, save for the initial loading time, and
> its performance is also superb.

hash:net and iptreemap are quite different. Let's look at 10.1.0.0/16: 
with hash:net that is a single element, interpreted as a network and 
matching all elements in it. In iptreemap, that's 65536 different, 
individual IP addresses.
 
> >  That was an error on my part, that I forgot to limit that type.
> > 
> > hash:ip type allows more than 64k elements, when defined with a non-default
> > "maxelem" parameter.
> >   
> So, for the number of disparate net ranges I pick from the geoip database
> (about 30k ranges, not single ip addresses!) what type of set should I choose
> then and can I also specify ip ranges instead of using the cidr ip address
> notation?

Convert the ranges to networks and use a hash:net type of set. There are 
countless tools to do the conversion. I see that automatic input 
conversion could be a useful feature in ipset but at least for a few weeks 
I'll not be able to deal with it.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset v6.latest bugs?

[Mr Dash Four]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]


>> Yeah, but the set is empty!
>>
>> It is flushed, so why is it that after the set is cleared (and there are no
>> elements in that set!), it still occupies 4 times as much memory it had
>> initially with the same number of elements, i.e. zero? If this isn't a memory
>> leak it is a very bad practice I would think.
>>     
>
> Hashes are never shrunk. The hash was initiated with the size 1024. Then 
> it was doubled, again and again. Even after deleting all the elements, the 
> base structures are there, emptied, ready to occupy new elements.
>   
Right! OK, I just realised that the has value has grown as well, thus 
increasing the memory footprint, which is fair enough i suppose. I also 
assumed that the hash value could double up indefinitely until the 
maxelem is reached, but that turned out not to be the case - the hash 
value doubled up just once:
[root@test1 ~]# ipset -N test hash:ip maxelem 262144
[root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
ipset v6.4: Element cannot be added to the set: it's already added
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -L test
Name: test
Type: hash:ip
Header: family inet hashsize 2048 maxelem 262144
Size in memory: 32896
References: 0
Members:
[root@test1 ~]#

Is this intentional?

Performing the same set of statements as in my initial post, but with 
maxelem 262144 (the number of ip addresses in that range) as well as 
hashsize set to the same number produces no errors and after "flush" the 
hash set uses the same memory footprint as when there were no elements 
stored there.

> If you don't need a large set anymore, swap it with a smaller one.
>   
What happens if this set is used in iptables statements, would this work?

> The problem is that at some point the conversion has to be done.
> It can be done before feeding the data to ipset too. 
>   
So you think it is a good idea for everybody out there using  ipset to 
get some sort of conversion utility so that hash:net is utilised in that 
manner then?

Wouldn't it be better if you could adapt ipset and make it behave the 
same way as it currently does with hash:ip type set in terms of 
specifying members? The same way as you did with specifying port ranges 
as well, not to mention that in versions 4+ that used to also be the 
case. The hash:net type set is the only exception in the whole range of 
sets on offer!

> hash:net and iptreemap are quite different. Let's look at 10.1.0.0/16: 
> with hash:net that is a single element, interpreted as a network and 
> matching all elements in it. In iptreemap, that's 65536 different, 
> individual IP addresses.
>   
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!

> Convert the ranges to networks and use a hash:net type of set. There are 
> countless tools to do the conversion.
There may be, but that isn't the point - do I have to arm myself with 
yet another tool, which would make my job that bit more complicated and 
difficult (not to mention the time I have to spend adapting to this as 
well as further maintaining it!), compared to if I had ipset implemented 
in such a way, that it is flexible enough to accept IP ranges as well as 
those listed with cidr notation - a flexibility which already existed in 
version 4 of the same tool?

> I see that automatic input 
> conversion could be a useful feature in ipset but at least for a few weeks 
> I'll not be able to deal with it.
>   
I am attaching something to this email (though I am not sure whether 
this would be accepted by the mail list daemon!) to get you started if 
you so desire.


[-- Attachment #2: cidr.c --]
[-- Type: text/plain, Size: 5498 bytes --]

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <math.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define IP_BINARY_LENGTH 32+1  /* 32 bits ipv4 address +1 for null */
#define IP_HEX_LENGTH    10   
#define MAX_CIDR_MASK    32
#define MAX_CIDR_LEN     18+1   /* 255.255.255.255/32 */

void rangeToCidr(uint32_t from ,uint32_t to,
                 void (callback)(char *cidrNotation));
int ipToBin(uint32_t ip , char * pOut);

void printNotation(char *cidrNotation);

/*******************************************************************************
*
* ipToBin - convert an ipv4 address to binary representation 
*           and pads zeros to the beginning of the string if 
*           the length is not 32 
*           (Important for ranges like 10.10.0.1 - 20.20.20.20 )
*
* ip   - ipv4 address on host order
* pOut - Buffer to store binary.
*
* RETURNS: OK or ERROR 
*/

int ipToBin(uint32_t ip , char * pOut) {
    char hex[IP_HEX_LENGTH];
    int i;
    int result=0;
    int len;
    char pTmp[2];
    int tmp;
    /*
     * XXX: Could use bit operations instead but was easier to debug
     */
    char binMap[16][5] = { 
                          "0000","0001","0010","0011", "0100",
                          "0101","0110","0111","1000", "1001",
                          "1010","1011","1100", "1101","1110","1111",
                         };
    pTmp[1]=0x0;
    memset(hex,0x0,sizeof(hex));
    len=sprintf(hex,"%x",ip);

    for(i=0;i<len;i++) {

        /* Ugly but to use strtol , we need the last byte as null */
        pTmp[0]=hex[i];
        errno = 0;
        tmp = strtol(pTmp, 0x0, 16);

        /* Should not happen */
        if (errno != 0) {
            memset(pOut,'0',IP_BINARY_LENGTH -1);
            return -1;
        }
        result+=sprintf(pOut+result,"%s",binMap[tmp]);
    }

    /* if length is not 32 , pad the start with zeros*/
    if(result < IP_BINARY_LENGTH-1) {
        char pSwap[IP_BINARY_LENGTH];
        strncpy(pSwap,pOut,IP_BINARY_LENGTH);
        memset(pOut,'0',IP_BINARY_LENGTH);
        strncpy(pOut+IP_BINARY_LENGTH-1-result,pSwap,result);
    } else if (result > IP_BINARY_LENGTH-1)
        return -1;

    /* Success */
    return 0;
}

/*******************************************************************************
*  main : 
* 
*  arg1 : Start IP Address
*  arg2 : End IP address
*/

int main (int argc,char **argv) {
    long fromIp, toIp;
    struct in_addr addr;
    if (argc !=3 ) {
        printf("Usage: %s <from> <to>\n",argv[0]);
        return(0);
    }

    /* All operation on host order */   
    if (inet_aton(argv[1],&addr) == 0)
        goto error;
    fromIp = ntohl(addr.s_addr);

    if (inet_aton(argv[2],&addr) ==0)
        goto error;
    toIp = ntohl(addr.s_addr);

    rangeToCidr(fromIp,toIp,printNotation);

    return 0;
error:
    printf("Invalid Argument\n");
    return -EINVAL;
}


/*******************************************************************************
*
* rangeToCidr - convert an ip Range to CIDR, and call 'callback' to handle
*               the value. 
*
* from     - IP Range start address
* to       - IP Range end address
* callback - Callback function to handle cidr.
* RETURNS: OK or ERROR 
*/

void rangeToCidr(uint32_t from ,uint32_t to,
                 void (callback)(char *cidrNotation)) {
    int     cidrStart = 0;
    int     cidrEnd = MAX_CIDR_MASK - 1;
    long    newfrom;
    long    mask;
    char    fromIp[IP_BINARY_LENGTH];
    char    toIp[IP_BINARY_LENGTH];
    struct  in_addr addr;
    char    cidrNotation[MAX_CIDR_LEN];

    memset (fromIp,0x0,sizeof(fromIp));
    memset (toIp,0x0,sizeof(toIp));

    if ( ipToBin(from,fromIp) != 0 ) 
        return;
    if ( ipToBin(to,toIp) != 0 )
        return;

    if(from < to ) {

        /* Compare the from and to address ranges to get the first
         * point of difference
         */
        while(fromIp[cidrStart]==toIp[cidrStart])
            cidrStart ++;
        cidrStart = 32 - cidrStart -1 ;

        /* Starting from the found point of difference make all bits on the 
         * right side zero 
         */
        newfrom = from >> cidrStart +1  << cidrStart +1;        

        /* Starting from the end iterate reverse direction to find 
         * cidrEnd
         */ 
        while( fromIp[cidrEnd] == '0' && toIp[cidrEnd] == '1')
            cidrEnd --;

        cidrEnd = MAX_CIDR_MASK - 1 - cidrEnd;

        if(cidrEnd <= cidrStart) {
            /* 
             * Make all the bit-shifted bits equal to 1, for
             * iteration # 1.
             */
            mask = pow (2, cidrStart ) - 1;
            rangeToCidr (from , newfrom | mask, callback);
            rangeToCidr (newfrom | 1 <<  cidrStart ,to ,callback);
        } else {
            addr.s_addr = htonl(newfrom);
            sprintf(cidrNotation,"%s/%d", 
                    inet_ntoa(addr), MAX_CIDR_MASK-cidrEnd);
            if (callback != NULL)
                callback(cidrNotation);
        }
    } else {
        addr.s_addr = htonl(from);
        sprintf(cidrNotation,"%s/%d",inet_ntoa(addr),MAX_CIDR_MASK);
        if(callback != NULL)
            callback(cidrNotation);
    }
}

/*******************************************************************************
*
* printNotation - This is an example callback function to handle cidr notation. 
*
* RETURNS:
*/

void printNotation(char *cidrNotation) {
    printf("%s\n",cidrNotation);
}

Re: ipset v6.latest bugs?

[Jozsef Kadlecsik]

On Tue, 26 Apr 2011, Mr Dash Four wrote:

> > > Yeah, but the set is empty!
> > > 
> > > It is flushed, so why is it that after the set is cleared (and there are
> > > no
> > > elements in that set!), it still occupies 4 times as much memory it had
> > > initially with the same number of elements, i.e. zero? If this isn't a
> > > memory
> > > leak it is a very bad practice I would think.
> > 
> > Hashes are never shrunk. The hash was initiated with the size 1024. Then it
> > was doubled, again and again. Even after deleting all the elements, the base
> > structures are there, emptied, ready to occupy new elements.
> >   
> Right! OK, I just realised that the has value has grown as well, thus
> increasing the memory footprint, which is fair enough i suppose. I also
> assumed that the hash value could double up indefinitely until the maxelem is
> reached, but that turned out not to be the case - the hash value doubled up
> just once:
> [root@test1 ~]# ipset -N test hash:ip maxelem 262144
> [root@test1 ~]# ipset -A test 10.4.0.0-10.7.255.255
> ipset v6.4: Element cannot be added to the set: it's already added
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:ip
> Header: family inet hashsize 2048 maxelem 262144
> Size in memory: 32896
> References: 0
> Members:
> [root@test1 ~]#
> 
> Is this intentional?

Due to the restarting bug (add the first element again) and failing as it 
is already added, the resizing happened once. If reissued the

ipset -A test 10.4.0.0-10.7.255.255
ipset -F test
ipset -L test

commands, you'd see that the hash is doubled again.

After the the bug is fixed, the hash will be doubled as many times as 
required and the parameters (maxsize) and physical memory permit.
 
> Performing the same set of statements as in my initial post, but with maxelem
> 262144 (the number of ip addresses in that range) as well as hashsize set to
> the same number produces no errors and after "flush" the hash set uses the
> same memory footprint as when there were no elements stored there.
> 
> > If you don't need a large set anymore, swap it with a smaller one.
> >   
> What happens if this set is used in iptables statements, would this work?

Yes, swapping works with sets in use by iptables rules.
 
> > The problem is that at some point the conversion has to be done.
> > It can be done before feeding the data to ipset too.   
> So you think it is a good idea for everybody out there using  ipset to get
> some sort of conversion utility so that hash:net is utilised in that manner
> then?
> 
> Wouldn't it be better if you could adapt ipset and make it behave the same way
> as it currently does with hash:ip type set in terms of specifying members? The
> same way as you did with specifying port ranges as well, not to mention that
> in versions 4+ that used to also be the case. The hash:net type set is the
> only exception in the whole range of sets on offer!

As I wrote, for a few weeks I won't have time to deal with adding new 
features.
 
> > hash:net and iptreemap are quite different. Let's look at 10.1.0.0/16: with
> > hash:net that is a single element, interpreted as a network and matching all
> > elements in it. In iptreemap, that's 65536 different, individual IP
> > addresses.
> >   
> 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.
 
Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset v6.latest bugs?

[Mr Dash Four]

> 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?

Re: ipset v6.latest bugs?

[Mr Dash Four]

>> 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.
I ran into more problems, unfortunately!

This is what I executed after managing to use the same ipset revisions 
in both the kernel and userspace:

[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -L test
Name: test
Type: hash:net,port
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16760
References: 0
Members:

[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4096
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -terse -L test
Name: test
Type: hash:net,port
Header: family inet hashsize 2048 maxelem 65536
Size in memory: 91448
References: 0

[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-6144
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -terse -L test
Name: test
Type: hash:net,port
Header: family inet hashsize 2048 maxelem 65536
Size in memory: 33144
References: 0
[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4096
[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4352
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4224
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4480
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4544
[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4607

[root@test1 ~]# ipset -F test
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-5119
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-5056
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4865
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
ipset v6.4: Element cannot be added to the set: it's already added

[root@test1 ~]# ipset -X test
[root@test1 ~]# ipset -N test hash:net,port
[root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
ipset v6.4: Element cannot be added to the set: it's already added


As evident from the above, there seem to be some, quite frankly, bizarre 
results:

1. Even though the maxelem value is 64k I seems to be restricted to add 
the amount of elements in the set which do not require the hash value to 
more than double (that may be related to the previous bug with hash:ip 
set though).

2. Take a note when I try to add 4608 elements to the test set - I did 
that 3 times with completely different results - it seems that ipset 
triggers an error when it feels like it.

3. Following on from the previous point, when I try to add more elements 
than the established "error threshold" in point 2 above, I also get 
mixed results (attempting to add 4864 elements gives me 2 successes and 
2 failures after 4 attempts made when I re-created the test set from 
scratch).

I am a bit baffled to say the least why on one occasion I am successful 
in adding more elements while previous attempts with less elements have 
triggered an error (adding 4864 elements successfully - twice, compared 
to 4608 unsuccessfully) - there is absolutely no logic in this!

There seems to be a serious issue or am I missing a trick here?

Re: ipset v6.latest bugs?

[Jozsef Kadlecsik]

On Wed, 27 Apr 2011, Mr Dash Four wrote:

> > > 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.
> I ran into more problems, unfortunately!
> 
> This is what I executed after managing to use the same ipset revisions in both
> the kernel and userspace:
> 
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -L test
> Name: test
> Type: hash:net,port
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 16760
> References: 0
> Members:
> 
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4096
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -terse -L test
> Name: test
> Type: hash:net,port
> Header: family inet hashsize 2048 maxelem 65536
> Size in memory: 91448
> References: 0
> 
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-6144
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -terse -L test
> Name: test
> Type: hash:net,port
> Header: family inet hashsize 2048 maxelem 65536
> Size in memory: 33144
> References: 0
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4096
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4352
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4224
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4480
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4544
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4607
> 
> [root@test1 ~]# ipset -F test
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4608
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-5120
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-5119
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-5056
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4865
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
> ipset v6.4: Element cannot be added to the set: it's already added
> 
> [root@test1 ~]# ipset -X test
> [root@test1 ~]# ipset -N test hash:net,port
> [root@test1 ~]# ipset -A test 10.4.0.0/14,1-4864
> ipset v6.4: Element cannot be added to the set: it's already added
>  
> As evident from the above, there seem to be some, quite frankly, bizarre
> results:
> 
> 1. Even though the maxelem value is 64k I seems to be restricted to add the
> amount of elements in the set which do not require the hash value to more than
> double (that may be related to the previous bug with hash:ip set though).

This is the same bug you discovered last time: the internal restarting 
at adding elements after resizing fails.

Please note, the maxelem parameter has no effect, but the hashsize does: 
if the hash too small, it has to be resized.

> 2. Take a note when I try to add 4608 elements to the test set - I did that 3
> times with completely different results - it seems that ipset triggers an
> error when it feels like it.

The hashes are created with a random hash key calculation parameter: if 
the hash is lucky enough, you can stuff the data into it without reaching 
the clashing limit and without the need to resize the hash.
 
> 3. Following on from the previous point, when I try to add more elements than
> the established "error threshold" in point 2 above, I also get mixed results
> (attempting to add 4864 elements gives me 2 successes and 2 failures after 4
> attempts made when I re-created the test set from scratch).

The same as above: if the clash limit is not reached, the hash happily 
can accept more data. If it's reached, resizing is triggered which is 
successfully done, but adding elements starts again with the already added 
element. That needs to be fixed.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset v6.latest bugs?

[Mr Dash Four]

>> 2. Take a note when I try to add 4608 elements to the test set - I did that 3
>> times with completely different results - it seems that ipset triggers an
>> error when it feels like it.
>>     
>
> The hashes are created with a random hash key calculation parameter: if 
> the hash is lucky enough, you can stuff the data into it without reaching 
> the clashing limit and without the need to resize the hash.
>   
I see, so the error is triggered at random because the randomly 
generated hash sometimes is able to "stuff the data", as you put it, 
without reaching the limit, but sometimes it doesn't and this, then, 
triggers the error, is that correct?

>> 3. Following on from the previous point, when I try to add more elements than
>> the established "error threshold" in point 2 above, I also get mixed results
>> (attempting to add 4864 elements gives me 2 successes and 2 failures after 4
>> attempts made when I re-created the test set from scratch).
>>     
>
> The same as above: if the clash limit is not reached, the hash happily 
> can accept more data. If it's reached, resizing is triggered which is 
> successfully done, but adding elements starts again with the already added 
> element. That needs to be fixed.
>   
I think I understand it now, thanks for the explanation. I hope that you 
would be able to fix this bug.

On a separate note, two days ago I was finally able to split ipset from 
xtables-addons and build it as a separate package (i.e. construct a 
.spec file, then build and install rpm based on that) while building 
only the userspace part (assuming the kernel part will stay with the 
kernel). This is by no means finished (there are some things still left 
to be ironed out - kernel modules dependency check, changelog history to 
be added etc), but I thought you may be interested in this.

If so, let me know and I'll send it to you (the important part is the 
.spec file and a separate patch which removes the build routines for the 
kernel modules).

I am in a process of doing the same with version 4.5 of ipset (I was 
able to successfully build the .35-88 version of the kernel with ipset 
4.5 kernel modules happily integrated into it yesterday), even though 
ipset 4.5 does not have pkgconfig files I intend to create these - 
hopefully today.

Re: ipset v6.latest bugs?

[Jozsef Kadlecsik]

On Wed, 27 Apr 2011, Mr Dash Four wrote:

> > > 2. Take a note when I try to add 4608 elements to the test set - I did
> > > that 3
> > > times with completely different results - it seems that ipset triggers an
> > > error when it feels like it.
> > 
> > The hashes are created with a random hash key calculation parameter: if the
> > hash is lucky enough, you can stuff the data into it without reaching the
> > clashing limit and without the need to resize the hash.
> >   
> I see, so the error is triggered at random because the randomly generated hash
> sometimes is able to "stuff the data", as you put it, without reaching the
> limit, but sometimes it doesn't and this, then, triggers the error, is that
> correct?

Yes, exactly.
 
> > > 3. Following on from the previous point, when I try to add more elements
> > > than
> > > the established "error threshold" in point 2 above, I also get mixed
> > > results
> > > (attempting to add 4864 elements gives me 2 successes and 2 failures after
> > > 4
> > > attempts made when I re-created the test set from scratch).
> > >     
> > 
> > The same as above: if the clash limit is not reached, the hash happily can
> > accept more data. If it's reached, resizing is triggered which is
> > successfully done, but adding elements starts again with the already added
> > element. That needs to be fixed.
> >   
> I think I understand it now, thanks for the explanation. I hope that you would
> be able to fix this bug.

I'm attending an annual conference this week, so it seems I won't have 
time to work on the bugfix before the weekend, sorry.
 
> On a separate note, two days ago I was finally able to split ipset from
> xtables-addons and build it as a separate package (i.e. construct a .spec
> file, then build and install rpm based on that) while building only the
> userspace part (assuming the kernel part will stay with the kernel). This is
> by no means finished (there are some things still left to be ironed out -
> kernel modules dependency check, changelog history to be added etc), but I
> thought you may be interested in this.
> 
> If so, let me know and I'll send it to you (the important part is the .spec
> file and a separate patch which removes the build routines for the kernel
> modules).

I don't really see why you have to split ipset from xtables-addons. What's 
wrong with the standalone ipset package, what forces you to do so?
 
> I am in a process of doing the same with version 4.5 of ipset (I was able to
> successfully build the .35-88 version of the kernel with ipset 4.5 kernel
> modules happily integrated into it yesterday), even though ipset 4.5 does not
> have pkgconfig files I intend to create these - hopefully today.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset v6.latest bugs?

[Mr Dash Four]

>> I think I understand it now, thanks for the explanation. I hope that you would
>> be able to fix this bug.
>>     
>
> I'm attending an annual conference this week, so it seems I won't have 
> time to work on the bugfix before the weekend, sorry.
>   
No worries, I will be using 4.5 for the time being particularly as I was 
finally able to integrate it into the kernel (your "patch_kernel" script 
did the donkey work though :-) ) and I was also able to "convert" ipset 
4.5 to use pkgconfig (still testing it though), so when I am more or 
less done I will be in a position to build (and use!) both generation 
packages as a standalone software.

> I don't really see why you have to split ipset from xtables-addons. What's 
> wrong with the standalone ipset package, what forces you to do so?
>   
I don't actually need xtables-addons for 80% of my boxes, so just 
building the ipset package was perfect! On those machines I used to 
compile xtables-addons just because I needed ipset, so it made more 
sense to use ipset as standalone and save myself the hassle (and some 
resources too).

I planned to do this for months, but wasn't able to due to time 
constraints. I can now afford more time and I am glad I was able to 
finally split it up. I am particularly pleased that I was able to 
integrate it into the kernel, which saved me another headache of having 
to deal with the bl**dy buildsys packages on Fedora which were needed to 
build the kernel modules.