Re: CAN libpcap capture endianess

[Ico Doornekamp <can@zevv.nl>]

* On 2013-09-12 10:00:10 +0200, Marc Kleine-Budde wrote:
 
> ...but your CAN frames don't look correct in wireshark. I suggest you
> bring up the command line tools and use candump to display the raw CAN
> frames. Raw CAN frames, as they enter the application, are in host
> order. To be precise the can_id is in host order, as all other members
> are u8. "data" is an array of 8 x u8, which is in fact big endian
> ordered, if you want to access it with 2x32 or 64 bit.
> 
> > struct can_frame {
> >         canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
> >         __u8    can_dlc; /* frame payload length in byte (0 .. CAN_MAX_DLEN) */
> >         __u8    data[CAN_MAX_DLEN] __attribute__((aligned(8)));
> > };

I just did this. candump shows this:

  slcan0  58A   [8]  4B 12 20 04 D6 00 00 00

The raw data is shown in wireshark as

  8a 05 00 00 08 00 00 00  4b 12 20 04 d6 00 00 00

The CAN dissector parses this as identifier 0x0a050000 with the
'extended' flag set , which seems to have the wrong endianess.

The CANopen dissector also interprets the identifier with wrong endian
order, and is thus not able to decode the rest of the packet.

If I'm not mistaking, both the CAN and CANopen dissector in wireshark
are thus assuming wrong endianess. I'll check the source and see if I
can come up with a proper patch for the wireshark team.

Thank you for your feedback,

Ico