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
