netdev - Re: [Bugme-new] [Bug 34322] New: No ECN marking in IPv6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 May 2011 14:41:46 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	netdev@...r.kernel.org
Cc:	bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org, sgunderson@...foot.com
Subject: Re: [Bugme-new] [Bug 34322] New: No ECN marking in IPv6


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 3 May 2011 20:05:00 GMT
bugzilla-daemon@...zilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=34322
> 
>            Summary: No ECN marking in IPv6
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 2.6.38.4
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV6
>         AssignedTo: yoshfuji@...ux-ipv6.org
>         ReportedBy: sgunderson@...foot.com
>         Regression: No
> 
> 
> Hi,
> 
> I'm completely unable to get ECN to work for IPv6. /proc/sys/net/ipv4/tcp_ecn
> is set to 1 on both sides, and ECN works just fine for IPv4 TCP connections,
> but when I connect over IPv6 tclass just stays at 0x0, and as far as I'd
> understood, there should be two bits here set to 10 (like in the diffserv field
> of IPv4), right?
> 
> I do get ECN-echo bits in the TCP header, though (for the initial SYN and
> SYN/ACK  packets).
> 

and

> I looked at the code, and although I don't understand all of it, it
> looks like e9df2e8fd8fbc95c57dbd1d33dada66c4627b44c (which also brought
> ECN for IPv6 SCTP) might be the culprit.  It seems like TCP_ECN_send()
> calls INET_ECN_xmit(), which only sets the ECN bit in the IPv4 ToS
> field (inet_sk(sk)->tos), but after the patch, what's checked is
> inet6_sk(sk)->tclass, which is a completely different field.
> 
> Is the analysis correct? Should the tclass be set as well?

and

> OK, as a quick hack, I did this:
> 
> --- a/linux-2.6.38.5/include/net/inet_ecn.h    2011-04-14 22:03:56.000000000+0200
> +++ b/linux-2.6.38.5/include/net/inet_ecn.h    2011-05-04 00:36:52.803377902+0200
> @@ -38,7 +38,7 @@
>      return outer;
>  }
> 
> -#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)
> +#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; if (inet6_sk(sk) != NULL) inet6_sk(sk)->tclass |= INET_ECN_ECT_0; } while (0)
>  #define    INET_ECN_dontxmit(sk) \
>      do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0)
> 
> and now my packets are properly marked with tclass 0x02 (ie.,
> signalling ECN-capable transport, no congestion experienced yet).
> 
> I guess this isn't the right way of doing it, but at least it confirms
> that the lack of setting tclass is part of the problem.

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