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.
Dmitriy Linikov.