Re: Hi. Regarding packet re-assembly

[Anders Broman <anders.broman () ericsson com>]

Hi,
Try to put

"if (pinfo->fd->flags.visited)"

around the reassembly code.

Regards

Anders

________________________________
From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Ari Yoskovitz
Sent: den 30 mars 2010 22:34
To: wireshark-dev () wireshark org
Subject: [Wireshark-dev] Hi. Regarding packet re-assembly

Hi!

I am new to Wireshark dissector development, and encountered the following problem:

I am sending packtes, and the packets are fragmented.
At first, I wasn't aware of the API's internal packet re-assembly capabilities, so I tried to use a global buffer to 
accumulate the packets' payloads. At the last packet, I dissected the buffer (now containing an Ethernet packet) and 
added the result to the tree.

I did this just to find out the Wireshark not only calls the dissector when first encountering a packet, but also when 
I click it later... I didn't know that...
This is a problem since using an accumulating buffer relies on the packets being dissected in order. However, if I now 
click the in an un-ordered manner, the buffer accumulates stuff wrongly. Moreover, If I don't click ALL packets 
involved in a transaction, I only get part of the data.

So, I discovered the fragment_add_seq() <http://src.opensolaris.org/source/s?defs=fragment_add_seq_key&project=/sfw> 
function and all that around it, but I still have the same problem:
My packets have *No seq number or frag number* !!
Hence, I cannot use such numbers as hash-table keys. I can only rely on transactions and fragments coming in ordered, 
but that's it.
Now, I want the fragments being added to the hash only when Wireshark first encounters a packet, but not again when I 
click it later. Using a simple global counter to produce keys will cause the same problem as before: When I later come 
back to observe packets a click them, they will be re-dissected, and now that the counter has a different value than 
before (it has advanced...), there will be no connection between a packet and the key produced for it in the first 
encounter.

I can think of all kinds of nasty tricks to solve this, but somehow I am sure there is an Wireshark provides an elegant 
way to achieve this.

Thanks!
--
Use the source, Luke!

___________________________________________________________________________
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