So I have to repeat again: your patches do not address the example of the
two rules with list:set type of sets, which give different results
depending on "in/out" or "src/dst" in the second direction position.
How many times would you like me to repeat this: they give "different
results" because you are applying direction parameters which have
different meanings by definition: "in" means "match on incoming
interfaces *only*", "out" means "match on outgoing interface *only*",
while "src" and "dst" do not have that restriction. This is how it
works, by definition (if you know any different, please let me know).
This was stated from the outset in my patches and in the various man
pages. So, given that in != src and out != dst (the same way as src !=
dst for example), one should not be surprised to get "different results"
when different direction parameters are used (or direction parameters,
which have different meaning). Simple logic and common sense will tell
you all that.
To reiterate once again - 'in' is for matches of incoming interfaces
only and should only be used for that particular purpose (it is one
reason why I am dead against your idea for this to be used "everywhere"
- to answer your other query below). Similar with 'out', but for
outgoing interfaces.
In the given example, in rule level, there is no hash:net,iface type of
set. Still, the result depends on the syntax.
Please clarify, what "given example"?
I wait for a better solution, which does not produce different results
depending on the "in/out" or "src/dst" syntax, for all set types,
including the list of sets.
Again, you get "different results" because you apply direction
parameters which have different meaning - by definition (see above if
you are still "confused" what the definition of 'in' and 'out' is). So,
to summarise, again, for your own benefit:
- "in" means match on incoming interface only;
- "out" means match on outgoing interface only;
Example: If list1 - list:set type of set has, say, 5 members: iface1 and
iface2 - type hash:net,iface, and ipp1, ipp2 and ipp3 - type
hash:ip,port, then the following iptables statement:
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
will only match packets on src IP address/subnet (the 1st direction
parameter) and the incoming interface (the 2nd direction parameter) -
nothing else, simply because of the definition of the second parameter -
"in" above, means "match on incoming interfaces only". In other words,
the above statement will produce matching members of iface1 and iface2,
while members of ipp1, ipp2 and ipp3 will be excluded from the match,
quite naturally. However,
iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
will match packets on source IP address/subnet (1st direction
parameter), 'src' interface (which you defined to mean incoming
interface) as well as source ports (2nd direction parameter), simply
because 'src' has a different definition from that of 'in' - it is more
broad and does not have the restriction 'in' has.
So, given the above, I fail to see how by applying direction parameters
with different meanings (by definition) surprises you, "confuses" you or
is in any way inconsistent when it produces different results for
different set members, but if you know any different I am all eyes/ears!
--
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
