Your example is wrong, because the effect of two command are of course
different.
So are yours as well, quite evidently. See my previous reply to Maciej.
But what I gave above, the results depends from the type of the members of
the set list, which is invisible in the command line.
It is quite visible as the 'in' bit suggests (similar to the 'dst' bit).
Even if it's
stressed in the manpage that "in" is equivalent with "src" but just for
the hash:net,iface type,
'In' is defined as match on incoming interface only - if that is not
clear, then it should be made clear (again, I draw similarities with
your clarifications of 'src' and 'dst' of the very same issue during the
last ipset update you've made).
Again, this is a choice for people who understand that choice - if
someone is uncomfortable with that choice, then s/he is free not to use
it. if I, on the other hand, am not comfortable with using 'src' and
'dst' for interface matching (I am sure I am not the only one!) then
there is a help at hand with the above choice.
that is an equivalency and users will expect the
same result for the cited commands. And they're right.
How so? How would one expect a match on "income interface only" with a
match on "source ip addresses, source subnets, source ports, source
everything else you care to mention ... and income interface" to be an
"equivalent"? it isn't - not in a million years!
--
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
