Re: [PATCH v2 3/3] ipset: change 'iface' part in hash:net,iface set
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
This is a "brief" summary of what we discussed with regards to the 'in' and 'out' options since I submitted the patches initially:Now that the latter is being resolved via the get_set_byname_with_features function, I would still like to keep this and relax the restriction for 'in' and 'out' on the list:set as I am yet to get a reasonable and adequate explanation as to why that should not be allowed (the use of 'in' and 'out' in list:set)?Go back and read my answer. I won't repeat myself any more again and again and again.
06/07/2012 ~~~~~~~~~~ JK: You must handle the case of the list:set type: how should then the new JK: "in", "out" be interpreted? Or should those be rejected? But then it'dJK: mean that if someone used a hash:net,iface type as a member of list:set,
JK: then he is forced to use "src", "dst" only. JK: much simpler to introduce the keywords as aliases, all over: JK: "in" as "dst" and "out" as "src"Me: Definition of 'in' and 'out' - to match against network interfaces. Nothing else! Me: It doesn't make sense at all to be used anywhere else - if they are allowed to Me: be used to specify source/destination ip addresses/subnets, protocols or ports,
Me: this would be completely nonsensical.Me: "list1 src,in" - *only* match packets against members of list1 which have a
Me: matching source IP address and incoming interface;Me: "list1 src,src" - match packets against *all* members of list1 which have a Me: matching source IP address, incoming interface as well as src port values.
JK: ...creates more confusion for the users than the current state: one JK: had to keep in mind what kind of sets are stored in a list of sets and JK: depending on them, use "src/dst" or "in/out" in the second direction JK: parameter. And additionally, JK: JK: "list1 src,src" JK: and JK: "list1 src,in" JK:JK: produced different results for the same member sets with the same elements
JK: against the same packets. This is unacceptable for me.Me: Please explain the 'confusion' bit? I've made it quite clear in the definition Me: of 'in' and 'out' - 'in' is meant for a match on the 'incoming', 'out' on Me: the 'outgoing' interfaces. If one wishes to produce a match against those Me: interfaces, then 'in' and 'out' is one possible way to go, if not - then use
Me: 'src' or 'dst' if you feel more comfortable with it.Me: You can't expect to issue two different iptables statements and get the same Me: number of matches! By the same token, if I execute the following two statements:
Me: "list1 src,src" Me: and Me: "list1 src,dst"Me: will also produce "different results for the same member sets with the same Me: elements against the same packets". So why is this not "unacceptable" then?
JK: list1 src,src JK: list1 src,in JK: JK: the underlying set types "decide" how to act to "src/in", when actually JK: "src" == "in".But "list1" is a list type of set, not hash:net,iface. JK: Still, the result is different.Me: Whoever produces the above statements is making a concious decision on what to
Me: use/deploy ... my patch series are offering a choice. JK: Your example is wrong, because the effect of two command are of course JK: different.JK: But what I gave above, the results depends from the type of the members of
JK: the set list, which is invisible in the command line. Even if it's JK: stressed in the manpage that "in" is equivalent with "src" but just forJK: the hash:net,iface type, that is an equivalency and users will expect the
JK: same result for the cited commands. And they're right. Me: It is quite visible as the 'in' bit suggests (similar to the 'dst' bit).Me: 'In' is defined as match on incoming interface only - if that is not clear, Me: then it should be made clear...How would one expect a match on "income interface only" Me: with a match on "source ip addresses, source subnets, source ports, source
Me: everything else you care to mention ... and income interface" to be an Me: "equivalent"? it isn't - not in a million years!JK: You want a choice to be introduced which lead to confusion - I'm repeating
JK: it countless times and you just ignore it. In order to prevent suchJK: confusions, I offered that let "in/out" be alias to "src/dst": accepted as
JK: input everywhere but printed/saved with hash:net,iface only. You pointJK: blank refused it. Then come up with a better solution than the submitted
JK: one.Me: How am I ignoring it? I asked you before and I am asking you again to explain Me: what that "confusion" is? It is quite clear to me what the meaning of "in" and
Me: "out" is ... if there is something "confusing" in that meaning,Me: then I'd like to know. As for your suggestion above, I'll repeat what I've Me: already posted - of course I'll refuse it, because it is completely nonsensical. Me: Do you not think that referring to a destination IP address, for example,
Me: as "out" IP address isn't confusing in the slightest? 07/07/2012 ~~~~~~~~~~ JK: ...your patches do not address the example of the JK: two rules with list:set type of sets, which give different results JK: depending on "in/out" or "src/dst" in the second direction position. JK: In the given example, in rule level, there is no hash:net,iface type ofJK: set. Still, the result depends on the syntax. I wait for a better solution,
JK: which does not produce different results depending on the "in/out" or JK: "src/dst" syntax, for all set types, including the list of sets ... JK: and where both syntax is accepted. 08/07/2012 ~~~~~~~~~~Me: If you know of a case where 'in' or 'out' direction parameters "are accepted" Me: and produce "different results" (by "different results" I mean different from
Me: their own definition - match on incoming/outgoing interfaces only), Me: then, by all means, let me know. JK: list1 src,src JK: list1 src,in JK: would produce different results and that's unacceptable. Me: Why not? JK: Because that's too subtle, error prone and hard to catch if not usedJK: really intentionally. Because that's illogical. Because there are a couple
JK: of ways to avoid it. Me: If I use 'src,dst' instead of 'src,src' would you considerMe: this "error prone", "hard to catch" or not? What do you see as "illogical"?
Me: Avoid what exactly? Using 'in' or 'out' in list:set types? JK: "src,src" != "src,dst", but JK: with your patches in some cases JK: "src,in" == "src,src" or "src,in" != "src,src" Me: Could you provide me with an example please? I am intrigued! JK: This is ridiculous, as if I haven't provided it countless times: JK: list1 src,src JK: list1 src,in Me: Well, in the above example I fail to see where "src,in" == "src,src" - Me: that is *never* the case!JK: According to your patches if list1 contains *only* hash:net,iface type of
JK: setst, then "src,in" == "src,src" because JK: JK: list1 src,in JK: JK: is identical in result with JK: JK: list1 src,src JK:JK: However, if list1 contains hash:net,iface type of sets *and* other types
JK: as well, then "src,in" != "src,src" because JK: JK: list1 src,in JK: JK: is not identical in result with JK: JK: list1 src,src JK: 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. In such a case all bets are off! Me:Me: When you have different members of a given set of course you are going to Me: have different results depending on the parameters you use. A small example Me: which comes to mind is how you treat multi-dimensional matches - by definition, Me: one has to specify all dimensions in order to get a complete match, otherwise Me: that won't happen. No matter how many 2 or 3 dimensional sets I add to a list:set, Me: I'll get the same number of results when I use single dimension for example,
Me: simply because of the way it works - by definition. Me:Me: It is the same with 'in' and 'out' - again, by definition, they match only on Me: incoming and outgoing interface, nothing else. No matter how many members of
Me: other set types you add to the list:set, you will always get matches Me: against incoming/outgoing interfaces. Me: Me: So, I fail to see where the confusion or inconsistency is? And also...Me: you get "different results" because you apply direction parameters which have Me: different meaning - by definition. So, to summarise, again, for your own benefit:
Me: Me: - "in" means match on incoming interface only; Me: - "out" means match on outgoing interface only; Me:Me: Example: If list1 - list:set type of set has, say, 5 members: iface1 and iface2 -
Me: type hash:net,iface, and ipp1, ipp2 and ipp3 - type hash:ip,port, Me: then the following iptables statement: Me: Me: list1 src,in Me:Me: will only match packets on src IP address/subnet (the 1st direction parameter) and Me: the incoming interface (the 2nd direction parameter) - nothing else, simply because Me: of the definition of the second parameter - "in" above, means "match on incoming Me: interfaces only". In other words, the above statement will produce matching members Me: of iface1 and iface2, while members of ipp1, ipp2 and ipp3 will be excluded
Me: from the match, quite naturally. However, Me: Me: list1 src,src Me:Me: will match packets on source IP address/subnet (1st direction parameter), 'src' Me: interface (which you defined to mean incoming interface) as well as source ports Me: (2nd direction parameter), simply because 'src' has a different definition from Me: that of 'in' - it is more broad and does not have the restriction 'in' has.
Me:Me: So, given the above, I fail to see how by applying direction parameters with different Me: meanings (by definition) surprises you, "confuses" you or is in any way inconsistent Me: when it produces different results for different set members, but if you know any
Me: different I am all eyes/ears!So, we started off with you being unhappy with users being "forced" to use src/dst only on list:set types (ahem :-) !) and your suggestion to use in/out everywhere - in every set and in every direction parameter.
Then you became "confused" because users, apparently, need to keep track of what kind of sets are stored in a list:set to do the matching, despite the clear definition of what in/out means and what it matches against (and despite myself reciting that same definition to you on at least 5 occasions). Also, the irony of you suggesting to use in/out everywhere - in every set and every conceivable direction parameter - and not see how confusing that could be for the end user was completely lost on you, it seems.
We then moved on to your "inconsistency" claim and the example where "list1 src,src" and "list1 src,in", apparently, "produced different results for the same member sets with the same elements against the same packets" and that was to you, of course, "unacceptable".
Please note the use of "same member sets" and "same elements" phrase above, because when I showed you that the examples I have given throughout are pretty consistent with the use and definition of 'in' and 'out', you then moved the goal posts yet again, quickly changed the above stance and decided to suddenly start deleting members of the same list1 set and add new ones to fit your argument again (so much for "same members set" and "same elements" then, eh?) - see your last post on 08/07 above if you think that I am making things up. And of course you decided to conveniently ignore the last two posts from me on 09 July (above) when I challenged you on this.
So, what should I "go back and read" exactly?The fact that you are, apparently, unable to grasp the definition of 'in' and 'out' and its proposed use, despite myself having to recite it for you on at least 5 occasions in the past couple of days, or the fact that you are unwilling or unable to hold an argument, scurrying around moving the goal posts every time I dig a gaping hole in your claims?
The proposed definition and use of 'in' and 'out' is quite clear - it is to match on incoming and outgoing interfaces only.
There are just two sets where this option could be used and deployed (in addition to the "standard" src/dst): hash:net,iface, because by definition, this set can hold interface names; and list:set, because, by extension, this type of set could have a member which is of type hash:net,iface and therefore specifying in/out makes perfect sense there. The list:set type does not match on set member names, it matches on set members' members, if that makes sense, so specifying 'in' and 'out' should be allowed there, as is the case with hash:net,iface type sets.
Since none of the other sets can have interfaces specified in them, it does not make any sense whatsoever for 'in' and 'out' to be used there!
This was one of the minor issues I have corrected with version 2 of the patches, because even though no matching on interfaces was allowed in those "other" type of sets, input of 'in' and 'out' was still allowed simply because iptables did not have the means to find out what kind of set it was dealing with - this was corrected in version 2 of the patchset with the introduction of the new get_set_byname_with_features function.
-- 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
[Netfitler Users] [LARTC] [Bugtraq] [Yosemite Forum] [Photo]