Re: What is best way to use other protocol subdissectors?

[Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>]

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.linikov () 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.broman () 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-request () 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-request () wireshark org?subject=unsubscribe