Re: Hi. Regarding packet re-assembly

[Ari Yoskovitz <ariyosko () gmail com>]

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



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