Wireshark-dev: Re: [Wireshark-dev] pinfo->fd->flags.visited for wireshark c dissector
On 06-01-16 19:12, Jeff Morriss wrote:
>
>
> On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx
> <mailto:pascal.quantin@xxxxxxxxx>> wrote:
>
>
>
> 2016-01-06 8:30 GMT+01:00 Ran Bao <worksev@xxxxxxxxx
> <mailto: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
>
Indeed, see here:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=doc/README.dissector#l3436
Thanks,
Jaap
