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* [email protected] On Thu, Jan 7, 2016 at 9:00 AM, Jaap Keuter <[email protected]> wrote: > On 06-01-16 19:12, Jeff Morriss wrote: > > > > > > On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin < > [email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > 2016-01-06 8:30 GMT+01:00 Ran Bao <[email protected] > > <mailto:[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 > > > > 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ 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
