Tom Chen wrote: > Aug 6 16:04:44 [ID 393812 kern.notice] requested sending data: > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000000 : 00 30 48 63 ee > 0c 00 c0 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000008 : dd 07 4f 67 08 > 00 45 00 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000010 : 11 2c 2a 5a 40 > 00 40 06 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000018 : 00 00 c0 a8 0a > 32 c0 a8 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000020 : 0a 01 58 bf c0 > e9 14 c7 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000028 : c9 b1 7d b3 18 > 2a 80 18 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000030 : c0 50 00 00 00 > 00 01 01 > Aug 6 16:04:44 [ID 239987 kern.notice] 0x0000000000000038 : 08 0a 00 01 f5 > c5 01 99 > Aug 6 16:04:44 [ID 498692 kern.notice] 0x0000000000000040 : 0c c5 > Aug 6 16:04:44 [ID 547160 kern.notice] total requested sening data length > is: 66 > Aug 6 16:04:44 [ID 310828 kern.notice] hcksum_retrieve( ) returns start=48, > stuff=ffffff00,stop=3ab3040, mss=5a8,requested offload=0x14 (LSO and IPv4 > full checksum offloading)
According to hexdump, it looks like the ip_len is 11 2c, or 0x112c or 4396 bytes. I think you have a bug in your driver and are not handling chained mblks. In my driver, I've seen frames which use sendfile (like those which originate from ftpd probably will) have an mblk chain with one small header mblk, and then a number of file pages attached to subsequent mblks in the chain. The header mblk will be 66 bytes for a connection with an mss of 1448.. Does the linux side show any signs of truncated packets (ip checksum errors, etc) in netstat? Drew _______________________________________________ networking-discuss mailing list [email protected]
