Re: [ANNOUNCE] ipset-5.0 released

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

 



On Sun, 19 Dec 2010, Mr Dash Four wrote:

> > > Wouldn't you agree that this is a better solution than registering 
> > > twice as many members in a particular set in order to get the match 
> > > I need?
> > 
> > Given that ports are only meaningful in the context of a protocol I don't
> > think that makes sense.
> You are mistaken! I've never actually stated, nor implied, that protocols are
> 'meaningless' when ports are specified or used - I stated that I am not
> interested in *matching* the protocol as for me this part of the match is
> irrelevant - there are plenty of examples where a particular service can
> employ either tcp or udp protocol on the same port - see below for examples.

I could not come up with a good solution. It is not possible to avoid
double lookup in the set if the elements may have (say hash:ip,port type 
of set) the forms:

ipaddr,tcp:port
ipaddr,udp:port
ipadd,tcpudp:port

But if the double-lookup is required, then better add all tcp and udp port 
variants and go with a single-lookup.

Or if you have uniform ports for all elements, you can use two set 
matches:

ipset create hash:ip ipaddrs
ipset create bitmap:port ports

... -m set --match-set ipaddrs dst -m set --match-set ports dst ...

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" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux