Re: Volatile Read of Wireshark Frames

[Anders Broman <anders.broman () ericsson com>]

From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of FIXED-TERM 
Scholz Tobias (DC-IA/EAM6)
Sent: den 18 februari 2015 10:47
To: wireshark-dev () wireshark org
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

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