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
