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

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

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