Wireshark mailing list archives
Re: pinfo->fd->flags.visited for wireshark c dissector
From: Jaap Keuter <jaap.keuter () xs4all nl>
Date: Wed, 6 Jan 2016 21:00:19 +0100
On 06-01-16 19:12, Jeff Morriss wrote:
On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin <pascal.quantin () gmail com <mailto:pascal.quantin () gmail com>> wrote: 2016-01-06 8:30 GMT+01:00 Ran Bao <worksev () gmail com <mailto:worksev () gmail com>>: 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 () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- pinfo->fd->flags.visited for wireshark c dissector Ran Bao (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Pascal Quantin (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Jeff Morriss (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Jaap Keuter (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Ran Bao (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Jeff Morriss (Jan 06)
- Re: pinfo->fd->flags.visited for wireshark c dissector Pascal Quantin (Jan 06)