Re: Hi. regarding 'visited' bit

["Mike Morrin" <Mike.Morrin () ipaccess com>]

________________________________

From: wireshark-dev-bounces () wireshark org
[mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Ari Yoskovitz
Sent: 20 May 2010 11:15
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Hi. regarding 'visited' bit

 

Hi. Thanks for your reply.

I removed my assignment to this bit, but now things act funny.
For example, i am using the re-assembling mechanism, including the hash
table.
I added DISSECTOR_ASSERTS for cases when the 'get' operation return a
NULL. This should never happen because I am inserting to the hash on the
first pass, using the 'visited' bit, and extracting from it on other
passes (visited != 0).
However, sometimes, not always, those asserts fails. If that's not odd
enough, saving to a file and re-loading it make the problems go away.

Maybe I don't really understand how the 'visited' bit works, or do I?

Take a look at this comment from reassemble.c and see if any of the
issues apply to your protocol:

 /*         * "already_added" is true if "pinfo->fd->flags.visited" is
true;

             * if "pinfo->fd->flags.visited", this isn't the first pass,
so

             * we've already done all the reassembly and added all the

             * fragments.

             *

             * If it's not true, but "check_already_added" is true, just
check

             * if we have seen this fragment before, i.e., if we have
already

             * added it to reassembly.

             * That can be true even if "pinfo->fd->flags.visited" is
false

             * since we sometimes might call a subdissector multiple
times.

             * As an additional check, just make sure we have not
already added 

             * this frame to the reassembly list, if there is a
reassembly list;

             * note that the first item in the reassembly list is not a

             * fragment, it's a data structure for the reassembled
packet.

             * We don't check it because its "frame" member isn't
initialized

             * to anything, and because it doesn't count in any case.

             *

I think that flags.visited is a rather blunt tool for this sort of
thing, maybe there is a better way...

Mike

Thanks.

On Sun, May 16, 2010 at 7:16 PM, Jaap Keuter <jaap.keuter () xs4all nl>
wrote:

On 05/16/2010 03:36 PM, Ari Yoskovitz wrote:
> Hi.
>
> I am using the pinfo->fd->flags.visited bit in my dissector.
> I have discovered (after a lot of debugging...) the sometimes this bit
> is asserted even on the first run, namely when the packet was not
visited...
> It happens very rarely, but when it does the results are destructive.
>
> Am I missing anything? Is this a bug?

This should never happen. If this is true, that's a bug.
Now the question is, can you define the circumstances when this happens?


> Thanks.
>
> BTW It looks to me that this bit has to be manually set to 1 when the
> packet is being visited for the first time. Again, am I wrong here?
Thanks.
>

This is *incorrect*
The EPAN dissection engine handles setting of this bit after the frame
was
handed off to the frame dissector. See dissect_packet() in
epan/packet.c. You're
supposed to treat this as a readonly value. Maybe this is the cause for
the bug
you see?

Thanks,
Jaap

________________________________________________________________________
___
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe




-- 
Use the source, Luke!






This message contains confidential information and may be privileged. If you are not the intended recipient, please 
notify the sender and delete the message immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe