Wireshark-bugs: [Wireshark-bugs] [Bug 8178] Multiple requests or responses in a single frame ca
Date: Wed, 09 Jan 2013 16:47:14 +0000
Comment # 6
on bug 8178
from Cal Turney
(In reply to comment #5) > Note also that an _expression_ of COUNT(smb2.cmd) and a filter of "smb2.cmd == > X && smb2.file_info.infolevel", where X is a command that has a file_info > structure containing an infolevel subfield, would, I think, end up counting > *all* the SMB2 commands in a packet in which *at least one* command had a > file_info structure containing an infolevel subfield. This may not be what > is intended. Yes. In the vast majority of cases this is not what the user intended. As many responses get queued up on a NAS server, they will typically gegin to transmit multiple responses in a framen. The same happens with clients such as webservers when they become overwhelemed with requests. Over the course of the capture period the clients or server may transmit varying numbers of requests/responses. The mere fact that some frames have multiple requests should in no way alter the statistical results. If Wireshark's SRT dialog reports that ther are 100 Writes with an average SRT of 2.3ms, io,stat and IO Graph should report the same number. In the NFSv3 example I mentioned, a single frame had 1 LOOKUP, 1 READ, and 4 GETATTR responses but when I filtered for the number of LOOKUPs the tools reported that there were 6 LOOKUPs but it gets worse. Consider this output: tshark -n -q -r multiple-resp-frame-635.cap -z io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==1 and frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==1 and frame.number==635" -z io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==3 and frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==3 and frame.number==635" -z io,stat,0,"COUNT(nfs.procedure_v3)nfs.procedure_v3==6 and frame.number==635","SUM(rpc.time)rpc.time and nfs.procedure_v3==6 and frame.number==635" -z "rpc,srt,100003,3,frame.number==635" ======================================================= NFS Version 3 SRT Statistics: Filter: frame.number==635 Procedure Calls Min SRT Max SRT Avg SRT GETATTR 4 0.113281 0.113281 0.113281 LOOKUP 1 0.113281 0.113281 0.113281 READ 1 0.113281 0.113281 0.113281 ======================================================= ============================================================================== | IO Statistics | | | | Interval size: 0.227 secs (dur) | | Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==6 and frame.number==635 | | 2: SUM(rpc.time)rpc.time and nfs.procedure_v3==6 and frame.number==635 | |----------------------------------------------------------------------------| | |1 |2 | | | Interval | COUNT | SUM | | |-----------------------------------| | | 0.000 <> 0.227 | 6 | 0.679686 | | ============================================================================== ============================================================================== | IO Statistics | | | | Interval size: 0.227 secs (dur) | | Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==3 and frame.number==635 | | 2: SUM(rpc.time)rpc.time and nfs.procedure_v3==3 and frame.number==635 | |----------------------------------------------------------------------------| | |1 |2 | | | Interval | COUNT | SUM | | |-----------------------------------| | | 0.000 <> 0.227 | 6 | 0.679686 | | ============================================================================== ============================================================================== | IO Statistics | | | | Interval size: 0.227 secs (dur) | | Col 1: COUNT(nfs.procedure_v3)nfs.procedure_v3==1 and frame.number==635 | | 2: SUM(rpc.time)rpc.time and nfs.procedure_v3==1 and frame.number==635 | |----------------------------------------------------------------------------| | |1 |2 | | | Interval | COUNT | SUM | | |-----------------------------------| | | 0.000 <> 0.227 | 6 | 0.679686 | | ============================================================================== As can be seen, io,stat reports that frame 635 has 6 GETATTRs, 6 LOOKUPs, and 6 READs and all three are responsible for 680ms of latency for a total of 2.039 *seconds* of latency. It doesn't take too many of these multi-response frame to completely ruin an analysis of latency in performance investigations. Rather than requiring the user to have to remember to specify filters in the form "same_subtree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel)", symantics should be added to for requesting these tools to filter in a way that treats a frame as one request or response tree. For example: aggregated_tree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel) or full_tree(smb2, smb2.cmd == 5 && smb2.file_info.infolevel) or frame(smb2, smb2.cmd == 5 && smb2.file_info.infolevel) In this way if frame one is a bear and frame 2 is a chicken and frame 3 has a bear and chicken, if one filters for a bear with wings, COUNT(bear && wings), the result would be a count of one. I have attached capture 'multiple-resp-frame-635.cap' that was used in the above example.
You are receiving this mail because:
- You are watching all bug changes.
- References:
- Prev by Date: [Wireshark-bugs] [Bug 8187] New: Buildbot crash output: fuzz-2013-01-08-28832.pcap
- Next by Date: [Wireshark-bugs] [Bug 8178] Multiple requests or responses in a single frame causes inaccuracy in tshark’s ‘-z io?=,=?UTF-8?Q?stat’ and Wireshark’s IO Graph statistics.
- Previous by thread: [Wireshark-bugs] [Bug 8178] Multiple requests or responses in a single frame causes inaccuracy in tshark’s ‘-z io?=,=?UTF-8?Q?stat’ and Wireshark’s IO Graph statistics.
- Next by thread: [Wireshark-bugs] [Bug 8178] Multiple requests or responses in a single frame causes inaccuracy in tshark’s ‘-z io?=,=?UTF-8?Q?stat’ and Wireshark’s IO Graph statistics.
- Index(es):