ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] pinfo->fd->flags.visited for wireshark c dissector

From: Ran Bao <worksev@xxxxxxxxx>
Date: Thu, 7 Jan 2016 09:09:41 +1300
Thanks all. The problem is now identified with the help from Jaap and Jeff. The "tree" is a real problem while I didn't handle the tree with NULL value passed to the lower layer dissector. 

Thanks you for your kind help.



Regards

Ran
_____________________________
Ran Bao
College of Engineering
University of Canterbury


On Thu, Jan 7, 2016 at 9:00 AM, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
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

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