On Nov 8, 2015, at 3:56 AM, Kumquat KromKiller <[email protected]> 
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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to