Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #909254

Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings

Cross-posted to 2 groups.

Show all headers | View raw

On Sat, Jul 21, 2018 at 12:22:44PM +0200, Thomas Leuxner wrote:
 > * Salvatore Bonaccorso <carnil@debian.org> 2018.07.19 14:38:
 >
 > > Can you check if the attached patch fixes the issue for you?
 > >
 > > 
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
 > >
 > > Regards,
 > > Salvatore
 >
 > Thanks Salvatore. That regression fix did indeed fix it:


Hello,

I'm using the sit module to establish a 6in4 tunnel to connect to my 
IPv6 tunnel broker.

Two days ago, I upgraded from 4.9.0-6-amd64 to 4.9.0-7-amd64 and started 
experiencing random connection failures on IPv6 traffic. It looked like 
the new kernel was dropping some packets received from the remote tunnel 
endpoint (tcpdump saw them coming on the IPv4 interface but not on the 
IPv6 tunnel interface, and they were not processed by the host nor 
forwarded).

The link with the upgrade was confirmed since downgrading back to 
4.9.0-6-amd64 made the issue disappear.

After further testing I made the assumption that the triggering factor 
was a value of 1 for the third and forth bits of the IPv6 header Flow 
Label field, which I then successfully confirmed by generating traffic 
with arbitrary Flow Label values. 100% of the ping requests matching the 
condition were dropped, and 100% of those not matching the condition 
were answered.

I also noticed that everytime a packet was dropped, a line similar to 
this one appeared in the dmesg:

sit: non-ECT from 74.232.98.121 with TOS=0x3

It happens that the offset of those two bits relative to the beginning 
of the IPv6 header is the same as the offset of the ECN field relative 
to the start of a IPv4 header. In addition, the reported IP and TOS 
values were always matching the data at offset 11 and 1 of the 
encapsulated IPv6 header, which happens to be the same offset than the 
Source IP address and TOS fields in a IPv4 header.

In the light of this, I started suspecting that something inside the 
kernel was mistakenly interpreting the inner IPv6 header as an IPv4 
header and was probably the cause of the problem.

I then found this bug report after searching for the aforementioned 
dmesg message. And it turned out that there is clearly a link with my 
IPv6 issue: I was no longer reproducing with an kernel image built from 
since 4.9.110-1 with David S. Miller patch applied (and without changing 
anything else).

It looks like this bug has probably more severe consequences than only 
dmesg spam.

Best regards,
Stephane Poignant

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Thomas Leuxner <tlx@leuxner.net> - 2018-07-14 18:50 +0200
  Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Ben Hutchings <ben@decadent.org.uk> - 2018-07-17 23:00 +0200
  Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Ben Hutchings <ben@decadent.org.uk> - 2018-07-18 23:40 +0200
    Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Thomas Leuxner <tlx@leuxner.net> - 2018-07-19 11:40 +0200
      Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Salvatore Bonaccorso <carnil@debian.org> - 2018-07-19 14:50 +0200
        Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Thomas Leuxner <tlx@leuxner.net> - 2018-07-21 12:30 +0200
          Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Salvatore Bonaccorso <carnil@debian.org> - 2018-07-21 13:30 +0200
  Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings Stéphane Poignant <stephanepoignant@vialis.net> - 2018-07-25 02:00 +0200

csiph-web