Seems like the DTLs are exactly what I was looking for, didn't know about that until now.
The information that I will sending could me made identical to SocketCAN. Would it be ok to reuse the same DTL as SocketCAN? Doing this I would only need to write a dissector for the higher layer protocol and hook it to SocketCAN in a similar way as CANopen.
Thanks,
Joakim
>-----Original Message-----
>From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Felix Obenhuber
>Sent: den 26 april 2012 17:22
>To: Developer support list for Wireshark
>Subject: Re: [Wireshark-dev] Capturing CAN packets
>
>On Thu, Apr 26, 2012 at 4:03 PM, Joakim Wiberg <jow@xxxxxx> wrote:
>> Any suggestions on how we shall encapsulate the CAN frames in Ethernet frames to make them show up in Wireshark in a logical way.
>>
>> The current implementation that's using a OUI in the SNAP header works, but is this the preferable way? Is it better to use an unused Ethernet type, or something else?
>
>Can you describe why you choose the way over the NIC and not over pcap? When you connect your CAN capture code to pcap you can use some DLT as it is done for USB or SocketCAN etc.
>I know it's a mess, that all CAN device manufacturer provide it's own API for Windows due to the lack of something like SocketCAN.
>Felix
