You stated: "I fail to see where "src,in" == "src,src" - that is *never*
the case!".
I provided an example, and you simply skipped the answer and made no
effort to understand it.
I responded to that point of yours the very next day (see my two posts
of 09 July if you are "confused") - you can't expect to get the same
results when you alter the members of a given set. Not to mention your
earlier - contradictory - claim to use "same member sets" and "same
elements", which isn't the case with your example given below. As I
posted previously, you are moving the goal posts to suit your arguments
with zero self-awareness.
JK: Moreover, "list1" can be updated with new member sets any time, and
JK: depending on the *syntax*, again, the result may change.
09/07/2012
~~~~~~~~~~
Me: You are changing the members of a given set - therefore, the result is
always
Me: bound to be different, no matter what.
[...]
Here again, no effort on your part to understand the case, just a
ridiculous comment.
Just for you, just for one time, because it seems you do not want to get
it at all, let the last case *also* be expressed, letter by letter.
Let there be four sets:
list1 is list:set type
ip0 is say hash:ip type
netiface0 is hash:net,iface type
ipport0 is hash:ip,port type
list1 is empty and ip0, netiface0 and ipport0 have got elements.
We have an iptables rule matching list1, which - according to you - could
be expressed using "src/dst" or "in/out" syntax.
The two are not equivalent and are not always interchangeable - I get
the feeling I am not repeating this for a first time.
a. iptables -m set --match set list1 src,dst -j ACCEPT
OR
b. iptables -m set --match set list1 src,out -j ACCEPT
1. step
ipset add list1 ip0
Rule a. and rule b. produce exactly the same result.
That is simply because the second dimension parameter is ignored (I
could put "src,mickey_mouse" for all I care and compare it to "src,dst"
- it will always produce the same result, simply because all set members
of list1 are one-dimensional and the second direction parameter is
always ignored - by definition). Show me where the "inconsistency" or
the "confusion" is here then?
2. step
ipset add list1 netiface0
Rule a. and rule b. still produce exactly the same result.
They do, because src/dst is equivalent to in/out for hash:net,iface type
set- by definition. Show me where the "inconsistency" or the "confusion"
is here then?
3. step
ipset add list1 ipport0
From now on, rule a. and rule b. can produce different results.
And that is because the second dimension parameter is accounted for and
you have a member of the list1 set which is not of type hash:net,iface -
that is where the definition of in/out are different. Show me where the
"inconsistency" or the "confusion" is here then?
4. step
ipset del list1 netiface0
Rule a. and rule b. produce again the same result.
Oh yeah? Are you for real? They produce different results! The reason
for that is because the second dimension ('dst' and 'out') differ - by
definition - for sets other than hash:net,iface, which is the case here
(ipport0 is still a member of list1) - the same as step 3 above. Show me
where the "inconsistency" or the "confusion" is here then?
That is exactly what I originally wrote, even highlighted the important
factor: "Moreover, "list1" can be updated with new member sets any time,
and depending on the *syntax*, again, the result may change."
See above - you can't expect to get the same results when you alter the
members of a given set. I also fail to see where the "inconsistency"
with regards to the use of 'in' and 'out' is either - to only match
against incoming/outgoing interfaces, which is the case with steps 3 & 4
above - you add hash:ip,port set (and keep it there) and that is not
matched by 'out' (2nd dimension parameter). If you still fail to grasp
what the definition of 'in' and 'out' is, then I am afraid you are truly
lost.
In all other cases you either have the second dimension completely
ignored - by definition (see my "mickey_mouse" example above) or you use
hash:net,iface sets where src/dst and in/out are equivalent - by definition.
The results only differ when the second dimension parameter is not
ignored and you have sets in list:set which are not of hash:net,iface
type - that is to be expected as in/out, when accounted for (and not
ignored!) have different meaning for these type of sets.
To repeat what I've said above - given the definition of in/out, show me
where the "inconsistency" or the "confusion" is and I'll concede that
particular argument.
I'm awaiting your patches. If my comments are handled properly (and no
other, including coding style mistakes are there), I'll apply them.
Otherwise your patches will be rejected, with terse comments.
Unless I get a reasonable explanation (either from you or anyone else
following this) as to what is wrong with allowing 'in' and 'out' to be
used in the list:set (in addition to hash:net,iface sets) and where the
"inconsistency" and "confusion" is, as you claimed before, I will be
submitting the new set of patches with that option activated so that
one has a choice of using 'in' and 'out' where it makes sense: in
hash:net,iface as well as list:set type of sets.
--
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
