[philippe alarcon <philippe.alarcon@xxxxxxx>]

Hello,

I suggest you to keep your listener.

As far as I know, the listener is called when the file is loaded.
And the dissector is called for each selected packet.

Then I think you need both functionalities :
- a listener in order to analyse and memorise all the informations about the different packets,
- a dissector in order to analyse the current packet,
and verify if the packet has been acknowledged or not,
or any related information.

Regards
Philippe

---

Date: Wed, 16 Sep 2009 08:59:46 -0400
From: beth.tridium@xxxxxxxxx
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] Accessing prior packets in Lua

I suddenly got a glimmer of a clue...

I should mention I am a rank Lua beginner, having never heard of it before last Friday.  My Lua script began as an exact copy of the "Address Counter" listener code in section 10.3 of the Wireshark User's Guide.  Obviously it has changed significantly in content since then, but the basic structure is the same, i.e. it is a listener, not a dissector.

I hadn't picked up on that terminology difference before (I was too busy trying to learn the language grammar and the Wireshark API).  I bet my script needs to be a dissector, not a listener. 

BTW since Martin asked, I've attached my current script.  You don't need to look at it unless you're interested.  I'm off to explore Lua dissectors now.

Thanks,
b.

On Wed, Sep 16, 2009 at 8:37 AM, Beth <beth.tridium@xxxxxxxxx> wrote:

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

---

Un avatar à votre image ? Créez votre mini-moi !