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

[Anders Broman <anders.broman@xxxxxxxxxxxx>]

Hi,

Wiresharks reassembly more or less will have to work in a similar way as an application using the protocol would.

The first pass over the packets is sequential in order so assuming the underlying transport protocol guarantees

in order delivery of the packets you would not have to worry about that. A trace starting in the middle of a segmented transfer

may miss segments which would have to be catered for.

If the segmentation can maximum be three segments that would implicitly give seq no 1 2 and 3.

But if it could be START MIDDLE .. MIDDLE END it's more trouble some. I think there is a reassembly function

which cater for un numbered in order fragments ( check the code).

Regards

Anders

---

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Ari Yoskovitz
Sent: den 30 mars 2010 23:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Hi. Regarding packet re-assembly

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!