Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 6651] Add dissector for CANopen protocol

Date: Wed, 7 Dec 2011 06:23:36 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6651

--- Comment #3 from Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> 2011-12-07 06:23:35 PST ---
(In reply to comment #2)
> Is CANopen a higher layer protocol, on top of SocketCAN, or an alternative
> protocol, besides SocketCAN?
> 
> In the first case, you should create a next_tvb and pass that to the CANopen
> dissector, just like you do with raw data.
> Why? Because the 'separation of protocol layers' is important. No two
> dissectors should work on the same frame data. When data has to be passed from
> one protocol layer to the next, the packet_info structure provides you the
> vehicle for that. 

This is really tricky with CAN. It differs from TCP/IP in many aspects. I'll
try to make an overview.

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.

Regarding this info how would you pass data to CANopen dissector?

> Some other details:
> 
> Why do a 'bytes_data = tvb_memdup' and add those (without freeing?), while you
> can do that with proto_tree_add_item()?

ACK

> '01.01.84' should be represented as '1 Jan 1984' (based on RFC 1123)

ACK

> "High-level protocol" preference label should be "Next level protocol", you
> never know (ref 'separation of protocol layers') what rides on top of your
> protocol.

ACK

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.