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" isCAN 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" isCAN ID (4 bytes). Only
CAN IDs of 11 or 29 bits, no higher bits setPayload 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.lini...@gmail.com>
To: wireshark-dev <wireshark-dev@wireshark.org>
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.bro...@ericsson.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
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@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
