Wireshark-dev: Re: [Wireshark-dev] Hi. regarding 'visited' bit
Hi,
It seems that you expect the dissection of your packets to take place in a linear fashion: don't !
Packet dissection is a random access process, and that is what you'll need to code for (and the reassembly functions struggle with to get right). Even your packets can arrive out of order, then reloading your file won't help either I expect.
Also make sure your reassembly takes place even if (tree == NULL), which is another common pitfall.
Thanks,
Jaap
On Thu, 20 May 2010 13:14:37 +0300, Ari Yoskovitz <ariyosko@xxxxxxxxx> wrote:
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?
Thanks.
On Sun, May 16, 2010 at 7:16 PM, Jaap Keuter
<jaap.keuter@xxxxxxxxx> 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
--
Use the source, Luke!
