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