Re: Strange TCP problem with awge0

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 2 Jan, 2015, at 08:02 , Martin Husemann <martin%duskware.de@localhost> wrote:
> This is very reliably 100% reproducable, for me and others (with a totally
> different network connection, so it is neither my ISP nor my router).
> 
> I have created some packet captures and stared at them, but I can't see
> what is wrong - looks like the ftp server is not seeing/acking our last
> packet, but *why* is that so, and why reproducably?

It looks to me like the packet that isn't being ack'd may actually be
going in the other direction, from the server to the client.  It is
always this one, the same in every trace:

06:30:36.457041 IP (tos 0x0, ttl 50, id 27541, offset 0, flags [DF], proto TCP (6), length 61)
    ftp.solnet.ch.ftp > ip-176-199-201-17.hsi06.unitymediagroup.de.65151: Flags [P.], cksum 0xe404 (correct), seq 1296:1305, ack 43, win 1040, options [nop,nop,TS val 3171079293 ecr 1], length 9
	0x0000:  4500 003d 6b95 4000 3206 89f3 d465 04f4  E..=k.@.2....e..
	0x0010:  b0c7 c911 0015 fe7f e09e abf3 1996 ee58  ...............X
	0x0020:  8018 0410 e404 0000 0101 080a bd02 d47d  ...............}
	0x0030:  0000 0001 3231 3120 456e 640d 0a         ....211.End..
06:30:43.504546 IP (tos 0x0, ttl 50, id 27553, offset 0, flags [DF], proto TCP (6), length 61)
    ftp.solnet.ch.ftp > ip-176-199-201-17.hsi06.unitymediagroup.de.65151: Flags [P.], cksum 0xc87c (correct), seq 1296:1305, ack 43, win 1040, options [nop,nop,TS val 3171086341 ecr 1], length 9
	0x0000:  4500 003d 6ba1 4000 3206 89e7 d465 04f4  E..=k.@.2....e..
	0x0010:  b0c7 c911 0015 fe7f e09e abf3 1996 ee58  ...............X
	0x0020:  8018 0410 c87c 0000 0101 080a bd02 f005  .....|..........
	0x0030:  0000 0001 3231 3120 456e 640d 0a         ....211.End..
06:30:57.402201 IP (tos 0x0, ttl 50, id 27811, offset 0, flags [DF], proto TCP (6), length 61)
    ftp.solnet.ch.ftp > ip-176-199-201-17.hsi06.unitymediagroup.de.65151: Flags [P.], cksum 0x9234 (correct), seq 1296:1305, ack 43, win 1040, options [nop,nop,TS val 3171100237 ecr 1], length 9
	0x0000:  4500 003d 6ca3 4000 3206 88e5 d465 04f4  E..=l.@.2....e..
	0x0010:  b0c7 c911 0015 fe7f e09e abf3 1996 ee58  ...............X
	0x0020:  8018 0410 9234 0000 0101 080a bd03 264d  .....4........&M
	0x0030:  0000 0001 3231 3120 456e 640d 0a         ....211.End..

In the Linux trace the same packet is sent, with the same sequence offset,
but is immediately ack'd by the client.

When this is going on with NetBSD are any of the netstat -s error counters
incrementing?  And is the IP/TCP checksum verification being done in software or
is the device hardware doing it instead?  If it is being done in hardware my
first guess, unencumbered by any facts or knowledge, would be that the checksum
hardware could be buggy and something about this packet is exercising the bug.

Dennis Ferguson