Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

From: Ari Yoskovitz <ariyosko@xxxxxxxxx>
Date: Tue, 30 Mar 2010 23:07:53 +0200
Hi, and thanks for the quick response!     :-)
I will look into it, but now that I think of it, the question is actually deeper:
Since I have no seq numbers on the packets, the only way for me to accumulate the payload properly is by running over related packets in order (I only have 'START', MIDDLE', 'END' markers on the packets).
This means that when I come back later to look at the dissected packets, I should have the old data from the first pass presented to me, and not to re-look at the tvb_buff. I somehow have to "save" my dissection results at the first pass, and re-show them when I click a packet later. Any re-evaluation, without having seq numbers to refer to as hash keys, should probably fail, since I don't even know what to take out from the hash.

Is there a way to do that?

Thanks again!

On Tue, Mar 30, 2010 at 10:50 PM, Anders Broman <anders.broman@xxxxxxxxxxxx> wrote:
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!

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe



--
Use the source, Luke!