This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Implementing an stream dissector for an Packet-DataPackets-Response stream

0

Hi,

I'm implementing an LUA dissector for an protocol that is implemented with

  RequestPacket, {RequestDataPacket} * n, {ResponseDataPacket} * n , ResponsePacket.

Requests / Responses might be interleaved with different Transaction-IDs.

To dissect the Response correctly I need to access the matching Request type.

How can I pass on the request types?

asked 15 May '16, 03:51

Thomas%20E's gravatar image

Thomas E
36459
accept rate: 0%

edited 15 May '16, 03:52


One Answer:

0

You'll have to use a global (i.e. not local to the dissection function) table holding the translations of the transaction ID (possibly combined with some additional information if the transaction IDs may roll over in a short time) to the associated request type. When dissecting requests, your dissection function would fill this table; when dissecting responses, it would use it to fetch the request type for the known transaction id. You would declare the table in the part of your Lua script where you create the protocol fields (i.e. before describing the dissector function itself).

The name of such table should begin with the name of the protocol (like MyProto_Request_Type_by_TxnID) merely to avoid conflicts in the common namespace shared by all Lua scripts.

Unfortunately, you cannot save space (which would be desirable) by dropping each item from the table as soon as it has been used once, because after the initial first-to-last dissection pass, a dissector for any packet may be invoked multiple times and in random order.

And the part of your dissecting function dealing with responses has to handle gracefully the situation when no request matching the response has been captured (due to mid-transaction start of capture, packet loss, ...).

answered 15 May '16, 04:30

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 15 May '16, 05:26

The number of streams is kind of limited compared to todays computing resources, so the approach worked fine. Used in https://github.com/tengelmeier/mtp-tools/.

(30 May '16, 07:53) Thomas E