Re: incorrect tcp checksum on Linux tun interfaces?

[Gert Doering <gert () greenie muc de>]

Hi,

On Tue, Dec 04, 2012 at 11:09:43AM -0500, Michael Richardson wrote:
> {sorry if I'm a bit tardy at removing the emergency moderation that I
> turned on in order to keep junk off the list}

I understand that, which I wasn't bugging anyone about this :-)

> > > > > > "Gert" == Gert Doering <gert () greenie muc de> writes:
>     Gert> I'm a bit irritated by a byproduct of a problem hunt today, incorrect
>     Gert> TCP checksums on a *tun* interface...
>
>     Gert> 23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length: 40) fd00:abcd:194:7::1.33509 > 
> fd00:abcd:194:7::1000.2: S, cksum 0x6502 (incorrect (-> 0x3962), 1541095226:1541095226(0) win 14400 <mss 
> 1440,sackOK,timestamp 178211075 0,nop,wscale 6>
>
> What's curious to me is that the chsum is not zero. If it was being
> "offloaded" into a step after the PF_PACKET interface, it would be zero,
> right?

I'm not sure.  I find this highly irritating, and I'm fairly sure that
*here* are the folks that have seen all the funnies when tcpdumping on
specific interfaces...

>     Gert> 23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags [DF], proto TCP (6), length 60) 
> 10.194.7.1.52647 > 10.194.7.6.2: S, cksum 0x23b9 (incorrect (-> 0xd832), 2395069612:2395069612(0) win 14600 <mss 
> 1460,sackOK,timestamp 178245508 0,nop,wscale 6>
>
> Both for IPv4 and IPv6?

Yes.

>     Gert> (The tun goes into openvpn, and out of the other side's tun
>     Gert> comes a packet 
>
> openvpn does IPv6 now?

For point-to-point links, it did for a long time (but you had to set it
up manually on both ends).  For multipoint setups with a "server" that
assigns IPv6 addresses etc., this is new functionality in 2.3, to be 
released "real soon now".

> I suppose the next step would be to hexdump packets from /dev/net/tun.

I can try to do that, but I'm fairly sure that the packet is fine when it
really arrives "at the tun interface" - after all, it's coming *out* of 
the server side tun with a correct checksum:

Client tun (kernel->tun->openvpn):

23:03:32.016262 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP (6), length 60)
    10.194.7.6.42707 > 10.194.7.1.2: Flags [S], cksum 0x23b9 (incorrect -> 0x0ff4), seq 3558498516, win 14600, options 
[mss 1460,sackOK,TS val 2703974026 ecr 0,nop,wscale 6], length 0
23:03:33.264096 IP6 (hlim 64, next-header TCP (6) payload length: 40) fd00:abcd:194:7::1000.33677 > 
fd00:abcd:194:7::1.2: Flags [S], cksum 0x6502 (incorrect -> 0x4150), seq 1568376760, win 14400, options [mss 
1440,sackOK,TS val 2703974338 ecr 0,nop,wscale 6], length 0


Server tun (openvpn->tun->kernel), same two packets:

23:07:08.409938 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP (6), length 60) 10.194.7.6.42707 > 
10.194.7.1.2: S, cksum 0x104f (correct), 3558498516:3558498516(0) win 14600 <mss 1369,sackOK,timestamp 2703974026 
0,nop,wscale 6>
23:07:09.642172 IP6 (hlim 64, next-header TCP (6) payload length: 40) fd00:abcd:194:7::1000.33677 > 
fd00:abcd:194:7::1.2: S, cksum 0x4150 (correct), 1568376760:1568376760(0) win 14400 <mss 1440,sackOK,timestamp 
2703974338 0,nop,wscale 6>

(for the SYN-ACK, the "incorrect" bit is on the other end, so this is 
symmetric)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert () greenie muc de
fax: +49-89-35655025                        gert () net informatik tu-muenchen de
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers