Re: Massive TCPv4 bad checksum

Meelis Roos (mroos@tartu.cyber.ee)
Mon, 19 Oct 1998 23:11:59 +0300

>> Most of the bad packets are from ftp and rsh. As the result, my
>> ftp and CVS over rsh on my CSLIP link are much slower than 2.0.

GU> Mine come mostly from ssh, and some from auth:

GU> TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.15:0016, len=20/20/40
GU> TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.4:0016, len=20/20/40
GU> TCPv4 bad checksum from 10.0.24.8:0071 to 10.0.24.4:04e2, len=20/20/40

GU> 10.0.24.4 = m68k
GU> 10.0.24.8 = PPC
GU> 10.0.24.15 = AXP

Me too. ssh-ing from to 10.0.249.90 through an application-level proxy on
10.0.16.128:

TCPv4 bad checksum from 10.0.249.90:0016 to 10.0.16.128:0946, len=33/33/53

The last column and the higher port number vary:
len=120/120/140
len=136/136/156
len=160/160/180
len=20/20/40
len=200/200/220
len=256/256/276
len=31/31/51
len=33/33/53
len=336/336/356
len=35/35/55
len=36/36/56
len=360/360/380
len=37/37/57
len=40/40/60
len=47/47/67
len=51/51/71
len=56/56/76
len=65/65/85
len=94/94/114

10.0.249.90 has slip connection to a cisco, 10.0.16.128 has ethernet
connection.

10.0.249.90 is 2.0.34 (maybe some messages are from 2.0.33 time).
10.0.16.128 is 2.1.103
Both are x86.

Just tried to reproduce it. In short - I couldn't.

I usually ssh to this host and sometimes I log out and sometimes the proxy
decides to shut down the connection so the connection can be closed from
either side.

-- 
Meelis Roos (mroos@tartu.cyber.ee)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/