[<jayrturner99@xxxxxxxxx>]

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@xxxxxxxxxxxxx> On Behalf Of Dario Lombardo
Sent: Monday, August 31, 2020 10:30 AM
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

 

--

Naima is online.