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 <g...@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 g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
