This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to Dissector with Timing Constraint

0

I have created a c++ dissector plugin that parses my protocol just fine.

My protocol has timing constraints between messages. What is the best way to implement tracking/reporting of time between messages.

Is this something that I can handle with of conversations (no experience with) or do I create my own wmem structure and track inside of the dissector? Should I create a post dissector tap (no experience with them)?

How would I indicate that the last message did not have a follow on message to satisfy the constraint.

Thanks for the help.

asked 25 Jan '17, 08:27

Rob%20B's gravatar image

Rob B
368813
accept rate: 0%


One Answer:

0

You should go and read doc/README.request_response_tracking where it is explained how to do this.

answered 25 Jan '17, 10:31

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

How would I set an expert field in the request stating that no response was seen?

(25 Jan '17, 13:58) Rob B
1

In the first pass of dissecting packets, this is obviously impossible, as, when the request was seen, Wireshark/TShark haven't yet read any packets that would be a response.

In subsequent passes, if you have a data structure to keep track of requests and replies, you can detect whether a response was seen, and add an expert info.

This means that, in TShark without the -2 flag, this will be impossible. It should work in most cases for Wireshark.

To determine whether you're in the first pass or not, check whether pinfo->fd->flags.visited is true or false. If it's false, you're doing the first pass, otherwise you're doing a subsequent pass.

(25 Jan '17, 14:44) Guy Harris ♦♦

Guy Harris, Thanks for the help.

Does Wireshark always do two passes?

(03 Feb '17, 08:22) Rob B

Wireshark is not guaranteed to make more than one complete pass over the packet data unless you run some statistical tap that has to scan all the packet or you run a display filter on the packet list; that first pass happens when you read the file in. If you select a packet, it will re-dissect the packet in order to generate the protocol tree for display, so at that point, the protocol tree can indicate a request without a response.

(03 Feb '17, 09:30) Guy Harris ♦♦