Re: [PATCH 0/3] ipset: change 'iface' part in hash:net,iface set

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

> > Well, in the above example I fail to see where "src,in" == "src,src" - 
> > that is *never* the case!
> >     
>
> According to your patches if list1 contains *only* hash:net,iface type of 
> setst, then "src,in" == "src,src" because
>
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>
> is identical in result with
>
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
>
> However, if list1 contains hash:net,iface type of sets *and* other types 
> as well, then "src,in" != "src,src" because
>
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>
> is not identical in result with
>
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
>
> Moreover, "list1" can be updated with new member sets any time, and 
> depending on the *syntax*, again, the result may change.
>   
You are changing the members of a given set - therefore, the result is 
always bound to be different, no matter what. In such a case all bets 
are off!

When you have different members of a given set of course you are going 
to have different results depending on the parameters you use. A small 
example which comes to mind is how you treat multi-dimensional matches - 
by definition, one has to specify all dimensions in order to get a 
complete match, otherwise that won't happen. No matter how many 2 or 3 
dimensional sets I add to a list:set, I'll get the same number of 
results when I use single dimension for example, simply because of the 
way it works - by definition.

It is the same with 'in' and 'out' - again, by definition, they match 
only on incoming and outgoing interface, nothing else. No matter how 
many members of other set types you add to the list:set, you will always 
get matches against incoming/outgoing interfaces.

So, I fail to see where the confusion or inconsistency is?

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