https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6651
--- Comment #7 from Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> 2011-12-11 23:49:30 PST ---
(In reply to comment #6)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Is CANopen a higher layer protocol, on top of SocketCAN, or an alternative
> > > protocol, besides SocketCAN?
> > >
> ...
> > SocketCAN (http://en.wikipedia.org/wiki/Socketcan) is just a driver/framework
> > for CAN (http://en.wikipedia.org/wiki/Controller_area_network). So SocketCAN
> > dissector fetches a CAN frame (ID, flags, data length and data (max. 8 bytes)).
> > This is raw CAN data without much interpretation. This is sufficient for custom
> > protocols running over CAN or diagnostics.
> >
> > CANopen (http://en.wikipedia.org/wiki/Canopen) uses CAN as transportation layer
> > and really interprets the CAN frames. The problem is it uses both ID and data,
> > so I can't just pass the 8 bytes of data field. I need the whole CAN frame. The
> > separation of SocketCAN and CANopen gives me on overview about CAN frame flags
> > like extended/standard frame, error frame etc. In CANopen dissector I provide
> > info about CANopen frame type and its fields.
> >
>
> So what you are saying is that both SocketCAN and CANopen sit on top of the
> CAN datalink layer? CANopen has no relation with SocketCAN other than working
> on the same communications medium?
> Then one or the other should bind to WTAP_ENCAP_SOCKETCAN and LINUX_SLL_P_CAN,
> not stacked like this.
Both CAN/SocketCAN dissector (that represents raw CAN frames) and CANopen
dissector operate on the same data - CAN frame. But logically there is
hierarchy: CANopen comes on top of CAN. So CANopen is to be called from CAN
dissector. CANopen can be also used with Industrial Ethernet as datalink layer,
so it have to be independent. CAN frames should have both CAN part showed (ID,
flags, data length) and interpreted part (CANopen, DeviceNet etc.), just like
in my implementation.
CAN dissector already binds to WTAP_ENCAP_SOCKETCAN and LINUX_SLL_P_CAN, so the
data is already extracted from the pcap, now it can be just showed or
interpreted. Due to differences between CAN and let's say TCP (no port number,
no protocol identification in header) this option should be available in the
lowest dissector i.e. in CAN dissector. CAN and CANopen can be seen as IP and
TCP or TCP and http, with the difference that user is responsible for defining
the representation.
The only issue id that both operate on the same buffer. For CANopen would be
sufficient if ID and perhaps data length could be given to dissector
separately, so that CANopen dissector is called only with max. 8 bytes data in
tv buffer and not the whole CAN frame.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.