[Beth <beth.tridium@xxxxxxxxx>]

Thank you both for your input.  My Lua script already creates a data structure for each packet, and when it sees an ack it does the calculation you describe.  And I can add the results to the protocol tree for the ack, since that's the one I'm processing when I do the calculations.  

But in my capture files, the ack *always* comes after the message that it acks.  So I don't quite understand what you mean by looking for the ack packet's information in my database when I am processing the acked message.  How could it already be there if I haven't had a chance to process it yet?

Unless there is some way to control the order in which my Lua script processes the packets?  I have been assuming it always goes from packet # 1 to N.

Thanks again,
b.

On Tue, Sep 15, 2009 at 11:00 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Sep 14, 2009, at 12:50 PM, Beth wrote:

> In my Lua program, I am analyzing how long it takes certain packets
> to be acked.  I can calculate the information once I get the ack
> packet, but what I would really like to do is to add the "time to
> ack" (or "never acked") data to the tree for the original packet.  I
> know this can be done in C, since the Wireshark fragment reassembly
> does it very nicely, but can it also be done from Lua?
>
> That is: given packet number X that is later acked by packet number
> Y, when my Lua program processes packet Y I can calculate the time
> between the packets.  I can print it in a textwindow, but I would
> much rather add this info to the display tree for packet X.  How
> might I access the tree for packet X, when I am processing packet Y?

You can't - it doesn't exist.  Protocol trees are discarded as soon as
Wireshark or TShark is finished with them, so they don't take up memory.

What you would need to do would be to have, as per Martin Visser's
suggestion, a data structure that stores, for each packet that would
be acked:

       the time stamp of the packet;

       the frame number of the packet;

       the time stamp of the ack for that packet (initialize to 0);

       the frame number of the frame containing the ack for that packet
(initialize to 0);

       whatever information would be needed in order to identify which frame
acks the packet;

and, when you see an ack, look in that data structure for the packet
to which it's an ack, and fill in the time stamp and the frame number
of the ack (if it's not already filled in - no frame has frame number
0, so if the frame number of the ack is non-zero, it's already been
filled in).

When dissecting a packet that could be acked, see whether there's an
entry in the database for it.

       If not:

               if the packet hasn't yet been seen, create one.

       If so:

               if the frame number containing the ack for the packet is non-zero,
compute the "time to ack" from the two time stamps, and put that and
the frame number of the ack into the protocol tree;

               otherwise, put a "never acked" indication into the protocol tree.

When dissecting an ack, see whether there's an entry in the database
for it:

       If so, and if the frame number for the packet being acked is non-
zero, you could put the "time to ack" and the frame number of the
packet being acked into the protocol tree.

___________________________________________________________________________
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