Re: Hi. regarding 'visited' bit

[Jaap Keuter <jaap.keuter () xs4all nl>]

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  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  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 
 Archives:
http://www.wireshark.org/lists/wireshark-dev [3]
 Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev [4]

mailto:wireshark-dev-request () wireshark org [5]?subject=unsubscribe    

--

Use the source, Luke!  

 

Links:
------
[1]
mailto:jaap.keuter () xs4all nl
[2] mailto:wireshark-dev () wireshark org
[3]
http://www.wireshark.org/lists/wireshark-dev
[4]
https://wireshark.org/mailman/options/wireshark-dev
[5]
mailto:wireshark-dev-request () wireshark org

___________________________________________________________________________
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