Hi all, I am testing tshark with revision 21520. Running tshark on an NFS capture gives different output between the two machines I am testing it on.
On the first machine, a P4, the command I run is: wireshark $ ./tshark -R nfs -r ~/docs/work/traffic_dumps/bigops2 -o "tcp.desegment_tcp_streams:TRUE" -o "rpc.defragment_rpc_over_tcp:TRUE" -o "rpc.desegment_rpc_over_tcp:TRUE" |wc -l 186 where 186 is the number of NFS request and reply messages dissected. The relevant output from tshark is below: 314 38.993431 10.13.1.55 -> 10.13.0.10 NFS V3 WRITE Call, FH:0xe856e786 Offset:0 Len:32768 UNSTABLE 321 38.994455 10.13.1.55 -> 10.13.0.10 NFS V3 WRITE Call, FH:0xe856e786 Offset:32768 Len:18301 UNSTABLE 323 38.994894 10.13.0.10 -> 10.13.1.55 NFS V3 WRITE Reply (Call In 314) Len:32768 UNSTABLE 329 38.996895 10.13.0.10 -> 10.13.1.55 NFS V3 WRITE Reply (Call In 321) Len:18301 UNSTABLE 330 38.998748 10.13.1.55 -> 10.13.0.10 NFS V3 COMMIT Call, FH:0xe856e786 331 39.003018 10.13.0.10 -> 10.13.1.55 NFS V3 COMMIT Reply (Call In 330) Next I run the same command on a 4-way Itanium SMP machine, the command is: tutti:~/wireshark$ ./tshark -R nfs -r bigops2 -o "tcp.desegment_tcp_streams:TRUE" -o "rpc.defragment_rpc_over_tcp:TRUE" -o "rpc.desegment_rpc_over_tcp:TRUE"|wc -l 184 On this machine the output for the same trace is 184 NFS request and reply messages. The messages that are missing from the Itanium output are one NFS3 WRITE call and its response. The NFS write length is 18301 bytes. See the paste below for the relevant output on the Itanium: 298 38.989526 10.13.1.55 -> 10.13.0.10 NFS V3 WRITE Call, FH:0xe856e786 Offset:0 Len:32768 UNSTABLE[Unreassembled Packet [incorrect TCP checksum]] 323 38.994894 10.13.0.10 -> 10.13.1.55 NFS V3 WRITE Reply (Call In 298) Len:32768 UNSTABLE 330 38.998748 10.13.1.55 -> 10.13.0.10 NFS V3 COMMIT Call, FH:0xe856e786 331 39.003018 10.13.0.10 -> 10.13.1.55 NFS V3 COMMIT Reply (Call In 330) Note the missing corresponding NFS messages on the Itanium for request numbers 321 and 329 from the P4 output. The bigops2 file was captured with maximum snaplen so it has all the bytes in there. Is this difference a known behaviour? I can perform more tests for the developers if more info is needed to fix this because my own extensions(..under GPL..) to the NFS dissector require correct de-fragmentation and de-segmentation and this seems to have something to do with these two issues. The differences above cropped up while testing my extensions but persist even when I run the commands on fresh builds from both revision 21520 and latest 21916 check-outs. Thanks in advance Shehjar _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
