Hi Stéphane, On Wed, Jul 25, 2018 at 01:39:47AM +0200, Stéphane Poignant wrote: > On Sat, Jul 21, 2018 at 12:22:44PM +0200, Thomas Leuxner wrote: > > * Salvatore Bonaccorso <car...@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.
The fix is applied in our git packaging repository pending for 4.9.110-3 (which should go out via the *-updates machanism to fix regressions found in 4.9.110-1 from the 9.5 point release). Regards, Salvatore
