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!