[PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[pablo]

From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>

The IPv6 header is not zeroed out in alloc_skb so we must initialize
it properly unless we want to see IPv6 packets with random TOS fields
floating around. The current implementation resets the flow label
but this could be changed if deemed necessary.

We stumbled upon this issue when trying to apply a mangle rule to
the RST packet generated by the REJECT target module.

The following Linux kernels are affected: <= 2.6.38.8

Cc: stable@kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)
---
 net/ipv6/netfilter/ip6t_REJECT.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/net/ipv6/netfilter/ip6t_REJECT.c b/net/ipv6/netfilter/ip6t_REJECT.c
index 28e7448..a5a4c5d 100644
--- a/net/ipv6/netfilter/ip6t_REJECT.c
+++ b/net/ipv6/netfilter/ip6t_REJECT.c
@@ -45,6 +45,8 @@ static void send_reset(struct net *net, struct sk_buff *oldskb)
 	int tcphoff, needs_ack;
 	const struct ipv6hdr *oip6h = ipv6_hdr(oldskb);
 	struct ipv6hdr *ip6h;
+#define DEFAULT_TOS_VALUE	0x0U
+	const __u8 tclass = DEFAULT_TOS_VALUE;
 	struct dst_entry *dst = NULL;
 	u8 proto;
 	struct flowi6 fl6;
@@ -124,7 +126,7 @@ static void send_reset(struct net *net, struct sk_buff *oldskb)
 	skb_put(nskb, sizeof(struct ipv6hdr));
 	skb_reset_network_header(nskb);
 	ip6h = ipv6_hdr(nskb);
-	ip6h->version = 6;
+	*(__be32 *)ip6h =  htonl(0x60000000 | (tclass << 20));
 	ip6h->hop_limit = ip6_dst_hoplimit(dst);
 	ip6h->nexthdr = IPPROTO_TCP;
 	ipv6_addr_copy(&ip6h->saddr, &oip6h->daddr);
-- 
1.7.2.5

[PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[pablo]

From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>

The mask indicates the bits one wants to zero out, so it needs to be
inverted before applying to the original TOS field.

The following Linux kernels are affected: <= 2.6.38.8

Cc: stable@kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 1ed2f73d90fb49bcf5704aee7e9084adb882bfc5)
---
 net/netfilter/xt_DSCP.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/netfilter/xt_DSCP.c b/net/netfilter/xt_DSCP.c
index 0a22919..ae82716 100644
--- a/net/netfilter/xt_DSCP.c
+++ b/net/netfilter/xt_DSCP.c
@@ -99,7 +99,7 @@ tos_tg6(struct sk_buff *skb, const struct xt_action_param *par)
 	u_int8_t orig, nv;
 
 	orig = ipv6_get_dsfield(iph);
-	nv   = (orig & info->tos_mask) ^ info->tos_value;
+	nv   = (orig & ~info->tos_mask) ^ info->tos_value;
 
 	if (orig != nv) {
 		if (!skb_make_writable(skb, sizeof(struct iphdr)))
-- 
1.7.2.5

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Maciej Żenczykowski]

> The mask indicates the bits one wants to zero out, so it needs to be
> inverted before applying to the original TOS field.

Uhm, does it?
This is backwards incompatible...

To me, you always 'and' with a mask, not with the negation of the mask.
ie. a mask is the bits you want to keep.

(mind you I haven't looked at the documentation of the feature, but
I'm still pretty sure the right fix here is to change the docs, not
the functionality)

> The following Linux kernels are affected: <= 2.6.38.8

- Maciej

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Jan Engelhardt]

On Monday 2011-06-06 15:44, Maciej Żenczykowski wrote:

>> The mask indicates the bits one wants to zero out, so it needs to be
>> inverted before applying to the original TOS field.
>
>Uhm, does it?
>This is backwards incompatible...
>
>To me, you always 'and' with a mask, not with the negation of the mask.
>ie. a mask is the bits you want to keep.

That certainly is not set into stone.

If you model a sculpture into an ice/concrete/wood/etc. block, you 
usually specify what to take away rather than what to leave, to take a 
non-abstract example. But see below.


>(mind you I haven't looked at the documentation of the feature,

[You should do that.]

xt_MARK does the same as xt_TOS, and both should be using &~ - because 
--set-mark 0x12/0x0f has always meant "kill 0x3f, then set 0x12".

I wager to say that the most common applications are:

 --set-mark somevalue/samevalue
 --set-mark somevalue/0xff

so having to calculate the negation of samevalue is usually wasted brain 
time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Fernando Luis Vazquez Cao]

Jan, Patrick,

I would like to get this bug in old Linux kernels documented in the
iptables man page, since it is pretty serious. The fix made into 2.6.39
and I would like to have it backported to 2.6.32-longterm and
2.6.33-longterm. If you disagree with the backport to -longterm please
let me know, I would update the patch accordingly.

---

In Linux kernels up to and including 2.6.38, with the exception of longterm
releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug (*) whereby
IPv6 TOS mangling does not behave as documented and differs from the IPv4
version. The TOS mask indicates the bits one wants to zero out, so it needs to
be inverted before applying it to the original TOS field. However, the
aformentioned kernels forgo the inversion which breaks --set-tos and its
mnemonics.

(*) Fixed by upstream commit:
    1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 (netfilter: IPv6: fix DSCP mangle code)

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---

diff -urNp iptables-1.4.11.1-orig/extensions/libxt_TOS.man iptables-1.4.11.1/extensions/libxt_TOS.man
--- iptables-1.4.11.1-orig/extensions/libxt_TOS.man	2011-06-08 22:26:17.000000000 +0900
+++ iptables-1.4.11.1/extensions/libxt_TOS.man	2011-06-16 16:07:34.374062111 +0900
@@ -4,24 +4,26 @@ shares the same bits as DSCP and ECN. Th
 \fBmangle\fP table.
 .TP
 \fB\-\-set\-tos\fP \fIvalue\fP[\fB/\fP\fImask\fP]
-Zeroes out the bits given by \fImask\fP and XORs \fIvalue\fP into the
-TOS/Priority field. If \fImask\fP is omitted, 0xFF is assumed.
+Zeroes out the bits given by \fImask\fP (see \fBBUGS\fP below) and XORs
+\fIvalue\fP into the TOS/Priority field. If \fImask\fP is omitted, 0xFF is
+assumed.
 .TP
 \fB\-\-set\-tos\fP \fIsymbol\fP
 You can specify a symbolic name when using the TOS target for IPv4. It implies
-a mask of 0xFF. The list of recognized TOS names can be obtained by calling
-iptables with \fB\-j TOS \-h\fP.
+a mask of 0xFF (see \fBBUGS\fP below). The list of recognized TOS names can be
+obtained by calling iptables with \fB\-j TOS \-h\fP.
 .PP
 The following mnemonics are available:
 .TP
 \fB\-\-and\-tos\fP \fIbits\fP
 Binary AND the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos
-0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.)
+0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.
+See \fBBUGS\fP below.)
 .TP
 \fB\-\-or\-tos\fP \fIbits\fP
 Binary OR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/\fP\fIbits\fP.)
+\fIbits\fP\fB/\fP\fIbits\fP. See \fBBUGS\fP below.)
 .TP
 \fB\-\-xor\-tos\fP \fIbits\fP
 Binary XOR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/0\fP.)
+\fIbits\fP\fB/0\fP. See \fBBUGS\fP below.)
diff -urNp iptables-1.4.11.1-orig/iptables/ip6tables.8.in iptables-1.4.11.1/iptables/ip6tables.8.in
--- iptables-1.4.11.1-orig/iptables/ip6tables.8.in	2011-06-08 22:26:17.000000000 +0900
+++ iptables-1.4.11.1/iptables/ip6tables.8.in	2011-06-16 17:08:42.222014375 +0900
@@ -380,7 +380,18 @@ invalid or abused command line parameter
 other errors cause an exit code of 1.
 .SH BUGS
 Bugs?  What's this? ;-)
+.PP
 Well... the counters are not reliable on sparc64.
+.PP
+In Linux kernels up to and including 2.6.38, with the exception of longterm
+releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug whereby
+IPv6 TOS mangling does not behave as documented and differs from the IPv4
+version. The TOS mask indicates the bits one wants to zero out, so it needs to
+be inverted before applying it to the original TOS field. However, the
+aformentioned kernels forgo the inversion which breaks --set-tos and its
+mnemonics.
+.PP
+You might also want to have a look at http://bugzilla.netfilter.org/
 .SH COMPATIBILITY WITH IPCHAINS
 This \fBip6tables\fP
 is very similar to ipchains by Rusty Russell.  The main difference is
diff -urNp iptables-1.4.11.1-orig/iptables/iptables.8.in iptables-1.4.11.1/iptables/iptables.8.in
--- iptables-1.4.11.1-orig/iptables/iptables.8.in	2011-06-08 22:26:17.000000000 +0900
+++ iptables-1.4.11.1/iptables/iptables.8.in	2011-06-16 17:08:10.933614702 +0900
@@ -379,7 +379,16 @@ invalid or abused command line parameter
 other errors cause an exit code of 1.
 .SH BUGS
 Bugs?  What's this? ;-)
-Well, you might want to have a look at http://bugzilla.netfilter.org/
+.PP
+In Linux kernels up to and including 2.6.38, with the exception of longterm
+releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug whereby
+IPv6 TOS mangling does not behave as documented and differs from the IPv4
+version. The TOS mask indicates the bits one wants to zero out, so it needs to
+be inverted before applying it to the original TOS field. However, the
+aformentioned kernels forgo the inversion which breaks --set-tos and its
+mnemonics.
+.PP
+You might also want to have a look at http://bugzilla.netfilter.org/
 .SH COMPATIBILITY WITH IPCHAINS
 This \fBiptables\fP
 is very similar to ipchains by Rusty Russell.  The main difference is

Re: [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Jan Engelhardt]

On Thursday 2011-06-16 10:36, Fernando Luis Vazquez Cao wrote:

>Jan, Patrick,
>
>I would like to get this bug in old Linux kernels documented in the
>iptables man page, since it is pretty serious. The fix made into 2.6.39
>and I would like to have it backported to 2.6.32-longterm and
>2.6.33-longterm. If you disagree with the backport to -longterm please
>let me know, I would update the patch accordingly.

> .SH BUGS
> Bugs?  What's this? ;-)
>+.PP
> Well... the counters are not reliable on sparc64.
>+.PP
>+In Linux kernels up to and including 2.6.38, with the exception of longterm
>+releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug whereby
>+IPv6 TOS mangling does not behave as documented and differs from the IPv4
>+version. The TOS mask indicates the bits one wants to zero out, so it needs to
>+be inverted before applying it to the original TOS field. However, the
>+aformentioned kernels forgo the inversion which breaks --set-tos and its
>+mnemonics.
>+.PP
>+You might also want to have a look at http://bugzilla.netfilter.org/
> .SH COMPATIBILITY WITH IPCHAINS
> This \fBip6tables\fP
> is very similar to ipchains by Rusty Russell.  The main difference is

I feel this should be listed in the TOS page, to avoid duplication.

Re: [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Patrick McHardy]

On 16.06.2011 17:06, Jan Engelhardt wrote:
> On Thursday 2011-06-16 10:36, Fernando Luis Vazquez Cao wrote:
> 
>> Jan, Patrick,
>>
>> I would like to get this bug in old Linux kernels documented in the
>> iptables man page, since it is pretty serious. The fix made into 2.6.39
>> and I would like to have it backported to 2.6.32-longterm and
>> 2.6.33-longterm. If you disagree with the backport to -longterm please
>> let me know, I would update the patch accordingly.

That's fine with me.

>> .SH BUGS
>> Bugs?  What's this? ;-)
>> +.PP
>> Well... the counters are not reliable on sparc64.
>> +.PP
>> +In Linux kernels up to and including 2.6.38, with the exception of longterm
>> +releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug whereby
>> +IPv6 TOS mangling does not behave as documented and differs from the IPv4
>> +version. The TOS mask indicates the bits one wants to zero out, so it needs to
>> +be inverted before applying it to the original TOS field. However, the
>> +aformentioned kernels forgo the inversion which breaks --set-tos and its
>> +mnemonics.
>> +.PP
>> +You might also want to have a look at http://bugzilla.netfilter.org/
>> .SH COMPATIBILITY WITH IPCHAINS
>> This \fBip6tables\fP
>> is very similar to ipchains by Rusty Russell.  The main difference is
> 
> I feel this should be listed in the TOS page, to avoid duplication.

I agree with Jan, just the TOS man page seems fine.

Re: [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Fernando Luis Vázquez Cao]

Hi Jan, Patrick,

On Thu, 2011-06-16 at 17:15 +0200, Patrick McHardy wrote:
> On 16.06.2011 17:06, Jan Engelhardt wrote:
> > I feel this should be listed in the TOS page, to avoid duplication.
> 
> I agree with Jan, just the TOS man page seems fine.

I will be replying to this email with the update patch.

Thanks,
Fernando

[PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Fernando Luis Vázquez Cao]

In Linux kernels up to and including 2.6.38, with the exception of longterm
releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug (*) whereby
IPv6 TOS mangling does not behave as documented and differs from the IPv4
version. The TOS mask indicates the bits one wants to zero out, so it needs to
be inverted before applying it to the original TOS field. However, the
aformentioned kernels forgo the inversion which breaks --set-tos and its
mnemonics.

(*) Fixed by upstream commit:
    1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 (netfilter: IPv6: fix DSCP mangle code)

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---

diff -urNp iptables-1.4.11.1-orig/extensions/libxt_TOS.man iptables-1.4.11.1/extensions/libxt_TOS.man
--- iptables-1.4.11.1-orig/extensions/libxt_TOS.man	2011-06-08 22:26:17.000000000 +0900
+++ iptables-1.4.11.1/extensions/libxt_TOS.man	2011-06-17 10:07:58.873127519 +0900
@@ -4,24 +4,33 @@ shares the same bits as DSCP and ECN. Th
 \fBmangle\fP table.
 .TP
 \fB\-\-set\-tos\fP \fIvalue\fP[\fB/\fP\fImask\fP]
-Zeroes out the bits given by \fImask\fP and XORs \fIvalue\fP into the
-TOS/Priority field. If \fImask\fP is omitted, 0xFF is assumed.
+Zeroes out the bits given by \fImask\fP (see NOTE below) and XORs \fIvalue\fP
+into the TOS/Priority field. If \fImask\fP is omitted, 0xFF is assumed.
 .TP
 \fB\-\-set\-tos\fP \fIsymbol\fP
 You can specify a symbolic name when using the TOS target for IPv4. It implies
-a mask of 0xFF. The list of recognized TOS names can be obtained by calling
-iptables with \fB\-j TOS \-h\fP.
+a mask of 0xFF (see NOTE below). The list of recognized TOS names can be
+obtained by calling iptables with \fB\-j TOS \-h\fP.
 .PP
 The following mnemonics are available:
 .TP
 \fB\-\-and\-tos\fP \fIbits\fP
 Binary AND the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos
-0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.)
+0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.
+See NOTE below.)
 .TP
 \fB\-\-or\-tos\fP \fIbits\fP
 Binary OR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/\fP\fIbits\fP.)
+\fIbits\fP\fB/\fP\fIbits\fP. See NOTE below.)
 .TP
 \fB\-\-xor\-tos\fP \fIbits\fP
 Binary XOR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/0\fP.)
+\fIbits\fP\fB/0\fP. See NOTE below.)
+.PP
+NOTE: In Linux kernels up to and including 2.6.38, with the exception of
+longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
+whereby IPv6 TOS mangling does not behave as documented and differs from the
+IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
+to be inverted before applying it to the original TOS field. However, the
+aformentioned kernels forgo the inversion which breaks --set-tos and its
+mnemonics.

Re: [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels

[Patrick McHardy]

On 17.06.2011 03:14, Fernando Luis V�zquez Cao wrote:
> In Linux kernels up to and including 2.6.38, with the exception of longterm
> releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug (*) whereby
> IPv6 TOS mangling does not behave as documented and differs from the IPv4
> version. The TOS mask indicates the bits one wants to zero out, so it needs to
> be inverted before applying it to the original TOS field. However, the
> aformentioned kernels forgo the inversion which breaks --set-tos and its
> mnemonics.
> 
> (*) Fixed by upstream commit:
>     1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 (netfilter: IPv6: fix DSCP mangle code)
> 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iptables/man: IPv6 TOS mangling fix was backported to 2.6.35-longterm too

[Fernando Luis Vázquez Cao]

Update man page accordingly.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---

diff -urNp iptables-orig/extensions/libxt_TOS.man iptables/extensions/libxt_TOS.man
--- iptables-orig/extensions/libxt_TOS.man	2011-07-11 17:41:10.000000000 +0900
+++ iptables/extensions/libxt_TOS.man	2011-08-02 09:59:27.356614494 +0900
@@ -28,9 +28,9 @@ Binary XOR the TOS value with \fIbits\fP
 \fIbits\fP\fB/0\fP. See NOTE below.)
 .PP
 NOTE: In Linux kernels up to and including 2.6.38, with the exception of
-longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
-whereby IPv6 TOS mangling does not behave as documented and differs from the
-IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
-to be inverted before applying it to the original TOS field. However, the
+longterm releases 2.6.32 (>=.42), 2.6.33 (>=.15), and 2.6.35 (>=.14), there is
+a bug whereby IPv6 TOS mangling does not behave as documented and differs from
+the IPv4 version. The TOS mask indicates the bits one wants to zero out, so it
+needs to be inverted before applying it to the original TOS field. However, the
 aformentioned kernels forgo the inversion which breaks --set-tos and its
 mnemonics.

Re: [PATCH] iptables/man: IPv6 TOS mangling fix was backported to 2.6.35-longterm too

[Fernando Luis Vazquez Cao]

Fernando Luis Vázquez Cao wrote:
> Update man page accordingly.
> 
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> ---
> 
> diff -urNp iptables-orig/extensions/libxt_TOS.man iptables/extensions/libxt_TOS.man
> --- iptables-orig/extensions/libxt_TOS.man	2011-07-11 17:41:10.000000000 +0900
> +++ iptables/extensions/libxt_TOS.man	2011-08-02 09:59:27.356614494 +0900
> @@ -28,9 +28,9 @@ Binary XOR the TOS value with \fIbits\fP
>  \fIbits\fP\fB/0\fP. See NOTE below.)
>  .PP
>  NOTE: In Linux kernels up to and including 2.6.38, with the exception of
> -longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
> -whereby IPv6 TOS mangling does not behave as documented and differs from the
> -IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
> -to be inverted before applying it to the original TOS field. However, the
> +longterm releases 2.6.32 (>=.42), 2.6.33 (>=.15), and 2.6.35 (>=.14), there is
> +a bug whereby IPv6 TOS mangling does not behave as documented and differs from
> +the IPv4 version. The TOS mask indicates the bits one wants to zero out, so it
> +needs to be inverted before applying it to the original TOS field. However, the
>  aformentioned kernels forgo the inversion which breaks --set-tos and its
>  mnemonics.

Ping?

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iptables/man: IPv6 TOS mangling fix was backported to 2.6.35-longterm too

[Jan Engelhardt]

On Wednesday 2011-08-24 04:55, Fernando Luis Vazquez Cao wrote:

>Fernando Luis Vázquez Cao wrote:
>> Update man page accordingly.
>> 
>> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
>> ---
>> 
>> -longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
>> -whereby IPv6 TOS mangling does not behave as documented and differs from the
>> -IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
>> -to be inverted before applying it to the original TOS field. However, the
>> +longterm releases 2.6.32 (>=.42), 2.6.33 (>=.15), and 2.6.35 (>=.14), there is
>> +a bug whereby IPv6 TOS mangling does not behave as documented and differs from
>> +the IPv4 version. The TOS mask indicates the bits one wants to zero out, so it
>> +needs to be inverted before applying it to the original TOS field. However, the
>>  aformentioned kernels forgo the inversion which breaks --set-tos and its
>>  mnemonics.
>
>Ping?

Patch picked up now.

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Fernando Luis Vázquez Cao]

On Mon, 2011-06-06 at 06:44 -0700, Maciej Żenczykowski wrote:
> > The mask indicates the bits one wants to zero out, so it needs to be
> > inverted before applying to the original TOS field.
> 
> Uhm, does it?

Yes.

> (mind you I haven't looked at the documentation of the feature, but
> I'm still pretty sure the right fix here is to change the docs, not
> the functionality)

You should read the documentation. What is more if you check the IPv4
implementation you will see that it is doing the right thing and
inverting the mask before applying the logical and to it. This bug went
unnoticed for so long (in fact it has been broken since day one) because
IPv6 packets being mangled tend to have their DSCP field zeroed out (it
used to be random before 4319cc0cf5bb894b7368008cdf6dd20eb8868018 -
netfilter: IPv6: initialize TOS field in REJECT target module).

- Fernando

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Maciej Żenczykowski]

I'm still opposed on the grounds that there may be people relying on
the current behaviour.
This should not make it into the stable series of kernels.
I can understand fixing it for a future upstream release.

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Fernando Luis Vázquez Cao]

On Mon, 2011-06-06 at 21:15 -0700, Maciej Żenczykowski wrote:
> I'm still opposed on the grounds that there may be people relying on
> the current behaviour.

That is not my call, but I can tell you that I wrote this patch in
response to a report from several carriers that were complaining that
Linux' mangling code was completely broken and unusable.

From my experience, we are in a situation where people used to IPv4's
mangling code are starting to migrate to IPv6 only to find out that some
of their iptables rules do not work as expected, the reason (unknown to
them) being that IPv6's DSCP mangling code was not implemented according
to the documentation.

I would think that the benefit of fixing this outweighs the risk of
breaking some systems relying on the current behavior, which is the
opposite of what the documentation says and what its IPv4 counterpart
does.

> This should not make it into the stable series of kernels.
> I can understand fixing it for a future upstream release.

At the very least,

[PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

is needed (of course, I would like to have 2/2 patch applied too).
Without this patch the TOS field of IPv6 packets generated by the REJECT
target module is random.

- Fernando

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Fernando Luis Vázquez Cao]

On Tue, 2011-06-07 at 13:51 +0900, Fernando Luis Vázquez Cao wrote:
> On Mon, 2011-06-06 at 21:15 -0700, Maciej Żenczykowski wrote:
> > I'm still opposed on the grounds that there may be people relying on
> > the current behaviour.
> 
> That is not my call, but I can tell you that I wrote this patch in
> response to a report from several carriers that were complaining that
> Linux' mangling code was completely broken and unusable.
> 
> From my experience, we are in a situation where people used to IPv4's
> mangling code are starting to migrate to IPv6 only to find out that some
> of their iptables rules do not work as expected, the reason (unknown to
> them) being that IPv6's DSCP mangling code was not implemented according
> to the documentation.
> 
> I would think that the benefit of fixing this outweighs the risk of
> breaking some systems relying on the current behavior, which is the
> opposite of what the documentation says and what its IPv4 counterpart
> does.

As an aside, we could even add a note to the relevant man page saying
that the IPv6 DSCP mangle code used to be broken but not anymore (it has
been done before).

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

[Maciej Żenczykowski]

> As an aside, we could even add a note to the relevant man page saying
> that the IPv6 DSCP mangle code used to be broken but not anymore (it has
> been done before).

That sounds reasonable - especially if we make it clear which versions
of the kernel are affected.
Unfortunately, people upgrade kernel and utilities seperately...
[theoretically iptables could detect kernel version and automatically
invert the mask for too old kernels...]

Re: [stable] [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[Greg KH]

On Mon, Jun 06, 2011 at 02:41:10AM +0200, pablo@netfilter.org wrote:
> From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> 
> The IPv6 header is not zeroed out in alloc_skb so we must initialize
> it properly unless we want to see IPv6 packets with random TOS fields
> floating around. The current implementation resets the flow label
> but this could be changed if deemed necessary.
> 
> We stumbled upon this issue when trying to apply a mangle rule to
> the RST packet generated by the REJECT target module.
> 
> The following Linux kernels are affected: <= 2.6.38.8
> 
> Cc: stable@kernel.org
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> (cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)

So, what kernel(s) are you wanting this to be applied to?

Should I just take the upstream
4319cc0cf5bb894b7368008cdf6dd20eb8868018, or does your backport do
something different here?

Same goes for the 2/2 patch, please be more specific.

thanks,

greg k-h

Re: [stable] [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[Fernando Luis Vázquez Cao]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On Mon, 2011-06-06 at 10:36 -0700, Greg KH wrote:
> On Mon, Jun 06, 2011 at 02:41:10AM +0200, pablo@netfilter.org wrote:
> > From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > 
> > The IPv6 header is not zeroed out in alloc_skb so we must initialize
> > it properly unless we want to see IPv6 packets with random TOS fields
> > floating around. The current implementation resets the flow label
> > but this could be changed if deemed necessary.
> > 
> > We stumbled upon this issue when trying to apply a mangle rule to
> > the RST packet generated by the REJECT target module.
> > 
> > The following Linux kernels are affected: <= 2.6.38.8
> > 
> > Cc: stable@kernel.org
> > Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > (cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)
> 
> So, what kernel(s) are you wanting this to be applied to?

Both patches fix bugs that have present from day one, so, ideally, I
would like to have them applied to all the stable and longterm kernels:

linux-2.6.38.8
linux-2.6.37.6
linux-2.6.36.4
linux-2.6.35.13
linux-2.6.34.9
linux-2.6.33.14
linux-2.6.32.41
linux-2.6.27.59

> Should I just take the upstream
> 4319cc0cf5bb894b7368008cdf6dd20eb8868018, or does your backport do
> something different here?

[PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module
For linux-2.6.38.8 you can take the upstream
4319cc0cf5bb894b7368008cdf6dd20eb8868018. For linux-2.6.37.6,
linux-2.6.36.4, linux-2.6.35.13, linux-2.6.34.9, linux-2.6.33.14,
linux-2.6.32.41, and linux-2.6.27.59 you will need to use the attached
backport.

[PATCH 2/2] netfilter: IPv6: fix DSCP mangle code
The upstream patch 1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 applies
cleanly to all the kernels above.

- Fernando

[-- Attachment #2: netfilter-IPv6-initialize-TOS-field-in-REJECT-target-module-2.6.27-2.6.37.patch --]
[-- Type: text/x-patch, Size: 1663 bytes --]

From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>

The IPv6 header is not zeroed out in alloc_skb so we must initialize
it properly unless we want to see IPv6 packets with random TOS fields
floating around. The current implementation resets the flow label
but this could be changed if deemed necessary.

We stumbled upon this issue when trying to apply a mangle rule to
the RST packet generated by the REJECT target module.

The following Linux kernels are affected: <= 2.6.38.8

Cc: stable@kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)
---

diff -urNp linux-2.6.32.41-orig/net/ipv6/netfilter/ip6t_REJECT.c linux-2.6.32.41/net/ipv6/netfilter/ip6t_REJECT.c
--- linux-2.6.32.41-orig/net/ipv6/netfilter/ip6t_REJECT.c	2011-06-07 10:40:05.000000000 +0900
+++ linux-2.6.32.41/net/ipv6/netfilter/ip6t_REJECT.c	2011-06-07 10:30:00.000000000 +0900
@@ -43,6 +43,8 @@ static void send_reset(struct net *net,
 	int tcphoff, needs_ack;
 	const struct ipv6hdr *oip6h = ipv6_hdr(oldskb);
 	struct ipv6hdr *ip6h;
+#define DEFAULT_TOS_VALUE	0x0U
+	const __u8 tclass = DEFAULT_TOS_VALUE;
 	struct dst_entry *dst = NULL;
 	u8 proto;
 	struct flowi fl;
@@ -121,7 +123,7 @@ static void send_reset(struct net *net,
 	skb_put(nskb, sizeof(struct ipv6hdr));
 	skb_reset_network_header(nskb);
 	ip6h = ipv6_hdr(nskb);
-	ip6h->version = 6;
+	*(__be32 *)ip6h =  htonl(0x60000000 | (tclass << 20));
 	ip6h->hop_limit = dst_metric(dst, RTAX_HOPLIMIT);
 	ip6h->nexthdr = IPPROTO_TCP;
 	ipv6_addr_copy(&ip6h->saddr, &oip6h->daddr);

Re: [stable] [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[Greg KH]

On Tue, Jun 07, 2011 at 11:39:33AM +0900, Fernando Luis Vázquez Cao wrote:
> On Mon, 2011-06-06 at 10:36 -0700, Greg KH wrote:
> > On Mon, Jun 06, 2011 at 02:41:10AM +0200, pablo@netfilter.org wrote:
> > > From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > > 
> > > The IPv6 header is not zeroed out in alloc_skb so we must initialize
> > > it properly unless we want to see IPv6 packets with random TOS fields
> > > floating around. The current implementation resets the flow label
> > > but this could be changed if deemed necessary.
> > > 
> > > We stumbled upon this issue when trying to apply a mangle rule to
> > > the RST packet generated by the REJECT target module.
> > > 
> > > The following Linux kernels are affected: <= 2.6.38.8
> > > 
> > > Cc: stable@kernel.org
> > > Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > > (cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)
> > 
> > So, what kernel(s) are you wanting this to be applied to?
> 
> Both patches fix bugs that have present from day one, so, ideally, I
> would like to have them applied to all the stable and longterm kernels:
> 
> linux-2.6.38.8
> linux-2.6.37.6
> linux-2.6.36.4
> linux-2.6.35.13
> linux-2.6.34.9
> linux-2.6.33.14
> linux-2.6.32.41
> linux-2.6.27.59
> 
> > Should I just take the upstream
> > 4319cc0cf5bb894b7368008cdf6dd20eb8868018, or does your backport do
> > something different here?
> 
> [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module
> For linux-2.6.38.8 you can take the upstream
> 4319cc0cf5bb894b7368008cdf6dd20eb8868018. For linux-2.6.37.6,
> linux-2.6.36.4, linux-2.6.35.13, linux-2.6.34.9, linux-2.6.33.14,
> linux-2.6.32.41, and linux-2.6.27.59 you will need to use the attached
> backport.

Ok, but this doesn't apply at all to the 2.6.39-stable kernel.

And .38-stable is end-of-life, as is .36-stable and .37-stable.

So, care to start all over again?

I need patches that apply to the .39-stable tree.

And then to any other stable kernel that you wish to have them apply to.
Currently "live" kernels are .32-longterm, .33-longterm, .34-longterm,
and .35-longterm.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[Fernando Luis Vázquez Cao]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Hi Craig,

On Tue, 2011-06-14 at 17:11 -0700, Greg KH wrote:
> On Tue, Jun 07, 2011 at 11:39:33AM +0900, Fernando Luis Vázquez Cao wrote:
> > [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module
> > For linux-2.6.38.8 you can take the upstream
> > 4319cc0cf5bb894b7368008cdf6dd20eb8868018. For linux-2.6.37.6,
> > linux-2.6.36.4, linux-2.6.35.13, linux-2.6.34.9, linux-2.6.33.14,
> > linux-2.6.32.41, and linux-2.6.27.59 you will need to use the attached
> > backport.
> 
> Ok, but this doesn't apply at all to the 2.6.39-stable kernel.

The reason is that both patch 1/2 and patch 2/2 are already in 2.6.39,
which is from where I would like to have them backported.


> So, care to start all over again?

Sure


> I need patches that apply to the .39-stable tree.

As mentioned above they were merged during the 2.6.39 merge window.


> And then to any other stable kernel that you wish to have them apply to.
> Currently "live" kernels are .32-longterm, .33-longterm, .34-longterm,
> and .35-longterm.

I would like to have them applied to all those. The patches are:

1. [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code

   This one you can take from upstream commit
   1ed2f73d90fb49bcf5704aee7e9084adb882bfc5.

2. [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

   The upstream patch would not apply cleanly so use the attached patch
   instead.

Thanks,
Fernando

[-- Attachment #2: netfilter-IPv6-initialize-TOS-field-in-REJECT-target-module-2.6.32~2.6.35.patch --]
[-- Type: text/x-patch, Size: 1663 bytes --]

From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>

The IPv6 header is not zeroed out in alloc_skb so we must initialize
it properly unless we want to see IPv6 packets with random TOS fields
floating around. The current implementation resets the flow label
but this could be changed if deemed necessary.

We stumbled upon this issue when trying to apply a mangle rule to
the RST packet generated by the REJECT target module.

The following Linux kernels are affected: <= 2.6.38.8

Cc: stable@kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018)
---

diff -urNp linux-2.6.32.41-orig/net/ipv6/netfilter/ip6t_REJECT.c linux-2.6.32.41/net/ipv6/netfilter/ip6t_REJECT.c
--- linux-2.6.32.41-orig/net/ipv6/netfilter/ip6t_REJECT.c	2011-06-07 10:40:05.000000000 +0900
+++ linux-2.6.32.41/net/ipv6/netfilter/ip6t_REJECT.c	2011-06-07 10:30:00.000000000 +0900
@@ -43,6 +43,8 @@ static void send_reset(struct net *net,
 	int tcphoff, needs_ack;
 	const struct ipv6hdr *oip6h = ipv6_hdr(oldskb);
 	struct ipv6hdr *ip6h;
+#define DEFAULT_TOS_VALUE	0x0U
+	const __u8 tclass = DEFAULT_TOS_VALUE;
 	struct dst_entry *dst = NULL;
 	u8 proto;
 	struct flowi fl;
@@ -121,7 +123,7 @@ static void send_reset(struct net *net,
 	skb_put(nskb, sizeof(struct ipv6hdr));
 	skb_reset_network_header(nskb);
 	ip6h = ipv6_hdr(nskb);
-	ip6h->version = 6;
+	*(__be32 *)ip6h =  htonl(0x60000000 | (tclass << 20));
 	ip6h->hop_limit = dst_metric(dst, RTAX_HOPLIMIT);
 	ip6h->nexthdr = IPPROTO_TCP;
 	ipv6_addr_copy(&ip6h->saddr, &oip6h->daddr);

Re: [stable] [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module

[Greg KH]

On Wed, Jun 15, 2011 at 03:19:44PM +0900, Fernando Luis Vázquez Cao wrote:
> Hi Craig,
> 
> On Tue, 2011-06-14 at 17:11 -0700, Greg KH wrote:
> > On Tue, Jun 07, 2011 at 11:39:33AM +0900, Fernando Luis Vázquez Cao wrote:
> > > [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module
> > > For linux-2.6.38.8 you can take the upstream
> > > 4319cc0cf5bb894b7368008cdf6dd20eb8868018. For linux-2.6.37.6,
> > > linux-2.6.36.4, linux-2.6.35.13, linux-2.6.34.9, linux-2.6.33.14,
> > > linux-2.6.32.41, and linux-2.6.27.59 you will need to use the attached
> > > backport.
> > 
> > Ok, but this doesn't apply at all to the 2.6.39-stable kernel.
> 
> The reason is that both patch 1/2 and patch 2/2 are already in 2.6.39,
> which is from where I would like to have them backported.
> 
> 
> > So, care to start all over again?
> 
> Sure
> 
> 
> > I need patches that apply to the .39-stable tree.
> 
> As mentioned above they were merged during the 2.6.39 merge window.
> 
> 
> > And then to any other stable kernel that you wish to have them apply to.
> > Currently "live" kernels are .32-longterm, .33-longterm, .34-longterm,
> > and .35-longterm.
> 
> I would like to have them applied to all those. The patches are:
> 
> 1. [PATCH 2/2] netfilter: IPv6: fix DSCP mangle code
> 
>    This one you can take from upstream commit
>    1ed2f73d90fb49bcf5704aee7e9084adb882bfc5.
> 
> 2. [PATCH 1/2] netfilter: IPv6: initialize TOS field in REJECT target module
> 
>    The upstream patch would not apply cleanly so use the attached patch
>    instead.

Ok, I've queued them up for the .32 and .33-longterm kernels, I'll let
the other longterm kernel maintainers apply them if they get around to
doing new releases of their trees.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html