Wireshark mailing list archives

Re: Add plugin timing statistics


From: <jayrturner99 () gmail com>
Date: Wed, 9 Sep 2020 10:54:43 -0500

I was able to add statistics for some simple request/response timing.

 

Using (!PINFO_FD_VISITED(pinfo)) I checked my packets on the first pass, in order. Since I have a Request/Response 
format, as I saw my Request frame, I stored it in my conversation proto data. When the Response came, I read the 
Request frame stored and associated the two with transaction data – written in a wmem_tree I also stored in the 
conversation proto data. My transactions have no unique identifier – so I used the frame number. Dissecting the 
Response, I could lookup the Request transaction and fill it in with the Response frame, and fill in the Response’s 
Request frame too. And I handle when they can’t find a partner. The proto_tree_add_uint referring to an FT_FRAMENUM; 
FRAMENUM_TYPE(FT_FRAMENUM_REQUEST/RESPONSE) links everything with hyperlinks and arrows with virtually no effort.

 

I can’t find information in tcpinfo pointing to the ACK packet, but I’ll make another thread with that question.

 

Thank you,

Jay Turner

 

From: Wireshark-dev <wireshark-dev-bounces () wireshark org> On Behalf Of Dario Lombardo
Sent: Monday, August 31, 2020 10:30 AM
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Subject: Re: [Wireshark-dev] Add plugin timing statistics

 

You could start by reading stats_tree documentation that tells you how handle statistic using the stats_tree subsystem 
(based on tap, but more evolved), by reading packet_info structure that stores info about lower layer protocols, and by 
reading the DNS dissector (above others), that creates stats that sound like the ones you need.

 

On Mon, Aug 31, 2020 at 5:21 PM <jayrturner99 () gmail com <mailto:jayrturner99 () gmail com> > wrote:

I would like advice on adding timing statistics to a Wireshark plugin. I have implemented a plugin for my company’s 
proprietary protocol, which sits on top of TCP/IP. I have added tap statistics to count various interesting pieces of 
data. I would now like to calculate the time it takes for the server to process commands.

 

Looking at a general flow in my protocol, a command is sent (PSH, ACK) and an ACK occurs. Then later a (PSH, ACK) and 
an ACK occur for the response.

If I take the response (PSH, ACK) timestamp and subtract the command ACK timestamp, I think this would be the best “how 
long did the server take to process” time.

Do you have an idea of any better timing data I should consider?

 

With a dissector, I can look at my protocol. How would I look at my packet’s TCP/IP protocol and get the timestamp?

 

Then I would need to associate my command’s timestamp with a response timestamp. How might I do this? Using a tap? If 
so, how might I do this? I know that my activity flow is - command (PSH, ACK), command ACK, response (PSH, ACK), 
response ACK - so I know that if I’m in a command packet that the response timestamp I need is two packets ahead, 
sequentially, in its conversation. Are there calls to peek ahead?

 

So, if you have suggestions on places within the documentation or code that I can study, please let me know.

 

Thank you,

Jay Turner

 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org <mailto:wireshark-dev () wireshark org> >
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org <mailto:wireshark-dev-request () wireshark org> 
?subject=unsubscribe




 

-- 

Naima is online.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: