Wireshark-dev: Re: [Wireshark-dev] Hi. Regarding packet re-assembly

From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Tue, 30 Mar 2010 22:50:59 +0200
Hi,
Try to put

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

around the reassembly code.

Regards

Anders


From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Ari Yoskovitz
Sent: den 30 mars 2010 22:34
To: wireshark-dev@xxxxxxxxxxxxx
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() 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!