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

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

[Mr Dash Four]

The following series of 3 patches included in this set allow 'in' or 'out' values to be specified for the 'iface' part of hash:net,iface set, corresponding to the  incoming and outgoing interface accordingly, thus eliminating the discrepancy which, up until now, existed with the 'old' format and also reinforcing much-needed consistency with the rest of the netfilter/iptables terminology.

For backwards compatibility, the 'old' format, comprising of 'src' (incoming) and 'dst' (outgoing) direction parameter for the 'iface' part of hash:net,iface is also supported.

The first patch updates iptables (userspace), the second - ipset (userspace), while the last one deals with the rest of the updates to ipset in kernel space, enabling the above functionality.
 
Example of use:

iptables -A INPUT -m set --match-set test src,in
iptables -A OUTPUT -m set --match-set test dst,out

The first example above produces a packet match, based on source IP address/subnet and the incoming interfice (i.e. the 'src' interface in old speak), while the second one does the same, but for the destination IP address/subnet and the outgoing interface ('dst' using the old format). 

The above two examples also assume that the 'test' set exists and is of type hash:net,iface, otherwise NO match is ever produced.


-- 
1.7.10.4

[PATCH 1/3] iptables: change 'iface' part in hash:net,iface set

[Mr Dash Four]

Userspace changes to iptables, allowing 'in' and 'out' values to be
specified for the 'iface' part of hash:net,iface type sets.

Man pages updated accordingly. This patch also makes some minor
corrections to the syntax of some console messages produced by
the set match and SET target.

Signed-off-by: Mr Dash Four <mr.dash.four@googlemail.com>
---
 extensions/libxt_SET.c                 |    7 ++++++-
 extensions/libxt_SET.man               |   23 ++++++++++++-----------
 extensions/libxt_set.c                 |   11 ++++++++---
 extensions/libxt_set.h                 |   10 +++++++---
 extensions/libxt_set.man               |   20 +++++++++-----------
 include/linux/netfilter/ipset/ip_set.h |    5 +++++
 6 files changed, 47 insertions(+), 29 deletions(-)

diff --git a/extensions/libxt_SET.c b/extensions/libxt_SET.c
index a11db39..d9f60c9 100644
--- a/extensions/libxt_SET.c
+++ b/extensions/libxt_SET.c
@@ -206,15 +206,20 @@ print_target(const char *prefix, const struct xt_set_info *info)
 {
 	int i;
 	char setname[IPSET_MAXNAMELEN];
+	char *ptr;
 
 	if (info->index == IPSET_INVALID_ID)
 		return;
 	get_set_byid(setname, info->index);
 	printf(" %s %s", prefix, setname);
 	for (i = 1; i <= info->dim; i++) {
+		if ((info->flags & IPSET_DIM_IFACE_INOUT) && i == IPSET_DIM_TWO)
+			ptr = (info->flags & (1 << i) ? "in" : "out");
+		else
+			ptr = (info->flags & (1 << i) ? "src" : "dst");
 		printf("%s%s",
 		       i == 1 ? " " : ",",
-		       info->flags & (1 << i) ? "src" : "dst");
+			ptr);
 	}
 }
 
diff --git a/extensions/libxt_SET.man b/extensions/libxt_SET.man
index 63eb383..747235f 100644
--- a/extensions/libxt_SET.man
+++ b/extensions/libxt_SET.man
@@ -1,25 +1,26 @@
-This modules adds and/or deletes entries from IP sets which can be defined 
+This module adds and/or deletes entries from IP sets which can be defined 
 by ipset(8).
 .TP
 \fB\-\-add\-set\fP \fIsetname\fP \fIflag\fP[\fB,\fP\fIflag\fP...]
-add the address(es)/port(s) of the packet to the sets
+add the address(es)/port(s) of the packet to the set
 .TP
 \fB\-\-del\-set\fP \fIsetname\fP \fIflag\fP[\fB,\fP\fIflag\fP...]
-delete the address(es)/port(s) of the packet from the sets
+delete the address(es)/port(s) of the packet from the set
 .IP
-where flags are
+where 'flag' above is comma separated list of
 .BR "src"
 and/or
 .BR "dst"
-specifications and there can be no more than six of them.
+with the exception of hash:ip,iface where in addition to the above flags, the following is also allowed for the 'iface' part of that set:
+.BR "in"
+or
+.BR "out" 
+corresponding to the incoming or outgoing network interface. The above flags cannot exceed six in total for a given set.
 .TP
 \fB\-\-timeout\fP \fIvalue\fP
-when adding entry, the timeout value to use instead of the default
-one from the set definition
+when adding an entry, the timeout value to use instead of the default one from the set definition.
 .TP
 \fB\-\-exist\fP
-when adding entry if it already exists, reset the timeout value
-to the specified one or to the default from the set definition
+when adding an entry, if such entry already exists, reset the timeout value to the specified one or to the default from the set definition.
 .PP
-Use of -j SET requires that ipset kernel support is provided, which, for
-standard kernels, is the case since Linux 2.6.39.
+Use of -j SET requires that ipset kernel support is provided, which, for standard kernels, is the case since Linux 2.6.39.
diff --git a/extensions/libxt_set.c b/extensions/libxt_set.c
index 77e3f07..ba478ed 100644
--- a/extensions/libxt_set.c
+++ b/extensions/libxt_set.c
@@ -60,7 +60,7 @@ set_parse_v0(int c, char **argv, int invert, unsigned int *flags,
 	case '2':
 		fprintf(stderr,
 			"--set option deprecated, please use --match-set\n");
-	case '1':		/* --match-set <set> <flag>[,<flag> */
+	case '1':		/* --match-set <set> <flag>[,<flag>] */
 		if (info->u.flags[0])
 			xtables_error(PARAMETER_PROBLEM,
 				      "--match-set can be specified only once");
@@ -140,7 +140,7 @@ set_parse_v1(int c, char **argv, int invert, unsigned int *flags,
 	case '2':
 		fprintf(stderr,
 			"--set option deprecated, please use --match-set\n");
-	case '1':		/* --match-set <set> <flag>[,<flag> */
+	case '1':		/* --match-set <set> <flag>[,<flag>] */
 		if (info->dim)
 			xtables_error(PARAMETER_PROBLEM,
 				      "--match-set can be specified only once");
@@ -175,6 +175,7 @@ print_match(const char *prefix, const struct xt_set_info *info)
 {
 	int i;
 	char setname[IPSET_MAXNAMELEN];
+	char *ptr;
 
 	get_set_byid(setname, info->index);
 	printf("%s %s %s",
@@ -182,9 +183,13 @@ print_match(const char *prefix, const struct xt_set_info *info)
 	       prefix,
 	       setname); 
 	for (i = 1; i <= info->dim; i++) {		
+		if ((info->flags & IPSET_DIM_IFACE_INOUT) && i == IPSET_DIM_TWO)
+			ptr = (info->flags & (1 << i) ? "in" : "out");
+		else
+			ptr = (info->flags & (1 << i) ? "src" : "dst");
 		printf("%s%s",
 		       i == 1 ? " " : ",",
-		       info->flags & (1 << i) ? "src" : "dst");
+		       ptr);
 	}
 }
 
diff --git a/extensions/libxt_set.h b/extensions/libxt_set.h
index 47c3f5b..23830b2 100644
--- a/extensions/libxt_set.h
+++ b/extensions/libxt_set.h
@@ -115,7 +115,7 @@ parse_dirs_v0(const char *opt_arg, struct xt_set_info_v0 *info)
 			info->u.flags[i++] |= IPSET_DST;
 		else
 			xtables_error(PARAMETER_PROBLEM,
-				"You must spefify (the comma separated list of) 'src' or 'dst'.");
+				"You must specify (comma separated list of) 'src' or 'dst'.");
 	}
 
 	if (tmp)
@@ -135,11 +135,15 @@ parse_dirs(const char *opt_arg, struct xt_set_info *info)
 	while (info->dim < IPSET_DIM_MAX && tmp != NULL) {
 		info->dim++;
 		ptr = strsep(&tmp, ",");
-		if (strncmp(ptr, "src", 3) == 0)
+		if (strncmp(ptr, "in", 2) == 0 && info->dim == IPSET_DIM_TWO)
+			info->flags |= (1 << info->dim | IPSET_DIM_IFACE_INOUT);
+		else if (strncmp(ptr, "out", 3) == 0 && info->dim == IPSET_DIM_TWO)
+			info->flags |= IPSET_DIM_IFACE_INOUT;
+		else if (strncmp(ptr, "src", 3) == 0)
 			info->flags |= (1 << info->dim);
 		else if (strncmp(ptr, "dst", 3) != 0)
 			xtables_error(PARAMETER_PROBLEM,
-				"You must spefify (the comma separated list of) 'src' or 'dst'.");
+				"You must specify (comma separated list of) 'src' or 'dst' with the addition of 'in' or 'out' for the interface part of hash:net,iface set, if used.");
 	}
 
 	if (tmp)
diff --git a/extensions/libxt_set.man b/extensions/libxt_set.man
index 1ad9085..31be0eb 100644
--- a/extensions/libxt_set.man
+++ b/extensions/libxt_set.man
@@ -1,22 +1,20 @@
 This module matches IP sets which can be defined by ipset(8).
 .TP
 [\fB!\fP] \fB\-\-match\-set\fP \fIsetname\fP \fIflag\fP[\fB,\fP\fIflag\fP]...
-where flags are the comma separated list of
+where 'flag' above is comma separated list of
 .BR "src"
 and/or
 .BR "dst" 
-specifications and there can be no more than six of them. Hence the command
+with the exception of hash:ip,iface where, in addition to these two options, the following is also allowed for the 'iface' part:
+.BR "in" 
+or
+.BR "out" 
+corresponding to the incoming or outgoing network interface. The above options cannot exceed six in total for a given set. The command
 .IP
  iptables \-A FORWARD \-m set \-\-match\-set test src,dst
 .IP
-will match packets, for which (if the set type is ipportmap) the source
-address and destination port pair can be found in the specified set. If
-the set type of the specified set is single dimension (for example ipmap),
-then the command will match packets for which the source address can be
-found in the specified set. 
+will match packets for which, if the set is of type hash:ip,port for example, the source IP address and destination port pair can be found and matched successfully. If the specified set is one dimensional (i.e. bitmap:ip), then the command will match packets for which the source address can be found in the set specified.
 .PP
-The option \fB\-\-match\-set\fP can be replaced by \fB\-\-set\fP if that does 
-not clash with an option of other extensions.
+The option \fB\-\-match\-set\fP can be replaced by \fB\-\-set\fP if that does not clash with an option from other extensions.
 .PP
-Use of -m set requires that ipset kernel support is provided, which, for
-standard kernels, is the case since Linux 2.6.39.
+Use of -m set requires that ipset kernel support is provided, which, for standard kernels, is the case since Linux 2.6.39.
diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
index 79cb077..901ec2f 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -186,6 +186,10 @@ enum ip_set_dim {
 	 * If changed, new revision of iptables match/target is required.
 	 */
 	IPSET_DIM_MAX = 6,
+	/* 
+	 * Indicates whether the new 'iface' format (in/out) has been used.
+	 */
+	IPSET_DIM_IFACE = 7, 
 };
 
 /* Option flags for kernel operations */
@@ -194,6 +198,7 @@ enum ip_set_kopt {
 	IPSET_DIM_ONE_SRC = (1 << IPSET_DIM_ONE),
 	IPSET_DIM_TWO_SRC = (1 << IPSET_DIM_TWO),
 	IPSET_DIM_THREE_SRC = (1 << IPSET_DIM_THREE),
+	IPSET_DIM_IFACE_INOUT = (1 << IPSET_DIM_IFACE),
 };
 
 
-- 
1.7.10.4

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

[Mr Dash Four]

Userspace changes to ipset, allowing 'in' and 'out' values to be
specified for the 'iface' part of hash:net,iface type sets.

Man page updated accordingly.

Signed-off-by: Mr Dash Four <mr.dash.four@googlemail.com>
---
 include/libipset/linux_ip_set.h |    5 +++++
 src/ipset.8                     |    8 ++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/libipset/linux_ip_set.h b/include/libipset/linux_ip_set.h
index 008da06..8f2bd95 100644
--- a/include/libipset/linux_ip_set.h
+++ b/include/libipset/linux_ip_set.h
@@ -190,6 +190,10 @@ enum ip_set_dim {
 	 * If changed, new revision of iptables match/target is required.
 	 */
 	IPSET_DIM_MAX = 6,
+	/* 
+	 * Indicates whether the new 'iface' format (in/out) has been used.
+	 */
+	IPSET_DIM_IFACE = 7, 
 };
 
 /* Option flags for kernel operations */
@@ -198,6 +202,7 @@ enum ip_set_kopt {
 	IPSET_DIM_ONE_SRC = (1 << IPSET_DIM_ONE),
 	IPSET_DIM_TWO_SRC = (1 << IPSET_DIM_TWO),
 	IPSET_DIM_THREE_SRC = (1 << IPSET_DIM_THREE),
+	IPSET_DIM_IFACE_INOUT = (1 << IPSET_DIM_IFACE),
 };
 
 #endif /* __IP_SET_H */
diff --git a/src/ipset.8 b/src/ipset.8
index bbad680..522107f 100644
--- a/src/ipset.8
+++ b/src/ipset.8
@@ -800,10 +800,10 @@ set, or by the host prefix value if the set is empty.
 .PP 
 The second direction parameter of the \fBset\fR match and
 \fBSET\fR target modules corresponds to the incoming/outgoing interface:
-\fBsrc\fR to the incoming one (similar to the \fB\-i\fR flag of iptables), while
-\fBdst\fR to the outgoing one (similar to the \fB\-o\fR flag of iptables). When
-the interface is flagged with \fBphysdev:\fR, the interface is interpreted
-as the incoming/outgoing bridge port.
+\fBin\fR for the incoming, 
+\fBout\fR for the outgoing interface, thus, consistent with their appropriate flags in netfilter/iptables), while the format used in prior versions of ipset is also supported:
+\fBsrc\fR indicating the incoming and 
+\fBdst\fR the outgoing interface respectively. If the interface value is preceded with \fBphysdev:\fR, the interface is then interpreted as bridge port.
 .PP 
 The lookup time grows linearly with the number of the different prefix
 values added to the set.
-- 
1.7.10.4

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

[Mr Dash Four]

Kernel changes to ipset, allowing 'in' and 'out' values to be
specified for the 'iface' part of hash:net,iface type sets.

Signed-off-by: Mr Dash Four <mr.dash.four@googlemail.com>
---
 include/linux/netfilter/ipset/ip_set.h      |    5 +++++
 net/netfilter/ipset/ip_set_bitmap_ipmac.c   |    4 ++++
 net/netfilter/ipset/ip_set_hash_ipport.c    |    6 ++++--
 net/netfilter/ipset/ip_set_hash_ipportip.c  |    6 ++++--
 net/netfilter/ipset/ip_set_hash_ipportnet.c |    6 ++++--
 net/netfilter/ipset/ip_set_hash_netport.c   |    6 ++++--
 6 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
index 2edc64c..a9fc982 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -190,6 +190,10 @@ enum ip_set_dim {
 	 * If changed, new revision of iptables match/target is required.
 	 */
 	IPSET_DIM_MAX = 6,
+	/* 
+	 * Indicates whether the new 'iface' format (in/out) has been used.
+	 */
+	IPSET_DIM_IFACE = 7, 
 };
 
 /* Option flags for kernel operations */
@@ -198,6 +202,7 @@ enum ip_set_kopt {
 	IPSET_DIM_ONE_SRC = (1 << IPSET_DIM_ONE),
 	IPSET_DIM_TWO_SRC = (1 << IPSET_DIM_TWO),
 	IPSET_DIM_THREE_SRC = (1 << IPSET_DIM_THREE),
+	IPSET_DIM_IFACE_INOUT = (1 << IPSET_DIM_IFACE),
 };
 
 #ifdef __KERNEL__
diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
index d7eaf10..1d8d754 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
@@ -348,6 +348,10 @@ bitmap_ipmac_kadt(struct ip_set *set, const struct sk_buff *skb,
 	ipset_adtfn adtfn = set->variant->adt[adt];
 	struct ipmac data;
 
+	/* in|out not allowed in this set type, only src|dst */
+	if (opt->flags & IPSET_DIM_IFACE_INOUT)
+		return -EINVAL;
+
 	/* MAC can be src only */
 	if (!(opt->flags & IPSET_DIM_TWO_SRC))
 		return 0;
diff --git a/net/netfilter/ipset/ip_set_hash_ipport.c b/net/netfilter/ipset/ip_set_hash_ipport.c
index 92722bb..615a6e3 100644
--- a/net/netfilter/ipset/ip_set_hash_ipport.c
+++ b/net/netfilter/ipset/ip_set_hash_ipport.c
@@ -143,7 +143,8 @@ hash_ipport4_kadt(struct ip_set *set, const struct sk_buff *skb,
 	ipset_adtfn adtfn = set->variant->adt[adt];
 	struct hash_ipport4_elem data = { };
 
-	if (!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
@@ -361,7 +362,8 @@ hash_ipport6_kadt(struct ip_set *set, const struct sk_buff *skb,
 	ipset_adtfn adtfn = set->variant->adt[adt];
 	struct hash_ipport6_elem data = { };
 
-	if (!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
diff --git a/net/netfilter/ipset/ip_set_hash_ipportip.c b/net/netfilter/ipset/ip_set_hash_ipportip.c
index 0637ce0..732fe63 100644
--- a/net/netfilter/ipset/ip_set_hash_ipportip.c
+++ b/net/netfilter/ipset/ip_set_hash_ipportip.c
@@ -146,7 +146,8 @@ hash_ipportip4_kadt(struct ip_set *set, const struct sk_buff *skb,
 	ipset_adtfn adtfn = set->variant->adt[adt];
 	struct hash_ipportip4_elem data = { };
 
-	if (!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
@@ -374,7 +375,8 @@ hash_ipportip6_kadt(struct ip_set *set, const struct sk_buff *skb,
 	ipset_adtfn adtfn = set->variant->adt[adt];
 	struct hash_ipportip6_elem data = { };
 
-	if (!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
diff --git a/net/netfilter/ipset/ip_set_hash_ipportnet.c b/net/netfilter/ipset/ip_set_hash_ipportnet.c
index 1ce21ca..4a01705 100644
--- a/net/netfilter/ipset/ip_set_hash_ipportnet.c
+++ b/net/netfilter/ipset/ip_set_hash_ipportnet.c
@@ -192,7 +192,8 @@ hash_ipportnet4_kadt(struct ip_set *set, const struct sk_buff *skb,
 	if (adt == IPSET_TEST)
 		data.cidr = HOST_MASK - 1;
 
-	if (!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
@@ -503,7 +504,8 @@ hash_ipportnet6_kadt(struct ip_set *set, const struct sk_buff *skb,
 	if (adt == IPSET_TEST)
 		data.cidr = HOST_MASK - 1;
 
-	if (!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
diff --git a/net/netfilter/ipset/ip_set_hash_netport.c b/net/netfilter/ipset/ip_set_hash_netport.c
index fc3143a..554a468 100644
--- a/net/netfilter/ipset/ip_set_hash_netport.c
+++ b/net/netfilter/ipset/ip_set_hash_netport.c
@@ -189,7 +189,8 @@ hash_netport4_kadt(struct ip_set *set, const struct sk_buff *skb,
 	if (adt == IPSET_TEST)
 		data.cidr = HOST_MASK - 1;
 
-	if (!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip4_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
@@ -467,7 +468,8 @@ hash_netport6_kadt(struct ip_set *set, const struct sk_buff *skb,
 	if (adt == IPSET_TEST)
 		data.cidr = HOST_MASK - 1;
 
-	if (!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
+	if ((opt->flags & IPSET_DIM_IFACE_INOUT) || /* in|out not allowed in this set type, only src|dst */
+		!ip_set_get_ip6_port(skb, opt->flags & IPSET_DIM_TWO_SRC,
 				 &data.port, &data.proto))
 		return -EINVAL;
 
-- 
1.7.10.4

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

[Jozsef Kadlecsik]

On Thu, 5 Jul 2012, Mr Dash Four wrote:

> The following series of 3 patches included in this set allow 'in' or 
> 'out' values to be specified for the 'iface' part of hash:net,iface set, 
> corresponding to the incoming and outgoing interface accordingly, thus 
> eliminating the discrepancy which, up until now, existed with the 'old' 
> format and also reinforcing much-needed consistency with the rest of the 
> netfilter/iptables terminology.
> 
> For backwards compatibility, the 'old' format, comprising of 'src' 
> (incoming) and 'dst' (outgoing) direction parameter for the 'iface' part 
> of hash:net,iface is also supported.

You have to introduce a new set type version whenever a new feature is 
added: in your patches there is no protection against mixed cases, when 
only the kernel or just the userspace is upgraded. Or one side is 
downgraded for whatever reason.

You must handle the case of the list:set type: how should then the new 
"in", "out" be interpreted? Or should those be rejected? But then it'd 
mean that if someone used a hash:net,iface type as a member of list:set, 
then he is forced to use "src", "dst" only.

It'd be much simpler to introduce the keywords as aliases, all over:
"in" as "dst" and "out" as "src", and print them with hash:net,iface only.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> You have to introduce a new set type version whenever a new feature is 
> added: in your patches there is no protection against mixed cases, when 
> only the kernel or just the userspace is upgraded. Or one side is 
> downgraded for whatever reason.
>   
You mean object version (similar to the one you had a debate about on 
this ML with Mr Engelhardt a while ago)?

As for protection against mixed case uses - I don't think there is a 
need for one. There are two possible scenarios worth considering:- using 
old iptables + new kernel and using new iptables + old kernel.

With the first case, iptables simply won't accept 'in' or 'out' values 
even if the kernel can process them. So, to me that is not an issue.

With the second case, again, even if iptables accept 'in' and 'out' as 
values, because the patches I submitted yesterday allow for backwards 
compatibility, the kernel would be able to process these matches without 
any issues.

If you look at the code, the iptables code is raising both DIM_TWO_SRC 
as well as the new DIM_IFACE bits in the 'flags' variable. The set 
matching functions of the "old" kernel will "know" of and take into 
account just the DIM_TWO_SRC bit to produce a match, which is quite fine 
and it is how is supposed to work in the first place, so again, a match 
will be produced and I don't see any issues here either.

If you think there would be any issues of mixed case uses, please 
elaborate why do you think that is and give me an example (I am 
excluding the list:set type as this is a bit of a special case - see below)?

> You must handle the case of the list:set type: how should then the new 
> "in", "out" be interpreted?
As I already pointed out in the patches yesterday, 'in' and 'out' have 
only one single purpose - to match against network interfaces. Nothing 
else!

'In' - means incoming interface, 'out' means outgoing. It doesn't make 
sense at all to be used anywhere else - if they are allowed to be used 
to specify source/destination ip addresses/subnets, protocols or ports, 
this would be completely nonsensical. It is also why I am dead against 
the idea 'in' and 'out' to be considered as simply a "synonym" of 'src' 
and 'dst' as you suggest below.

Again, 'in' and 'out' are only meant and should only be used for 
interfaces, nothing else.

>  Or should those be rejected? But then it'd 
> mean that if someone used a hash:net,iface type as a member of list:set, 
> then he is forced to use "src", "dst" only.
>   
It would help if I use an example for this.

If I create a list set (lets call it list1) consisting of, say, 2 
hash:net,iface set members (lets call them iface1 and iface2) and 3 
other hash:ip,port set members (lets call them ipp1, ipp2 and ipp3) and 
if I then execute the following iptables statement:

iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT

The above statement will *only* match packets against members of the 
list1 set which have a matching source IP address and incoming interface 
- iface1 and iface2 in this case. ipp1, ipp2 and ipp3 won't be matched.

This makes perfect sense, given what I have written above (and in the 
patches I submitted yesterday) about the definition of 'in' and 'out' - 
it means match *only* against the incoming or outgoing interfaces.

However, if I execute the following iptables statement:

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT

That would match packets against *all* members of the list1 set (iface1, 
iface2, ipp1, ipp2 and ipp3 this time) which have a matching source IP 
address, incoming interface as well as src port values. Again, I see 
nothing wrong with that and the fact that there is additional "filter" 
for 'in' and 'out' values - well, I consider this an added feature, if 
anything.

> It'd be much simpler to introduce the keywords as aliases, all over:
> "in" as "dst" and "out" as "src", and print them with hash:net,iface only.
>   
Simpler for whom? It can't be for the end user, because referring to, 
say, destination IP address as "out" IP address is even more ridiculous 
than using 'src' and 'dst' designators for network interfaces. Quite 
astonishing that!

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

[Jan Engelhardt]

On Friday 2012-07-06 21:05, Mr Dash Four wrote:

>
>> You have to introduce a new set type version whenever a new feature is added:
>> in your patches there is no protection against mixed cases, when only the
>> kernel or just the userspace is upgraded. Or one side is downgraded for
>> whatever reason.
>>  
> You mean object version (similar to the one you had a debate about on this ML
> with Mr Engelhardt a while ago)?

The SO version is purely a userspace issue. Here, Joszef means the 
user-kernel interaction; a too-old userspace ipset binary would not know 
how to interpret a too-new kernel response which has IFACE set; and a 
too-old kernel would not know how to read a too-new ipset request with 
IFACE set.

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

[Mr Dash Four]

> The SO version is purely a userspace issue. Here, Joszef means the 
> user-kernel interaction; a too-old userspace ipset binary would not know 
> how to interpret a too-new kernel response which has IFACE set; and a 
> too-old kernel would not know how to read a too-new ipset request with 
> IFACE set.
>   
If you look more careful at the patches I submitted yesterday, you will 
find out that the changes I have made to ipset (userspace) are 
negligible and have nothing whatsoever to do with the changes I have 
proposed in these patches.

Whether one uses the old ipset (userspace) or the new one won't matter 
one jot for the purpose of these changes!

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

[Mr Dash Four]

Oh, and also...
> and a too-old kernel would not know how to read a too-new ipset request with 
> IFACE set.
>   
A response I gave on this very issue from the post you quoted:

"...With the second case, again, even if iptables accept 'in' and 'out' 
as values, because the patches I submitted yesterday allow for backwards 
compatibility, the kernel would be able to process these matches without 
any issues.

If you look at the code, the iptables code is raising both DIM_TWO_SRC 
as well as the new DIM_IFACE bits in the 'flags' variable. The set 
matching functions of the "old" kernel will "know" of and take into 
account just the DIM_TWO_SRC bit to produce a match, which is quite fine 
and it is how is supposed to work in the first place, so again, a match 
will be produced and I don't see any issues here either."

If you know any different I am all eyes/ears etc!

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

[Jozsef Kadlecsik]

On Fri, 6 Jul 2012, Mr Dash Four wrote:

> > You have to introduce a new set type version whenever a new feature is
> > added: in your patches there is no protection against mixed cases, when only
> > the kernel or just the userspace is upgraded. Or one side is downgraded for
> > whatever reason.
> >   
> You mean object version (similar to the one you had a debate about on 
> this ML with Mr Engelhardt a while ago)?

No, I meant functionality changes, but...
 
> As for protection against mixed case uses - I don't think there is a need for
> one. There are two possible scenarios worth considering:- using old iptables +
> new kernel and using new iptables + old kernel.
> 
> With the first case, iptables simply won't accept 'in' or 'out' values even if
> the kernel can process them. So, to me that is not an issue.
> 
> With the second case, again, even if iptables accept 'in' and 'out' as values,
> because the patches I submitted yesterday allow for backwards compatibility,
> the kernel would be able to process these matches without any issues.
> 
> If you look at the code, the iptables code is raising both DIM_TWO_SRC as well
> as the new DIM_IFACE bits in the 'flags' variable. The set matching functions
> of the "old" kernel will "know" of and take into account just the DIM_TWO_SRC
> bit to produce a match, which is quite fine and it is how is supposed to work
> in the first place, so again, a match will be produced and I don't see any
> issues here either.
> 
> If you think there would be any issues of mixed case uses, please elaborate
> why do you think that is and give me an example (I am excluding the list:set
> type as this is a bit of a special case - see below)?

...you are right, because "in" is equivalent with "src".
 
> > You must handle the case of the list:set type: how should then the new "in",
> > "out" be interpreted?
> As I already pointed out in the patches yesterday, 'in' and 'out' have 
> only one single purpose - to match against network interfaces. Nothing 
> else!
> 
> 'In' - means incoming interface, 'out' means outgoing. It doesn't make 
> sense at all to be used anywhere else - if they are allowed to be used 
> to specify source/destination ip addresses/subnets, protocols or ports, 
> this would be completely nonsensical. It is also why I am dead against 
> the idea 'in' and 'out' to be considered as simply a "synonym" of 'src' 
> and 'dst' as you suggest below.
> 
> Again, 'in' and 'out' are only meant and should only be used for 
> interfaces, nothing else.
> 
> >  Or should those be rejected? But then it'd mean that if someone used a
> > hash:net,iface type as a member of list:set, then he is forced to use "src",
> > "dst" only.
> >   
> It would help if I use an example for this.
> 
> If I create a list set (lets call it list1) consisting of, say, 2
> hash:net,iface set members (lets call them iface1 and iface2) and 3 other
> hash:ip,port set members (lets call them ipp1, ipp2 and ipp3) and if I then
> execute the following iptables statement:
> 
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
> 
> The above statement will *only* match packets against members of the list1 set
> which have a matching source IP address and incoming interface - iface1 and
> iface2 in this case. ipp1, ipp2 and ipp3 won't be matched.
> 
> This makes perfect sense, given what I have written above (and in the 
> patches I submitted yesterday) about the definition of 'in' and 'out' - 
> it means match *only* against the incoming or outgoing interfaces.
> 
> However, if I execute the following iptables statement:
> 
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT

This creates more confusion for the users than the current state: one 
had to keep in mind what kind of sets are stored in a list of sets and 
depending on them, use "src/dst" or "in/out" in the second direction 
parameter. And additionally,

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT

and

iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT

produced different results for the same member sets with the same elements 
against the same packets. This is unacceptable for me.

> That would match packets against *all* members of the list1 set (iface1,
> iface2, ipp1, ipp2 and ipp3 this time) which have a matching source IP
> address, incoming interface as well as src port values. Again, I see nothing
> wrong with that and the fact that there is additional "filter" for 'in' and
> 'out' values - well, I consider this an added feature, if anything.
> 
> > It'd be much simpler to introduce the keywords as aliases, all over:
> > "in" as "dst" and "out" as "src", and print them with hash:net,iface only.
> >   
> Simpler for whom? It can't be for the end user, because referring to, say,
> destination IP address as "out" IP address is even more ridiculous than using
> 'src' and 'dst' designators for network interfaces. Quite astonishing that!

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> ...you are right, because "in" is equivalent with "src".
>   
Except that it isn't. It is only "equivalent" for the 'iface' part of 
hash:net,iface sets and nothing else. Consider it as an alternative to 
select 'iface' part of a hash:net,iface set. It servers no other purpose 
and should *not* be used for anything else.

> This creates more confusion for the users than the current state: one 
> had to keep in mind what kind of sets are stored in a list of sets and 
> depending on them, use "src/dst" or "in/out" in the second direction 
> parameter.
Please explain the 'confusion' bit?

I've made it quite clear in the definition of 'in' and 'out' (not least 
in the various man pages which form part of these patch series - a bit 
like you trying to clarify the use of 'src' and 'dst' for the 'iface' 
part in the last ipset update) - 'in' is meant for a match on the 
'incoming', 'out' on the 'outgoing' interfaces.

If one wishes to produce a match against those interfaces, then 'in' and 
'out' is one possible way to go, if not - then use 'src' or 'dst' if you 
feel more comfortable with it.

What I am offering with my patch series is a choice (a choice I didn't 
have before, I might add!) - nobody is forced to use it, except those 
who understand that choice. If one is unwilling/unable to deploy this 
for one reason or another, no problem - quite simple really.

>  And additionally,
>
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
>
> and
>
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>
> produced different results for the same member sets with the same elements 
> against the same packets. This is unacceptable for me.
>   
You can't expect to issue two different iptables statements (as in your 
example above) and get the same number of matches! Not going to happen, 
is it? By the same token, if I execute the following two statements:

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT

and

iptables -A INPUT -m set --match-set list1 src,dst -j ACCEPT

The above will also produce "different results for the same member sets 
with the same elements against the same packets". So why is this not 
"unacceptable" then?

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

[Jozsef Kadlecsik]

On Fri, 6 Jul 2012, Mr Dash Four wrote:

> > This creates more confusion for the users than the current state: one 
> > had to keep in mind what kind of sets are stored in a list of sets and 
> > depending on them, use "src/dst" or "in/out" in the second direction 
> > parameter.
>
> Please explain the 'confusion' bit?

Look at your patches and the manpage modifications: do you explain in them 
what happens when a hash:net,iface type of set is a member of a list of 
sets and one uses "in/out" or "src/dst"? No. And even if you add the 
appropriate lines, the user still faces:
 
> >  And additionally,
> > 
> > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> > 
> > and
> > 
> > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
> > 
> > produced different results for the same member sets with the same elements
> > against the same packets. This is unacceptable for me.
> >   
> You can't expect to issue two different iptables statements (as in your
> example above) and get the same number of matches! Not going to happen, is it?
> By the same token, if I execute the following two statements:
> 
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> 
> and
> 
> iptables -A INPUT -m set --match-set list1 src,dst -j ACCEPT

Your example is wrong, because the effect of two command are of course 
different.

But what I gave above, the results depends from the type of the members of 
the set list, which is invisible in the command line. Even if it's 
stressed in the manpage that "in" is equivalent with "src" but just for 
the hash:net,iface type, that is an equivalency and users will expect the 
same result for the cited commands. And they're right.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> Your example is wrong, because the effect of two command are of course 
> different.
>   
So are yours as well, quite evidently. See my previous reply to Maciej.

> But what I gave above, the results depends from the type of the members of 
> the set list, which is invisible in the command line.
It is quite visible as the 'in' bit suggests (similar to the 'dst' bit).

>  Even if it's 
> stressed in the manpage that "in" is equivalent with "src" but just for 
> the hash:net,iface type,
'In' is defined as match on incoming interface only - if that is not 
clear, then it should be made clear (again, I draw similarities with 
your clarifications of 'src' and 'dst' of the very same issue during the 
last ipset update you've made).

Again, this is a choice for people who understand that choice - if 
someone is uncomfortable with that choice, then s/he is free not to use 
it. if I, on the other hand, am not comfortable with using 'src' and 
'dst' for interface matching (I am sure I am not the only one!) then 
there is a help at hand with the above choice.

>  that is an equivalency and users will expect the 
> same result for the cited commands. And they're right.
>   
How so? How would one expect a match on "income interface only" with a 
match on "source ip addresses, source subnets, source ports, source 
everything else you care to mention ... and income interface" to be an 
"equivalent"? it isn't - not in a million years!

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

[Mr Dash Four]

> > You can't expect to issue two different iptables statements (as in 
> your example above) and get the same number of matches! Not going to 
> happen, is it? By the same token, if I execute the following two 
> statements:
>
> I would certainly expect the two above statements to be identical.
>
They are not! How many times would you like me to repeat that: 'in' = 
use and match on incoming interfaces *only*, 'out' = use and match on 
outgoing interfaces *only*. It is appropriately named as well. I 
considered 'in' to be 'incoming_network_interface' at one point, but 
opted for the short version instead. ;-)

> As an uninterested third party only slightly following along this 
> discussion.  I would expect this to be a purely userspace change.  Ie. 
> just change src->in and dst->out on display, and make src==in and 
> dst==out on input.  I see no reason for any kernel space changes or 
> kernel version bumps.
>
And why is that exactly? What is stopping me, or everybody else for that 
matter, to make "kernel version bumps", as you put it? Changes to 
various netfilter components often require kernel submissions as well as 
userspace changes, simply because of the scope of those changes. Nothing 
is precluding me, or anybody else, from applying these changes.

> > The above will also produce "different results for the same member 
> sets with the same elements against the same packets". So why is this 
> not "unacceptable" then?
>
> Because src != dst ?
>
Exactly my point! src != dst, but src != in as well (see above). 'src' = 
'in' (and use the the term "equal" loosely here) *only* in the scope of 
the 'iface' part of hash:net,iface set describing network interface matches.

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

[Jozsef Kadlecsik]

On Fri, 6 Jul 2012, Mr Dash Four wrote:

> > Because src != dst ?
> > 
> Exactly my point! src != dst, but src != in as well (see above). 'src' = 
> 'in' (and use the the term "equal" loosely here) *only* in the scope of 
> the 'iface' part of hash:net,iface set describing network interface 
> matches.

Do you deliberately close your eyes? In the two rules

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT

the underlying set types "decide" how to act to "src/in", when actually 
"src" == "in". I hear you shouting: FOR HASH:NET,IFACE ONLY. Right. But 
"list1" is a list type of set, not hash:net,iface. Still, the result is 
different.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> Do you deliberately close your eyes? In the two rules
>   
Explain the above comment please?

> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>
> the underlying set types "decide" how to act to "src/in", when actually 
> "src" == "in". I hear you shouting: FOR HASH:NET,IFACE ONLY. Right. But 
> "list1" is a list type of set, not hash:net,iface. Still, the result is 
> different.
>   
Whoever produces the above statements is making a concious decision on 
what to use/deploy! I am repeating this for, I don't know, a third time 
maybe - what my patch series are offering is a choice. If you, or 
anybody else wishes to continue to use 'src' or 'dst' (including for 
interface matching), then so be it, you are completely free to do that - 
I am not forcing you, or anyone to do otherwise.

If, on the other hand, I, or anybody else, is not entirely comfortable 
with using 'src' or 'dst' for interface matching and prefer to use 'in' 
or 'out' instead, then so be it - the choice is there.

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

[Jozsef Kadlecsik]

On Fri, 6 Jul 2012, Mr Dash Four wrote:

> > Do you deliberately close your eyes? In the two rules
> >   
> Explain the above comment please?

Are you deliberately deaf to the arguments?
 
> > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
> > 
> > the underlying set types "decide" how to act to "src/in", when actually
> > "src" == "in". I hear you shouting: FOR HASH:NET,IFACE ONLY. Right. But
> > "list1" is a list type of set, not hash:net,iface. Still, the result is
> > different.
> >   
> Whoever produces the above statements is making a concious decision on 
> what to use/deploy! I am repeating this for, I don't know, a third time 
> maybe - what my patch series are offering is a choice. If you, or 
> anybody else wishes to continue to use 'src' or 'dst' (including for 
> interface matching), then so be it, you are completely free to do that - 
> I am not forcing you, or anyone to do otherwise.

You want a choice to be introduced which lead to confusion - I'm repeating 
it countless times and you just ignore it. In order to prevent such 
confusions, I offered that let "in/out" be alias to "src/dst": accepted as 
input everywhere but printed/saved with hash:net,iface only. You point 
blank refused it. Then come up with a better solution than the submitted 
one.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

  

>> Explain the above comment please?
>>     
>
> Are you deliberately deaf to the arguments?
>   
My hearing is still quite sharp, thank you. As for the "arguments" bit - 
as far as I understand it (well, hoping, at least anyway), this is a 
discussion, and nobody's "arguing".

> You want a choice to be introduced which lead to confusion - I'm repeating 
> it countless times and you just ignore it.
How am I ignoring it? I asked you before and I am asking you again to 
explain what that "confusion" is? It is quite clear to me what the 
meaning of "in" and "out" is (again, if it is not made clear in the 
various man pages, I would certainly appreciate any suggestions you - or 
anyone else following this - might have). Again, if there is something 
"confusing" in that meaning, then I'd like to know.

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.

I don't know how much more clearer that could be, to be honest, but if 
you have something on your mind, I am certainly all eyes/ears!

>  In order to prevent such 
> confusions, I offered that let "in/out" be alias to "src/dst": accepted as 
> input everywhere but printed/saved with hash:net,iface only. You point 
> blank refused it.
That is correct, and I also remember asking the question to whom do you 
think that solution would be "easier"? You declined to answer that 
particular query. It certainly won't be for the end user, that's for sure!

As for your suggestion above, I'll repeat what I've already posted - of 
course I'll refuse it, because it is completely nonsensical. Do you not 
think that referring to a destination IP address, for example, as "out" 
IP address isn't confusing in the slightest? I mean, really Jozsef, you 
could do better than that!

>  Then come up with a better solution than the submitted 
> one.
>   
I will, if you let me know what is wrong, in your view, with the one I 
submitted yesterday.

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

[Jozsef Kadlecsik]

On Fri, 6 Jul 2012, Mr Dash Four wrote:

> > You want a choice to be introduced which lead to confusion - I'm repeating
> > it countless times and you just ignore it.
> How am I ignoring it? I asked you before and I am asking you again to 
> explain what that "confusion" is? It is quite clear to me what the 
> meaning of "in" and "out" is (again, if it is not made clear in the 
> various man pages, I would certainly appreciate any suggestions you - or 
> anyone else following this - might have). Again, if there is something 
> "confusing" in that meaning, then I'd like to know.

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. 
 
> 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.
 
> >  Then come up with a better solution than the submitted one.
> >   
> I will, if you let me know what is wrong, in your view, with the one I
> submitted yesterday.

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.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Jozsef Kadlecsik]

On Sat, 7 Jul 2012, Jozsef Kadlecsik wrote:

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

To make sure I'm not misunderstood, I have to add to the last sentence: 
"...and where both syntax is accepted".

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

>> 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.
>>     
>
> To make sure I'm not misunderstood, I have to add to the last sentence: 
> "...and where both syntax is accepted".
>   
If you know of a case where 'in' or 'out' direction parameters "are 
accepted" and produce "different results" (by "different results" I mean 
different from their own definition - match on incoming/outgoing 
interfaces only), then, by all means, let me know.

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

[Jozsef Kadlecsik]

On Sun, 8 Jul 2012, Mr Dash Four wrote:

> > > 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.
> > 
> > To make sure I'm not misunderstood, I have to add to the last sentence:
> > "...and where both syntax is accepted".
> >   
> If you know of a case where 'in' or 'out' direction parameters "are accepted"
> and produce "different results" (by "different results" I mean different from
> their own definition - match on incoming/outgoing interfaces only), then, by
> all means, let me know.

I repeat it as many times it's required. The rules

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT

would produce different results and that's unacceptable.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> I repeat it as many times it's required. The rules
>
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>
> would produce different results and that's unacceptable.
>   
Why not?

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

[Jozsef Kadlecsik]

On Sun, 8 Jul 2012, Mr Dash Four wrote:

> > I repeat it as many times it's required. The rules
> > 
> > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
> > 
> > would produce different results and that's unacceptable.
> >   
> Why not?

Because that's too subtle, error prone and hard to catch if not used 
really intentionally. Because that's illogical. Because there are a couple 
of ways to avoid it.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> Because that's too subtle, error prone and hard to catch if not used 
> really intentionally.
If I use 'src,dst' instead of 'src,src' would you consider this "error 
prone", "hard to catch" or not?

>  Because that's illogical.
Please explain - what do you see as "illogical"?

>  Because there are a couple 
> of ways to avoid it.
>   
Avoid what exactly? Using 'in' or 'out' in list:set types?

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

[Jozsef Kadlecsik]

On Sun, 8 Jul 2012, Mr Dash Four wrote:

> > Because that's too subtle, error prone and hard to catch if not used really
> > intentionally.
> If I use 'src,dst' instead of 'src,src' would you consider this "error prone",
> "hard to catch" or not?

"src,src" != "src,dst", but

with your patches in some cases 

"src,in" == "src,src" or "src,in" != "src,src"
 
> >  Because that's illogical.
> Please explain - what do you see as "illogical"?

See above.
 
> >  Because there are a couple of ways to avoid it.
> >   
> Avoid what exactly? Using 'in' or 'out' in list:set types?

For example. That's a possible solution.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

> "src,src" != "src,dst", but
>
> with your patches in some cases 
>
> "src,in" == "src,src" or "src,in" != "src,src"
>   
Could you provide me with an example please? I am intrigued!

>> Avoid what exactly? Using 'in' or 'out' in list:set types?
>>     
>
> For example. That's a possible solution.
>   
So, in other words, what you are actually getting at, is that you wish 
to restrict the use of 'in' and 'out' options only for hash:net,iface 
types because you are not happy with the use of 'in'/'out' in any other 
set types, list:set in particular? Have I understood this correctly then?

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

[Jozsef Kadlecsik]

On Sun, 8 Jul 2012, Mr Dash Four wrote:

> > "src,src" != "src,dst", but
> > 
> > with your patches in some cases 
> > "src,in" == "src,src" or "src,in" != "src,src"
> >   
> Could you provide me with an example please? I am intrigued!

This is ridiculous, as if I haven't provided it countless times:

iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
 
> > > Avoid what exactly? Using 'in' or 'out' in list:set types?
> > >     
> > 
> > For example. That's a possible solution.
> >   
> So, in other words, what you are actually getting at, is that you wish to
> restrict the use of 'in' and 'out' options only for hash:net,iface types
> because you are not happy with the use of 'in'/'out' in any other set types,
> list:set in particular? Have I understood this correctly then?

That's a possible - probably the simplest - solution. It's OK for me.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

>>> with your patches in some cases 
>>> "src,in" == "src,src" or "src,in" != "src,src"
>>>   
>>>       
>> Could you provide me with an example please? I am intrigued!
>>     
>
> This is ridiculous, as if I haven't provided it countless times:
>
> iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
>   
Well, in the above example I fail to see where "src,in" == "src,src" - 
that is *never* the case!

>> So, in other words, what you are actually getting at, is that you wish to
>> restrict the use of 'in' and 'out' options only for hash:net,iface types
>> because you are not happy with the use of 'in'/'out' in any other set types,
>> list:set in particular? Have I understood this correctly then?
>>     
>
> That's a possible - probably the simplest - solution. It's OK for me.
>   
So, let me get this straight then: you wish 'in' and 'out' to be 
accepted as input (and I presume also displayed as well) *only* for 
hash:net,iface type of sets and rejected (possibly with an error) 
everywhere else?

In other words:
1. For hash:net,iface the possible options should be 'in', 'out', 'src' 
and 'dst'; and
2. For all other sets, including list:set the only available options 
should be 'src' and 'dst'. Have I understood this correctly then?

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

[Jozsef Kadlecsik]

On Sun, 8 Jul 2012, Mr Dash Four wrote:

> > > > with your patches in some cases "src,in" == "src,src" or "src,in" !=
> > > > "src,src"
> > > >         
> > > Could you provide me with an example please? I am intrigued!
> > >     
> > 
> > This is ridiculous, as if I haven't provided it countless times:
> > 
> > iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
> > iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
> >   
> 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 have exhausted my patience in this, I won't repeat it again.
 
> > > So, in other words, what you are actually getting at, is that you wish to
> > > restrict the use of 'in' and 'out' options only for hash:net,iface types
> > > because you are not happy with the use of 'in'/'out' in any other set
> > > types,
> > > list:set in particular? Have I understood this correctly then?
> > 
> > That's a possible - probably the simplest - solution. It's OK for me.
> >   
> So, let me get this straight then: you wish 'in' and 'out' to be accepted as
> input (and I presume also displayed as well) *only* for hash:net,iface type of
> sets and rejected (possibly with an error) everywhere else?
>
> In other words:
> 1. For hash:net,iface the possible options should be 'in', 'out', 'src' and
> 'dst'; and
> 2. For all other sets, including list:set the only available options should be
> 'src' and 'dst'. Have I understood this correctly then?

Yes, that looks OK.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

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

[Mr Dash Four]

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

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

[Mr Dash Four]

>> In other words:
>> 1. For hash:net,iface the possible options should be 'in', 'out', 'src' and
>> 'dst'; and
>> 2. For all other sets, including list:set the only available options should be
>> 'src' and 'dst'. Have I understood this correctly then?
> 
> Yes, that looks OK.
I'll submit an alternative version of the patches soon, with the above restrictions applied to see if that makes you happy.

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

[Mr Dash Four]

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

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

[Mr Dash Four]

> > 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:
>
> Fly on the wall comment: the fact you allow sets of objects of 
> different types seems like a design mistake.
>
Nope, that is the *real* beauty of list:set type of sets - you can 
mix-and-match to your heart's content! In ipset versions prior to 4, I 
think, there used to be a feature called "nesting" in sets, but it was 
fraud and later abandoned.