:Please try testing with following patch:
:http://leaf.dragonflybsd.org/~sephe/nfe_csum.diff
:
:It should make turning on/off rxcsum/txcsum separately work. And
:let's see which one generate wrong csum.
:
:Best Regards,
:sephe
NFS client running on machine with NFE interface.
txcsum works
rxcsum does not
tcpdump -vvvvv -s 4096 -n -i nfe0 -l not port 22
-Matt
client sends readdir request. Note that tcpdump is properly
reporting 'bad cksum' since when txcsum is turned on the packet
checksum is left set to zero so hardware can calculate the correct
checksum to insert.
10:41:42.521057 IP (tos 0x0, ttl 64, id 31776, offset 0, flags [none], proto:
UDP (17), length: 168, bad cksum 0 (->fa0e)!) 216.240.41.28.1399809221 >
216.240.41.25.2049: 140 readdir fh
Unknown/01CFA141D029474010000000B34F0200000000004BFA0C470000000000000000 8192
bytes @ 0 verf 0000000000000000
client receives response. This response packet appears to be getting
thrown away. Insofar as I can tell the received checksum is ok.
10:41:42.521592 IP (tos 0x0, ttl 64, id 16804, offset 0, flags [+], proto: UDP
(17), length: 1500) 216.240.41.25.2049 > 216.240.41.28.1399809221: reply ok
1472 readdir POST: DIR 755 ids 0/0 sz 1024 verf 5e000000720392cc
10:41:42.521598 IP (tos 0x0, ttl 64, id 16804, offset 1480, flags [none],
proto: UDP (17), length: 216) 216.240.41.25 > 216.240.41.28: udp
--------
Now I ifconfig nfe0 -rxcsum and I get (from the same NFS retry
sequence):
10:48:10.346244 IP (tos 0x0, ttl 64, id 31959, offset 0, flags [none], proto:
UDP (17), length: 168, bad cksum 0 (->f957)!) 216.240.41.28.1399809221 >
216.240.41.25.2049: 140 readdir fh
Unknown/01CFA141D029474010000000B34F0200000000004BFA0C470000000000000000 8192
bytes @ 0 verf 0000000000000000
10:48:10.346729 IP (tos 0x0, ttl 64, id 4178, offset 0, flags [+], proto: UDP
(17), length: 1500) 216.240.41.25.2049 > 216.240.41.28.1399809221: reply ok
1472 readdir POST: DIR 755 ids 0/0 sz 1024 nlink 22 rdev 194/589983 fsid 27407
fileid 24fb3 a/m/ctime 1173632815.000000 1186616261.000000 1186616261.000000
verf 5e000000720392cc
10:48:10.346736 IP (tos 0x0, ttl 64, id 4178, offset 1480, flags [none],
proto: UDP (17), length: 216) 216.240.41.25 > 216.240.41.28: udp
Note that tcpdump reports a more expanded received packet now, but
I dont know if that means anything. The received packet is processed
by NFS and my ls of the NFS directory returns.
-Matt
