On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin <[email protected]> wrote:
> > > 2016-01-06 8:30 GMT+01:00 Ran Bao <[email protected]>: > >> 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
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
