Wireshark-dev: Re: [Wireshark-dev] Volatile Read of Wireshark Frames
From: Anders Broman <[email protected]>
Date: Wed, 18 Feb 2015 10:05:02 +0000

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of FIXED-TERM Scholz Tobias (DC-IA/EAM6)
Sent: den 18 februari 2015 10:47
To: [email protected]
Subject: [Wireshark-dev] Volatile Read of Wireshark Frames

 

Hi,

 

at the moment I am improving an existing Wireshark dissector. For my improvement it is really necessary, that Wireshark processes the incoming frames in a row. This will be done perfectly, if I am starting a new capture.

 

But for the case, that I am stopping my current capture and starting it at a later point new without rebooting Wireshark, the frames are processed in a  arbitrary order. I can check this conduct, with an easy output message to the Debug Console:

printf(“ Frame %u\n “, pinfo->fd->num);

(As far as I know, “pinfo->fd->num” returns the frame number of the current processed frame.)

With this function, I was able to see, that Wireshark jumps between the incoming frames during a running capture. For Example one conduct:

 

Frame 1 -230 processed in a row à  Jump to Frame 1 again à  Frame 1 -26 processed in a row à Jump to Frame 64 à Jump to Frame 1 again à Jump to Frame 205 à next frames have been processed in a row…

I even didn’t click on any frame. I just started and stopped the capture again.

 

Therefore I wanted to ask, whether this behavior is known and a solution exists, or whether I can force Wireshark to strict process a special Frame with number “XYZ”? It would be nice, if someone could explain me this conduct of Wireshark, after starting the capture new without closing the program, so that maybe I am able to deal with that conduct on my own.

 

If it helps to improve comprehension of my problem, I can create a screenshot and share it.

 

Thanks in advance.

 

In general Wireshark reads all packets in sequential order on the first pass only, after that packets will be read as needed eg if you scroll or jump to a packet the now visible packets will be “redissected”

The dissection result is not kept in memory so re dissection is needed.

 

pinfo->fd->flags.visited is sued in dissectors to only do some stuff on the first sequential pass and then arrangements has to be made if the result needs to be “remembered”

Hope this helps.

 

Regards

Anders