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?
Thanks,
Joakim
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Joakim Wiberg
Sent: den 24 april 2012 09:37
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Capturing CAN packets
The socketcan dissector seems to decode the same things that we intended to provide as well. Your suggesting adding a packet-can.c where higher layer protocols can hook up makes sense.
Any suggestions on how the Windows app shall interface with Wireshark? Is the usage of an OUI in the SNAP header a feasible or shall we look at some other way?
Thanks,
Joakim
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Felix Obenhuber
Sent: den 23 april 2012 19:06
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Capturing CAN packets
Hi,
On Mon, Apr 23, 2012 at 5:43 PM, Joakim Wiberg <jow@xxxxxx> wrote:
> My understanding is that the socketcan part only works on Linux. The
> attempt here was to create a Windows application captures the CAN
> frames and hands them over to Wireshark. The packets could be passed
> directly on to packet-socketcan.c (and then later to packet-canopen.c)
> if there were a way to tag the packets as socketcan packets.
Yes, SocketCAN runs on Linux only.
Maybe a dedicated CAN dissector ( e.g packet-can.c) with it's own format (or why not take the very well designed SocktCAN format?) might be a good idea for a clear design. This CAN dissector is served by the SocketCAN dissector and your Windows CAN implementation.
The CanOpen (and other high level protocols like J1939) dissectors hook up on the CAN dissector.
Please note that the the data format that is used within the SocketCAN dissector is declared in the SocketCAN implementation (e.g struct can_frame and the bits coded into the id field). Furthermore SocketCAN defines a full set error codes that are indicated by the error flag in the id and transmitted in the data bytes.
Here you can find the corresponding headers with some details about SocketCAN:
https://gitorious.org/linux-can/linux-can/blobs/master/include/linux/can.h
https://gitorious.org/linux-can/linux-can/trees/master/include/linux/can/
cheers,
Felix
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
