Inter-Frame references using Conversations and Request/Response

Hello Devs,

Thanks for your continued efforts on this valuable tool!

Background: We're building a dissector for DeviceNet which significantly extends the stock dissector shipped with Wireshark. (if there is interest, we're happy to share our work) This dissector performs frame reassembly of CAN frames into Group 2 DeviceNet frames as a path to allowing us to understand the "language/protocol" of a connected device. We are successfully interpreting the DeviceNet level interactions now. The "wire protocol" is being successfully and fully interpreted. (We even figured out how to add hints to reference applicable sections of the OVDA spec!)

Objective: Now that we can build DeviceNet frames which the target device is interpreting, we are hoping to add some additional commentary in the INFO column.

In order to do this, we need to "simulate" knowing some state of the target device. We would like to add "interpretation" of responses to queries to the device. Our thinking is that if we can look retrospectively into the packet stream to a frame which immediately precedes our response data to see which "command" was issues, we can take a stab at interpreting the response.

It's well understood that this is not foolproof, but for our purposes the items we put into the INFO column are really meant to be hints, not a rigorous "decode".

With that background, our question is if (programmatically) there a way to walk through past frames to find our query? We've written the dissector in C, so are looking for how we might use the tools in that environment to achieve this.

For context, here is a snippet of a trace:

No. Protocol    IsFrag   Frag Type   Req/Resp      Device            Info
Data
1   DeviceNet    False               Request        RMS              Read current Flow State
2   DeviceNet    True      Start
3   DeviceNet    True      ACK
4   DeviceNet    True      Mid
5   DeviceNet    True      ACK
6   DeviceNet    True      last      Response       0,-0.0895222,0
7   DeviceNet    True      ACK
8   DeviceNet    False               Request        RMS              Read current Flow State
9   DeviceNet    True      Start
10  DeviceNet    True      ACK
11  DeviceNet    True      Mid
12  DeviceNet    True      ACK
13  DeviceNet    True      last      Response      0,-0.0907981,0


We would like to arrive at line 6, and be able to look back to line 1 to understand the command issued. Alternatively, we could also create some state in line 1 which could be interpreted in line 6. Again, I'll emphasize we know this is not "foolprooof" but in the "no errors" case, would help us be able to quickly see what is happening.

Is there a way to add "state" that can be referenced between packets in this manner?

Much thanks for your assistance in helping us understand some of the power of Wireshark!

edit retag close merge delete

Sort by » oldest newest most voted

You should look at conversations and request\response tracking.

A conversation is a way to build up state from all the packets in the "conversation" and as each packet is dissected the dissector can add or read info from the conversation data structure, see README.dissector Sect 2.2.

Request\response tracking allows you to display useful information in the decode tree such as which requests are matched to which response and the response time for individual transactions, see README.request_response_tracking.

more

Thanks for the pointers... I can see there will be some more questions, as we peel this onion.

To Start:

1. It seems like "conversations" are meant to capture "sessions" modeled after things like an "ftp" session, etc... Here there is a clear "initiation" a collection of transactions, and a "conclusion".

In DeviceNet there is some concept of setting up a connection. In this case, we could conceivably create a new conversation based on the connection setup if we happen to be around for this, and likewise, end a conversation if we are around for a connection termination.

However, in most cases, the connections are persistent once set up, so we may not capture either a setup or teardown event.

In these cases, are "conversations" still useful, and if so, how might we "clue in" wireshark of pre-existing connections between devices? An example of this situation is that we want to ...(more)

( 2021-08-30 20:08:23 +0000 )edit

Obviously if the state you require isn't in the capture, then you can't complete dissection. The dissector should fail "gracefully" in that case.

TBH, I don't know the answers to your conversation addressing issues, I've only handled this at the TCP level. There are some other dissectors that are not IP based that also make use of conversations, e.g. packet-usb-i1d3.c

( 2021-08-31 09:11:05 +0000 )edit