Ok, I'm thinking maybe the 2.0.33 box isn't the prob. I look at syslog
messages on the 2.1.90 box and see this:
Mar 21 11:24:38 bengal kernel: TCPv4 bad checksum from 206.202.0.2:0017 to 206.202.2.150:0456, len=20/20/40
Mar 21 11:27:59 bengal kernel: TCPv4 bad checksum from 206.202.0.2:0017 to 206.202.2.150:0456, len=20/20/40
Mar 21 11:28:45 bengal kernel: TCPv4 bad checksum from 206.202.0.2:0017 to 206.202.2.150:0454, len=20/20/40
Mar 21 11:29:12 bengal kernel: TCPv4 bad checksum from 206.202.0.2:0017 to 206.202.2.150:045a, len=20/20/40
Mar 21 11:29:15 bengal kernel: TCPv4 bad checksum from 206.202.0.3:0017 to 206.202.2.150:045b, len=20/20/40
Mar 21 11:29:36 bengal kernel: TCPv4 bad checksum from 206.202.0.3:0017 to 206.202.2.150:045b, len=20/20/40
(0.2 is Linux server, 0.3 is Sun, 2.150 is Linux 2.1.90 btw)
Duh, a silly fix did not make it into 2.1.90 it appears.
In linux/net/ipv4/tcp.c:tcp_do_sendmsg() change:
int last_byte_was_odd = (copy & 1);
to be instead
int last_byte_was_odd = (copy % 4);
Checksum problems will go away, and so will the stuck connections.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu