From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mr Dash Four Subject: Re: [PATCH 0/3] ipset: change 'iface' part in hash:net,iface set Date: Mon, 09 Jul 2012 21:19:39 +0100 Message-ID: <4FFB3CDB.80206@googlemail.com> References: <4FF74868.3070303@googlemail.com> <4FF74D5C.6060909@googlemail.com> <4FF752F0.3010007@googlemail.com> <4FF765E7.6020809@googlemail.com> <4FF9852C.7080201@googlemail.com> <4FF9D97D.7040309@googlemail.com> <4FF9DB46.5000302@googlemail.com> <4FFA056C.8000709@googlemail.com> <4FFA08CE.1090406@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netfilter Core Team , Pablo Neira Ayuso , Patrick McHardy To: Jozsef Kadlecsik Return-path: Received: from mail-we0-f174.google.com ([74.125.82.174]:63325 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752968Ab2GIUTn (ORCPT ); Mon, 9 Jul 2012 16:19:43 -0400 Received: by weyx8 with SMTP id x8so1525154wey.19 for ; Mon, 09 Jul 2012 13:19:42 -0700 (PDT) In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: >> Well, in the above example I fail to see where "src,in" == "src,src" - >> that is *never* the case! >> > > According to your patches if list1 contains *only* hash:net,iface type of > setst, then "src,in" == "src,src" because > > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT > > is identical in result with > > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT > > However, if list1 contains hash:net,iface type of sets *and* other types > as well, then "src,in" != "src,src" because > > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT > > is not identical in result with > > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT > > Moreover, "list1" can be updated with new member sets any time, and > depending on the *syntax*, again, the result may change. > You are changing the members of a given set - therefore, the result is always bound to be different, no matter what. In such a case all bets are off! When you have different members of a given set of course you are going to have different results depending on the parameters you use. A small example which comes to mind is how you treat multi-dimensional matches - by definition, one has to specify all dimensions in order to get a complete match, otherwise that won't happen. No matter how many 2 or 3 dimensional sets I add to a list:set, I'll get the same number of results when I use single dimension for example, simply because of the way it works - by definition. It is the same with 'in' and 'out' - again, by definition, they match only on incoming and outgoing interface, nothing else. No matter how many members of other set types you add to the list:set, you will always get matches against incoming/outgoing interfaces. So, I fail to see where the confusion or inconsistency is?