![]() | |||||||||||||
Messages in this thread |
From: Mitch Adair <mitch@acan.net> Date: Sat, 21 Mar 1998 12:22:40 -0600 (CST) 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 | ||||||||||||
| Last update: 2005-03-22 12:41 [W:0.156 / U:0.090 seconds] ©2003-2008 Jasper Spaans | |||||||||||||