[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-dev
Subject: Re: [Wireshark-dev] pinfo->fd->flags.visited for wireshark c dissector
From: Ran Bao <worksev () gmail ! com>
Date: 2016-01-06 20:09:41
Message-ID: CANOKkbpnefVg2EAaRzubU-DPPWb7Kd++vbpy7EFaO=TaXDC59A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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*
rba90@uclive.ac.nz
On Thu, Jan 7, 2016 at 9:00 AM, Jaap Keuter <jaap.keuter@xs4all.nl> wrote:
> 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
>
[Attachment #5 (text/html)]
<div dir="ltr">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. <div><br></div><div>Thanks you for \
your kind help.</div></div><div class="gmail_extra"><br clear="all"><div><div \
class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div \
dir="ltr"><br><div><div \
style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;word-wrap:break-word"><div \
style="word-wrap:break-word"><div style="word-wrap:break-word"><div \
style="word-wrap:break-word"><div style="word-wrap:break-word"><div \
style="word-wrap:break-word"><div style="word-wrap:break-word"><div \
style="margin:0px"><div style="margin:0px"><div style="margin:0px">Regards</div><div \
style="margin:0px;min-height:14px"><br></div><div style="margin:0px">Ran</div><div \
style="margin:0px;font-size:15px;font-family:Calibri"><b>_____________________________</b></div><div \
style="margin:0px;font-size:15px"><b><i>Ran Bao</i></b></div><div \
style="margin:0px"><b>College of Engineering</b></div><div \
style="margin:0px"><b>University of Canterbury</b></div><div \
style="margin:0px;color:rgb(71,135,255)"><span style="text-decoration:underline"><a \
href="mailto:rba90@uclive.ac.nz" \
target="_blank">rba90@uclive.ac.nz</a></span></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Jan 7, 2016 at 9:00 AM, Jaap Keuter <span \
dir="ltr"><<a href="mailto:jaap.keuter@xs4all.nl" \
target="_blank">jaap.keuter@xs4all.nl</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On 06-01-16 19:12, Jeff Morriss wrote:<br> ><br>
><br>
> On Wed, Jan 6, 2016 at 12:48 PM, Pascal Quantin <<a \
href="mailto:pascal.quantin@gmail.com">pascal.quantin@gmail.com</a><br> > \
<mailto:<a href="mailto:pascal.quantin@gmail.com">pascal.quantin@gmail.com</a>>> \
wrote:<br> ><br>
><br>
><br>
> 2016-01-06 8:30 GMT+01:00 Ran Bao <<a \
href="mailto:worksev@gmail.com">worksev@gmail.com</a><br> > <mailto:<a \
href="mailto:worksev@gmail.com">worksev@gmail.com</a>>>:<br> ><br>
> Hi ____<br>
><br>
> I am currently implementing a dissector plugin for a DMR \
conventional<br> > and trunked protocols. Three layers of protocols \
were involved. Messages<br> > was send to a specific UDP port on \
server. ____<br> ><br>
> __ __<br>
><br>
> UDP port -> Company specified protocol -> DMR Layer 2 \
Protocols -> DMR<br> > Layer 3 Protocols.____<br>
><br>
> __ __<br>
><br>
> Raw messages are processed or reassembled and delivered to higher \
layer<br> > sub dissectors for further analysis. Some DMRL2 PDUs are \
required to be<br> > reassembled into a large message. Due to the \
limitation of DMRL2 PDUs,<br> > many message bursts do not contain \
fragmentation number or stop bit. The<br> > DMRL2 dissector heavily \
relies on the receiving order of fragments. I<br> > used \
fragment_add_seq_next() function to add each fragments into hash<br> > \
tables. ____<br> ><br>
> __ __<br>
><br>
> However, I noticed that the value of pinfo->fd->flags.visited \
was<br> > initialized with 0, so that each fragments are only added \
once, when<br> > opening *.pcapng file with filter applied. If there \
is no filter<br> > specified before opening *.pcapng file, either \
using Open or Open from<br> > recent, the \
pinfo->fd->flags.visited for each PDUs were set to 1<br> > \
initially. Hence no fragment was reassembled. ____<br> ><br>
> __ __<br>
><br>
> It turned out that the user have to provide some filter before \
capturing<br> > or reading from file in order to assemble these PDUs. \
Is that the<br> > feature that Wireshark was designed? Is there any \
method to reset<br> > visited flag for each PDUs?<br>
><br>
><br>
> Hi Ran,<br>
><br>
> what you report is very surprising. pinfo->fd->flags.visited is set \
to 0 the<br> > very first time a packet is read (first pass), whether a \
display filter is<br> > set or not. Then all subsequent decoding of the \
packet has the flag set.<br> > This can be double checked by putting a \
breakpoint in dissect_frame<br> > function() for example.<br>
> Are you sure you do not have some code preventing your dissector from \
being<br> > called on first pass?<br>
><br>
><br>
> Usually this kind of problem is caused by some lower layer protocol (in this<br>
> case maybe "Company specified protocol"?) isn't calling \
subdissectors when the<br> > tree is NULL. I fixed an example of this relatively \
recently:<br> ><br>
> <a href="https://code.wireshark.org/review/11226" rel="noreferrer" \
target="_blank">https://code.wireshark.org/review/11226</a><br> ><br>
<br>
Indeed, see here:<br>
<a href="https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=doc/README.dissector#l3436" \
rel="noreferrer" target="_blank">https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=doc/README.dissector#l3436</a><br>
<br>
Thanks,<br>
Jaap<br>
<br>
___________________________________________________________________________<br>
Sent via: Wireshark-dev mailing list <<a \
href="mailto:wireshark-dev@wireshark.org">wireshark-dev@wireshark.org</a>><br>
Archives: <a href="https://www.wireshark.org/lists/wireshark-dev" \
rel="noreferrer" target="_blank">https://www.wireshark.org/lists/wireshark-dev</a><br>
Unsubscribe: <a href="https://wireshark.org/mailman/options/wireshark-dev" \
rel="noreferrer" target="_blank">https://wireshark.org/mailman/options/wireshark-dev</a><br>
mailto:<a \
href="mailto:wireshark-dev-request@wireshark.org">wireshark-dev-request@wireshark.org</a>?subject=unsubscribe<br>
</blockquote></div><br></div>
___________________________________________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic