On Nov 8, 2015, at 3:56 AM, Kumquat KromKiller <kromkillerkumquat@xxxxxxxxx> wrote:
> When I say plain, maybe I should have said that I'm working at FPGA-level.
> Basically, when I receive a CAN message, I put everything between start-of-frame and end-of-frame in the Ethernet payload and since the length of the payload is less than 0x0600, I use the EtherType to store the length.
>
> If I hear you right, the best option for now is to comply with the SocketCAN format, choose an unused EtherType and write a dissector that basically just tell Wireshark that this particular EtherType is in fact SocketCAN ?
> That is great because the code for this dissector should be pretty small.
>
> Still, it isn't out-of-the-box. Can you confirm me that this is not possible ?
The only ways in which standard Wireshark, out of the box, will recognize CAN packets are if:
1) the packets are in a pcap file with a link-layer header type of 227, or a pcap-ng file in which the interface for those packets has a link-layer header type of 227, and the packets begin with a SocketCAN header
or
2) the packets are in a pcap file with a link-layer header type of 113, or a pcap-ng file in which the interface for those packets has a link-layer header type of 113, and the packets begin with a Linux cooked capture header:
http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html
in which the protocol type field has a value of 0x000C
and neither of those will ever be the case for an Ethernet capture (the link-layer header type for a pcap file or a pcap-ng interface will be 1 for Ethernet captures).
So, no, it is not possible to make this work out of the box.
