Wireshark-dev: Re: [Wireshark-dev] pinfo->fd->flags.visited for wireshark c dissector
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Wed, 6 Jan 2016 13:12:58 -0500


On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:


2016-01-06 8:30 GMT+01:00 Ran Bao <worksev@xxxxxxxxx>:

Hi

I am currently implementing a dissector plugin for a DMR conventional and trunked protocols. Three layers of protocols were involved. Messages was send to a specific UDP port on server.

 

UDP port -> Company specified protocol -> DMR Layer 2 Protocols -> DMR Layer 3 Protocols.

 

Raw messages are processed or reassembled and delivered to higher layer sub dissectors for further analysis. Some DMRL2 PDUs are required to be reassembled into a large message. Due to the limitation of DMRL2 PDUs, many message bursts do not contain fragmentation number or stop bit. The DMRL2 dissector heavily relies on the receiving order of fragments. I used fragment_add_seq_next() function to add each fragments into hash tables.

 

However, I noticed that the value of pinfo->fd->flags.visited was initialized with 0, so that each fragments are only added once, when opening *.pcapng file with filter applied. If there is no filter specified before opening *.pcapng file, either using Open or Open from recent,  the pinfo->fd->flags.visited for each PDUs were set to 1 initially. Hence no fragment was reassembled.

 

It turned out that the user have to provide some filter before capturing or reading from file in order to assemble these PDUs. Is that the feature that Wireshark was designed? Is there any method to reset visited flag for each PDUs?


Hi Ran,

what you report is very surprising. pinfo->fd->flags.visited is set to 0 the very first time a packet is read (first pass), whether a display filter is set or not. Then all subsequent decoding of the packet has the flag set.
This can be double checked by putting a breakpoint in dissect_frame function() for example.
Are you sure you do not have some code preventing your dissector from being called on first pass?

Usually this kind of problem is caused by some lower layer protocol (in this case maybe "Company specified protocol"?) isn't calling subdissectors when the tree is NULL.  I fixed an example of this relatively recently:

https://code.wireshark.org/review/11226