Re: [ANNOUNCE] ipset-5.0 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 18 Dec 2010, Mr Dash Four wrote:

> > I'm happy to announce the new branch of ipset and release it's first
> > element, ipset-5.0.
> >   
> I see that you have considered my suggestions and added port ranges to the
> hash sets. That will make my job much easier! Thank you!

That was not so hard, I hesitated just a little bit to add new features 
before the release.
 
> Is there any difference between hash:net,ip and hash:ip,port? It seems as
> though I can specify subnets (CIDR format) of different sizes in both sets!

You meant hash:net,port and hash:ip,port. Of course they are different. In 
hash:net,port you can store different sized netblock and port pairs, while 
in hash:ip,port you can store just IP address and port pairs. Let me show 
you an example:

# ipset create foo hash:net,port
# ipset add foo 192.168.0.0/30,80
# ipset list foo
Name: foo
Type: hash:net,port
Header: family inet hashsize 1024 maxelem 65536 
Size in memory: 16792
References: 0
Members:
192.168.0.0/30,tcp:80

# ipset create bar hash:ip,port
# ipset add bar 192.168.0.0/30,80
# ipset list bar
Name: bar
Type: hash:ip,port
Header: family inet hashsize 1024 maxelem 65536 
Size in memory: 16632
References: 0
Members:
192.168.0.0,tcp:80
192.168.0.1,tcp:80
192.168.0.2,tcp:80
192.168.0.3,tcp:80
 
> I also spotted another feature I previously missed when looked at 5.0-pre10 -
> nesting of datatypes (I think the default is 4, which would be enough for 99%
> of cases). That is absolutely brilliant as up until now I have used multiple
> --match-set directives to do that job, which can now be done 'internally' by
> ipset. It also addresses the issue of 'binding' (a feature dropped in earlier
> ipset releases and a feature I badly missed if I am being honest), but the
> implementation this time is much better. This set of features will be put to
> the test as I will be using them quite extensively!

Binding was unfortunately a bad ideas therefore had to be dropped. The 
multidimensional sets and the list of sets fairly well replace it.

> I do have another question however: Currently the protocol part from the port
> ranges (hash sets) is not mandatory. Does that mean that if I omit it then the
> port range is matched *regardless* of the protocol (tcp or udp)? For example,
> if I have 10.1.1.0/24,80 would that match 10.1.1.1:tcp:80 *and*
> 10.1.1.1:udp:80? If so, that is very good news!

No, that's just a shorthand notation. If the protocol is left out then TCP 
is assumed. If you need the same port with TCP and UDP, then you have to 
add both to the set. Just using the examle set bar above:

# ipset add bar 192.168.0.1,tcp:53
# ipset add bar 192.168.0.1,udp:53
# ipset list bar
Name: bar
Type: hash:ip,port
Header: family inet hashsize 1024 maxelem 65536 
Size in memory: 16696
References: 0
Members:
192.168.0.0,tcp:80
192.168.0.1,tcp:53
192.168.0.1,tcp:80
192.168.0.2,tcp:80
192.168.0.1,udp:53
192.168.0.3,tcp:80
 
> I downloaded the source to look at, but won't compile it just yet as I am
> waiting for this version to be integrated in the xtables tree and hoping that
> integration is flawless and without the silly compile-time errors as was the
> case with previous xtables releases (*nudges Jan*).

That won't be so easy for Jan, and it's up to him to decide, which ipset 
tree he wants to support in xtables-addons: the old one which does not 
need kernel patching or the new one with the burden of the netlink.patch.
 
> As part of that process I will try and create the .spec file needed to build
> the Fedora rpm package (it would be for FC13 as I am yet to migrate to FC14)
> and will submit it with them to integrate it with FC as soon as possible.
> 
> Final question from me: As part of the ipset-5.0 package you provide a netlink
> patch file. I have read the README and it seems that the only time that patch
> needs to be applied is if the kernel version is >= 2.6.31. Is that the case
> and are there any other constraints/requirements? Do I apply this patch if the
> kernel version is <= 2.6.31? It is important for me to know the answer to this
> question when I prepare the .spec file for building the rpm for Fedora.

In order to support kernel versions below 2.6.31, I had to add a lot of 
#ifdefs in xt_set.c to support the countless API changes in netfilter 
targets and matches. Hm, maybe I could support kernel releases from 
2.6.24. Below 2.6.24 there are missing netlink definitions as Jan 
mentioned.

Best regards,
Jozsef
-
E-mail  : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux