Wireshark · Wireshark-dev: Re: [Wireshark-dev] What is best way to use other protocol subdissectors?

[Michael Mann <mmann78@xxxxxxxxxxxx>]

What is the format of the IEEE-1722 "CAN message"?  From my experience there are many different formats for CAN, so I think it's abstracted as best it can be.  The SocketCAN "packet format" is

CAN ID (4 bytes).  Since CAN IDs are typically 11 or 29-bits, SocketCAN uses some of the higher bits for other flags.

Payload length (1 byte)

"Padding" (3 bytes)

<CAN payload>  (size based on payload length).

Since the CAN ID is not "on the wire" for many CAN protocols (it's just the 8 byte payload), subdissectors have been set up to accept the 32-bit CAN ID as a "data parameter" passed into the dissection function.  Technically, I think Maksim Salau expanded it to a full structure (probably to accommodate/mask the higher bits of SocketCAN).  This does fall a little under first dissector gets to more heavily influence the interface.

All CAN protocols have registered with the "can.subdissector", where the "interface" is expecting the "data parameter" structure that is dictated by SocketCAN.  However any dissector has access to use the "can.subdissector" table.  For example, if the IEEE-1722 "packet format" is

CAN ID (4 bytes).  Only CAN IDs of 11 or 29 bits, no higher bits set

Payload length (1 byte)

<CAN payload> (size based on payload length)

The IEEE-1722 "CAN dissector" can enumerate the "header fields" of CAN ID and Payload length, and reuse the same display names like can.id, and then get a handle to the "can.subdissector" table and call dissector_try_payload_new() just like the SocketCAN dissector does.  Just be aware that the data parameter of dissector_try_payload_new() has to match the structure that SocketCAN uses because that is the "interface" that the "can.subdissector" dissector table has defined.

With the "can.subdissector" there isn't a way to determine which subdissector should be called (so you always have to use Decode As).  Some protocols, like TCP or UDP can key off of the "port number" to determine which subdissector to call and subdissectors can register by that port number.

If the IEEE-1722 "packet format" has a field to determine which CAN protocol followed (i.e. 1 = J1939, 2 = CANOpen), then it should setup its own subdissector table ("1722can.subdissector"), and then the CAN protocols themselves would need to register with that dissector table as well, with the value of the field used to call them.

Hope this provides a little more clarity.

-----Original Message-----
From: Dmitriy Linikov <dmitriy.linikov@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Jan 30, 2019 6:01 am
Subject: Re: [Wireshark-dev] What is best way to use other protocol subdissectors?

Date: Wed, 30 Jan 2019 09:42:30 +0000
From: Anders Broman <anders.broman@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] What is best way to use other protocol subdissectors?

Why do you need to add “fake "can.flags.xxx" to the list of protocol fields”?

I want wireshark to treat ACF-CAN submessages of IEEE1722 like any regular can message that is handled by packet-socketcan: decode payload and use the same filters.

I think the reason for that is that you are adding hf variables to a protocol whose name is ieee1722 and in that case the expected format is

Ieee1722.can.flags.rtr. I guess you should register your sub protocol and name the hf’s accordingly but it’s hard to say with the information given.

Publish you code snippet?

 

The example of such code can be seen in packet-caneth.c which is also a transport protocol for CAN messages over Ethernet. It defines "can.id" and other "can.xxx" hf in addition to its own "caneth.magic", "caneth.version", etc.

Maksim Salau has already pointed me to the list of exceptions in "sub is_from_other_protocol_whitelist" in tools/checkfiltername.pl, but still I'm not sure whether it is the right way to do it.

It looks like there is a flaw in wireshark's CAN support which is at the moment not abstract and is bound to the Linux-specific SocketCAN driver implementation.

Best regards,

Dmitriy Linikov.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe