Re: Hi. Regarding packet re-assembly

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

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 () wireshark org [mailto:wireshark-dev-bounces () wireshark org] 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 () ericsson com<mailto:anders.broman () ericsson com>> 
wrote:
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> 
[mailto: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<mailto: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<mailto: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<mailto:wireshark-dev-request () wireshark 
org>?subject=unsubscribe



--
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