Wireshark-users: Re: [Wireshark-users] Custom CAN dissector script

From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 5 Jun 2023 14:39:14 -0700
On Jun 5, 2023, at 1:58 PM, Fabian Cenedese <Cenedese@xxxxxxxx> wrote:

> At 22:29 05.06.2023, Guy Harris wrote:
> 
>> On Jun 5, 2023, at 3:43 AM, Fabian Cenedese <Cenedese@xxxxxxxx> wrote:
>> 
>>> We're using CAN bus as protocol and I implemented a capture
>>> to save the sent and received frames into a .pcapng file.
>> 
>> So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in the IDBs, with the SocketCAN pseudo-header:
>> 
>>       https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
> 
> I also tried CAN20B (190), but now I'm using SOCKETCAN (227) as this
> worked better.

Unfortunately, CAN20B was never documented, and the people at CACE Technologies^W^WRiverbed^WSysdig don't remember what it was any more.

So, yes, LINKTYPE_CAN_SOCKETCAN is what should be used.

>> If by "script" you mean "dissector written in Lua rather than C", that's going to be a bit tricky; subdissectors called by the SocketCAN dissector are passed a pointer to a structure that includes, among other things, the ID, but that's a C structure, and we don't currently have a good way to pass information to Lua subdissectors.
> 
> I just assumed that lua is the fastest or easiest way to go, but I could
> also create a dll if that is better.

"Better" depends on the criteria; if your dissector needs to get at the CAN ID, as their... nonstandard way of using the ID seems to indicate, a C dissector would be "better" in that, currently, there's no way to get that from Lua.

(In the long term, we should provide a way to get at that from Lua (which might also involve passing information as a key-value store, which would also help *C* dissectors, as, instead of getting a blob whose structure is defined only by convention between the calling and called dissector, which is rather fragile, they'd get it as a key-value store as well.  But that's not what we have now.)

>>> as well as the first data byte.
>>> 
>>> How would I register this dissector as it doesn't use an Ethernet
>>> port?
>> 
>> Not sure what an "Ethernet port" is, but various dissectors that call subdissectors have dissector tables using various keys, such as Ethernet types, TCP or UDP ports, and so on.
> 
> Exactly, always Ethernet related.

TCP and UDP ports aren't Ethernet-related; only Ethernet types are.