netdev - Re: When a TCP segment is split up (to be sent through a TUN device with a small MTU) who should recalculate the checksum?

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52862960.6090408@calva.com>
Date:	Fri, 15 Nov 2013 15:02:08 +0100
From:	John Hughes <john@...va.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	John Hughes <john@...antech.com>, netdev@...r.kernel.org
Subject: Re: When a TCP segment is split up (to be sent through a TUN device
 with a small MTU) who should recalculate the checksum?

On 15/11/13 14:06, Eric Dumazet wrote:
> On Fri, 2013-11-15 at 09:52 +0100, John Hughes wrote:
>> I have two offices, joined by a OpenVPN tunnel.  I've upgraded the
>> kernels in the machines running the tunnel to 3.10.  All of a sudden I'm
>> getting horrible transmission delays between the two offices.
>>
>> office1 LAN--------office1 tunnel machine
>>                               |
>>                               | openvpn tunnel
>>                               |
>>                       office2 tunnel machine------office2 LAN
>>                                     
>>
>> What seems to be happening is that packets are arriving at the LAN
>> interface of the machine running the tunnel and being combined by
>> generic-receive-offload.  These packets then have to be split up again
>> as they are too big for the tunnels MTU.
>>
>> But when the packets are split the TCP checksum doesn't seem to be being
>> recalculated, so the systems on the other end of the tunnel ignore them,
>> forcing many retries and the observed delays.
>>
>>
> Thanks for the report
>
> It depends on the offload capabilities of the NIC forwarding packets

The NIC is a kernel tun device.
>
> ethtool -k eth0

# ethtool -k tun1
Features for tun1:
rx-checksumming: off [fixed]
tx-checksumming: off
	tx-checksum-ipv4: off [fixed]
	tx-checksum-ip-generic: off [requested on]
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
...

It seems someone has asked the tunnel to compute checksums 
(tx-checksum-ip-generic), but it can't do that.


>
> TCP checksums can be recomputed by tcp_gso_segment() (it was named
> tcp_tso_segment() in linux 3.10), unless the NIC told it was doing the
> checksum computation itself.
>
> ethtool -K eth0 tx off
>
> Should request stack to perform the cheksums.
>
> What is the NIC doing the transmits ?
>
>
>

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