ipset: change 'iface' part in hash:net,iface set

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

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.

---
 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(-)

index a11db39..d9f60c9 100644
@@ -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);
 	}
 }
 

index 63eb383..747235f 100644
@@ -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.

index 77e3f07..ba478ed 100644
@@ -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);
 	}
 }
 

index 47c3f5b..23830b2 100644
@@ -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)

index 1ad9085..31be0eb 100644
@@ -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.

index 79cb077..901ec2f 100644
@@ -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

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.

---
 include/libipset/linux_ip_set.h |    5 +++++
 src/ipset.8                     |    8 ++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

index 008da06..8f2bd95 100644
@@ -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 */

index bbad680..522107f 100644
@@ -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

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

---
 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(-)

index 2edc64c..a9fc982 100644
@@ -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__

index d7eaf10..1d8d754 100644
@@ -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;

index 92722bb..615a6e3 100644
@@ -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;
 

index 0637ce0..732fe63 100644
@@ -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;
 

index 1ce21ca..4a01705 100644
@@ -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;
 

index fc3143a..554a468 100644
@@ -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

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 : [email protected], [email protected] 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

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

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.

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.

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!

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!

Oh, and also...

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!

No, I meant functionality changes, but...

...you are right, because "in" is equivalent with "src".

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.

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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

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.

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.

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?

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:

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 : [email protected], [email protected] 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

So are yours as well, quite evidently. See my previous reply to Maciej.

It is quite visible as the 'in' bit suggests (similar to the 'dst' bit).

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

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!

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

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.

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 : [email protected], [email protected] 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

Explain the above comment please?

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.

Are you deliberately deaf to the arguments?

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 : [email protected], [email protected] 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

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

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!

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!

I will, if you let me know what is wrong, in your view, with the one I submitted yesterday.

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.

In the given example, in rule level, there is no hash:net,iface type of set. Still, the result depends on the syntax.

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 : [email protected], [email protected] 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

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 : [email protected], [email protected] 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

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 : [email protected], [email protected] 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

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 : [email protected], [email protected] 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

If I use 'src,dst' instead of 'src,src' would you consider this "error prone", "hard to catch" or not?

Please explain - what do you see as "illogical"?

Avoid what exactly? Using 'in' or 'out' in list:set types?

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

with your patches in some cases

"src,in" == "src,src" or "src,in" != "src,src"

See above.

For example. That's a possible solution.

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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

Could you provide me with an example please? I am intrigued!

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?

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

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

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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

Well, in the above example I fail to see where "src,in" == "src,src" - that is *never* the case!

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?

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.

Yes, that looks OK.

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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

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?

I'll submit an alternative version of the patches soon, with the above restrictions applied to see if that makes you happy.

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.

Please clarify, what "given example"?

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!

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.