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