CAN libpcap capture endianess

CAN libpcap capture endianess

[Ico]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

Hello,

Recently I tried the CANopen module in wireshark to sniff on my slcan
interface, but the dissector seemed to mix up the endianess of the
capture. The source of the dissector seems to assume the CANopen data is
encoded in big endian, altough afaik CANopen uses little endian for its
data.

I contacted Yegor Yefremov, the contributor of the CANopen dissector,
who is now just confused as I am: he made some captures on his own
setup, on which the endianess is indeed different then from mine.

We both run on x86, so host endianess does not seem to be part of the
problem.

Hereby I attach two capture files, one made on my setup, and one made by
Yegor. Can oneone check which one has the proper endianess, and maybe
take a look at the current CANopen dissector in wireshark to see if the
implementation is ok?

Thank you,

Ico

attached:

1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86

-- 
:wq
^X^Cy^K^X^C^C^C^C

[-- Attachment #2: capture-ico.pcap --]
[-- Type: application/octet-stream, Size: 12940 bytes --]

[-- Attachment #3: capture-yegor.pcap --]
[-- Type: application/octet-stream, Size: 22128 bytes --]

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

Hello,

On 09/11/2013 07:42 PM, Ico wrote:
> Recently I tried the CANopen module in wireshark to sniff on my slcan
> interface, but the dissector seemed to mix up the endianess of the

When opening your attached files I don't see any CANopen related
dissecting happening in my wireshark (Version 1.10.1 (SVN Rev 50926 from
/trunk-1.10), from current Debian testing/jessie). Just normal raw CAN
frames are displayed.

> capture. The source of the dissector seems to assume the CANopen data is
> encoded in big endian, altough afaik CANopen uses little endian for its
> data.

Maybe you are mixing CANopen and plain raw CAN frames.

> I contacted Yegor Yefremov, the contributor of the CANopen dissector,
> who is now just confused as I am: he made some captures on his own
> setup, on which the endianess is indeed different then from mine.
> 
> We both run on x86, so host endianess does not seem to be part of the
> problem.

But you're using a 64 bit system while Yegor uses a 32 bit one
(according to your notes below).

> Hereby I attach two capture files, one made on my setup, and one made by
> Yegor. Can oneone check which one has the proper endianess, and maybe
> take a look at the current CANopen dissector in wireshark to see if the
> implementation is ok?

Your dump doesn't look correct in my wireshark, it has alternating
extended and standard frames and the standard frames have identifiers of
0x060000 which is not valid.

Does the command line tool candump show proper frames?

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-11 20:22:01 +0200, Marc Kleine-Budde wrote:
 
> > Recently I tried the CANopen module in wireshark to sniff on my
> > slcan interface, but the dissector seemed to mix up the endianess of
> > the
> 
> When opening your attached files I don't see any CANopen related
> dissecting happening in my wireshark (Version 1.10.1 (SVN Rev 50926
> from /trunk-1.10), from current Debian testing/jessie). Just normal
> raw CAN frames are displayed.

Since CAN does not have a way to distinguish between sub-protocols, wireshark
has no way to detect the payload as CANopen.  To force wireshark to use the
CANopen dissector, you can change the next level protocol in the preferences
window, as described here:

https://libbits.wordpress.com/2012/05/07/capturing-and-analyzing-can-frames-with-wireshark/

> But you're using a 64 bit system while Yegor uses a 32 bit one
> (according to your notes below).

Indeed, but I believe that should in no way interfere with captured data
endianess.

> Your dump doesn't look correct in my wireshark, it has alternating
> extended and standard frames and the standard frames have identifiers
> of 0x060000 which is not valid.
> 
> Does the command line tool candump show proper frames?

I'll have to look into that tomorrow, at this time I only have access to
the capture file I made earlier.

For the record: my capture was made with the following commands:

slcan_attach /dev/ttyUSB0 -o -s 5
slcand ttyUSB0
ifconfig slcan0 up
wireshark -i slcan0 -w capture.pcap

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On 09/11/2013 08:30 PM, Ico Doornekamp wrote:
> Since CAN does not have a way to distinguish between sub-protocols, wireshark
> has no way to detect the payload as CANopen.  To force wireshark to use the
> CANopen dissector, you can change the next level protocol in the preferences
> window, as described here:

Correct.

> https://libbits.wordpress.com/2012/05/07/capturing-and-analyzing-can-frames-with-wireshark/

I see, thanks.

>> But you're using a 64 bit system while Yegor uses a 32 bit one
>> (according to your notes below).
> 
> Indeed, but I believe that should in no way interfere with captured data
> endianess.
> 
>> Your dump doesn't look correct in my wireshark, it has alternating
>> extended and standard frames and the standard frames have identifiers
>> of 0x060000 which is not valid.
>>
>> Does the command line tool candump show proper frames?
> 
> I'll have to look into that tomorrow, at this time I only have access to
> the capture file I made earlier.

What kind of CAN hardware are you using? Maybe it's not compatible with
the existing driver.

> For the record: my capture was made with the following commands:
> 
> slcan_attach /dev/ttyUSB0 -o -s 5
> slcand ttyUSB0
> ifconfig slcan0 up
> wireshark -i slcan0 -w capture.pcap

I've never used a slcan device, but looks good, there aren't that many
options.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-11 20:38:15 +0200, Marc Kleine-Budde wrote:
 
> >> Does the command line tool candump show proper frames?
> > 
> > I'll have to look into that tomorrow, at this time I only have access to
> > the capture file I made earlier.
> 
> What kind of CAN hardware are you using? Maybe it's not compatible with
> the existing driver.

I'm using the CANUSB device from can232.com:

http://www.can232.com/?page_id=16

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Oliver Hartkopp]

On 11.09.2013 20:38, Marc Kleine-Budde wrote:
> On 09/11/2013 08:30 PM, Ico Doornekamp wrote:


>>> But you're using a 64 bit system while Yegor uses a 32 bit one
>>> (according to your notes below).
>>

I wonder if the used of an unsigned long data type for the u32 can_id
and the use of kstrtoul() might cause an issue on 64 bit platforms?!?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/slcan.c#n146

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/slcan.c#n164


The 'unsigned long' conversion was introduced in 2009 due to a report of Kurt van Dijck:

http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/drivers/net/can/slcan.c?op=revision&rev=919
http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/drivers/net/can/slcan.c?op=diff&rev=919&peg=919

but maybe kstrtouint()

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/kstrtox.c#n202

would be the better choice now.


>> Indeed, but I believe that should in no way interfere with captured data
>> endianess.
>>
>>> Your dump doesn't look correct in my wireshark, it has alternating
>>> extended and standard frames and the standard frames have identifiers
>>> of 0x060000 which is not valid.
>>>
>>> Does the command line tool candump show proper frames?
>>
>> I'll have to look into that tomorrow, at this time I only have access to
>> the capture file I made earlier.

Yes, that would be my first question too ...

Regards,
Oliver

Re: CAN libpcap capture endianess

[Oliver Hartkopp]

On 11.09.2013 20:53, Ico Doornekamp wrote:
> * On 2013-09-11 20:38:15 +0200, Marc Kleine-Budde wrote:
>  
>>>> Does the command line tool candump show proper frames?
>>>
>>> I'll have to look into that tomorrow, at this time I only have access to
>>> the capture file I made earlier.
>>
>> What kind of CAN hardware are you using? Maybe it's not compatible with
>> the existing driver.
> 
> I'm using the CANUSB device from can232.com:
> 
> http://www.can232.com/?page_id=16
> 

I do have this hardware at work.

And the slcan driver was originally implemented for this hardware.

I have to look, if i can find a Debian amd64 system for testing.
Usually our Laptops are i386 (32 bit) installations.

Best regards,
Oliver

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On 09/11/2013 09:17 PM, Oliver Hartkopp wrote:
> I wonder if the used of an unsigned long data type for the u32 can_id
> and the use of kstrtoul() might cause an issue on 64 bit platforms?!?

No, only if the CAN id is > 2^32  :D

> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/slcan.c#n146
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/slcan.c#n164

> The 'unsigned long' conversion was introduced in 2009 due to a report of Kurt van Dijck:
> 
> http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/drivers/net/can/slcan.c?op=revision&rev=919
> http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/drivers/net/can/slcan.c?op=diff&rev=919&peg=919

I think Kurt's solution to use an intermediate is correct.

> but maybe kstrtouint()
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/kstrtox.c#n202
> 
> would be the better choice now.

Oh, thanks, I didn't know that this library exists! Send patches :)

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On 09/11/2013 07:42 PM, Ico wrote:
> 1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
> 2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86

BTW:

> file *.pcap
> capture-ico.pcap:   pcap-ng capture file - version 1.0
> capture-yegor.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 65535)

You are using different tools.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-11 21:37:06 +0200, Marc Kleine-Budde wrote:
 
> On 09/11/2013 07:42 PM, Ico wrote:
> > 1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
> > 2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86
> 
> BTW:
> 
> > file *.pcap
> > capture-ico.pcap:   pcap-ng capture file - version 1.0
> > capture-yegor.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 65535)
> 
> You are using different tools.

That's fine for all I know, since a sniff is a sniff. The original
question - which endianess is the right one (and what causes the wrong
endian sniff) - still stands.
 

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On 09/11/2013 10:05 PM, Ico Doornekamp wrote:
> * On 2013-09-11 21:37:06 +0200, Marc Kleine-Budde wrote:
>  
>> On 09/11/2013 07:42 PM, Ico wrote:
>>> 1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
>>> 2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86
>>
>> BTW:
>>
>>> file *.pcap
>>> capture-ico.pcap:   pcap-ng capture file - version 1.0
>>> capture-yegor.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 65535)
>>
>> You are using different tools.
> 
> That's fine for all I know, since a sniff is a sniff. The original
> question - which endianess is the right one (and what causes the wrong
> endian sniff) - still stands.

I don't think so, there seems to be two different capture formats, the
tcpdump's and the wireshark's one.

I'm not familiar with the tcpdump capture format, but the
"(little-endian)" above suggests that the format supports both little
and big endianes.

And I'm neither familiar with wireshark. Is there an abstraction for the
different capture formats? Who handles the different endianesses? Maybe
it's a bug in the CAN dissector.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-11 22:11:04 +0200, Marc Kleine-Budde wrote:
 
> I'm not familiar with the tcpdump capture format, but the
> "(little-endian)" above suggests that the format supports both little
> and big endianes.

As far as I know wireshark should be able to handle both formats.

Maybe I can change the question so it's not directly related to capture formats
and wireshark:

I have can packets of SDO transfers (not the same objects, though). Can anyone
tell me which one has the data in proper byte order as it passed on the CAN
bus?

1: 8a 05 00 00 08 00 00 00 43 18 10 03 2f 01 00 00  
2: 00 00 06 02 08 5f db f6 2f 00 18 02 01 00 00 00   

1. packet #10 from capture-10. Node ID 10, SDO 0x1018sub3
2. packet #39 from capture-yegor. Node ID SDO 0x0018sub2

Thanks for your patience,

Ico

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On 09/12/2013 08:52 AM, Ico Doornekamp wrote:
> * On 2013-09-11 22:11:04 +0200, Marc Kleine-Budde wrote:
>  
>> I'm not familiar with the tcpdump capture format, but the
>> "(little-endian)" above suggests that the format supports both little
>> and big endianes.
> 
> As far as I know wireshark should be able to handle both formats.
> 
> Maybe I can change the question so it's not directly related to capture formats
> and wireshark:
> 
> I have can packets of SDO transfers (not the same objects, though). Can anyone
> tell me which one has the data in proper byte order as it passed on the CAN
> bus?

I don't speak CANopen...

> 1: 8a 05 00 00 08 00 00 00 43 18 10 03 2f 01 00 00  
> 2: 00 00 06 02 08 5f db f6 2f 00 18 02 01 00 00 00   
> 
> 1. packet #10 from capture-10. Node ID 10, SDO 0x1018sub3
> 2. packet #39 from capture-yegor. Node ID SDO 0x0018sub2

...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)));
> };

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* 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

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On 09/12/2013 10:47 AM, Ico Doornekamp wrote:
> * 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

"8a 05 00 00" in little endian is 0x0000058a, "08 00 00 00" is the dlc
of 8. Looks correct.

> 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.

They are assuming the wrong endianes for your capture file. Yegor's
capture file, which comes in another format, is interpreted correctly.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-12 10:52:34 +0200, Marc Kleine-Budde wrote:
 
> On 09/12/2013 10:47 AM, Ico Doornekamp wrote:
> > * 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
 
> "8a 05 00 00" in little endian is 0x0000058a, "08 00 00 00" is the dlc
> of 8. Looks correct.
> 
> > 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.
> 
> They are assuming the wrong endianes for your capture file. Yegor's
> capture file, which comes in another format, is interpreted correctly.

Sorry, I was not completely clear on this: I did the capturing on the
slcan0 interface from wireshark, so I did not make a capture file first.

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On 09/12/2013 11:09 AM, Ico Doornekamp wrote:

>> They are assuming the wrong endianes for your capture file. Yegor's
>> capture file, which comes in another format, is interpreted correctly.
> 
> Sorry, I was not completely clear on this: I did the capturing on the
> slcan0 interface from wireshark, so I did not make a capture file first.

In your original mail you've captured with wireshark, too, but written
into a file. Now you are capturing with wireshark directly. I assume the
same capturing engine (that one in wireshark) is involved in both
workflows and the same error is triggered in the
interpretation/dissection process.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2013-09-12 11:13:40 +0200, Marc Kleine-Budde wrote:
 
> On 09/12/2013 11:09 AM, Ico Doornekamp wrote:
> 
> >> They are assuming the wrong endianes for your capture file. Yegor's
> >> capture file, which comes in another format, is interpreted correctly.
> > 
> > Sorry, I was not completely clear on this: I did the capturing on the
> > slcan0 interface from wireshark, so I did not make a capture file first.
> 
> In your original mail you've captured with wireshark, too, but written
> into a file. Now you are capturing with wireshark directly. 

Correct. Yesterday I did not have access to the test setup, but today
I'm back at the lab.

> I assume the same capturing engine (that one in wireshark) is involved
> in both workflows and the same error is triggered in the
> interpretation/dissection process.

That's what I'm thinking as well. But the confusion arose because of the
dump I received from Yegor, which was decoded correctly by wireshark.

I've long learned that is usually safest to assume that strange errors
originate from myself instead of questioning other peoples software, but
in this case it seems that wireshark is at fault.

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Ico Doornekamp]

Sorry to resurrect this three your old thread, but it seems that the
issue stil exists, and the source of the problem does not seem to lie in
wireshark, but somewhere in the can-raw handling.

There still seems to be an endianess problem with raw socket access to slcan
devices. The original message from sep 2013 is pasted below this mail.

I have found a simple way to reproduce, this is what I do:

- setup a vcan device 'vcan0'

  modprobe vcan
  ip link add dev vcan0 type vcan
  ip link set vcan0 up 

- setup a slcan device 'slcan0'. You do not need an actual slcan
  interface, it is enough to slattach to any serial device

  slcan_attach -s5 /dev/ttyUSB0
  slcand -o -c -f -s5 ttyUSB0
  ifconfig slcan0 up

- send a CAN frame on vcan0 and observe in wireshark:

  $ cansend vcan0 '123#00000000'

  1 0.000000 -> CAN 12 STD: 0x00000123 00 00 00 00


- send a CAN frame on slcan0 and observe in wireshark:

 $ cansend slcan0 '123#00000000'

 1 0.000000000 -> CAN 16 ERR: 0x03010000 00 00 00 00


The problem resides in the endianess of the CAN ID that is decoded. On vcan0
the proper address is seen (0x00000123), but on slcan0 the address is read in
the wrong order (0x03010000).

I have verified that the CAN message on the bus on slcan0 is actually
sent with ID 0x123. Messages received from other devices are also shown
with wrong endianess.


* On 2013-09-11 19:42:43 +0200, Ico wrote:
 
> Recently I tried the CANopen module in wireshark to sniff on my slcan
> interface, but the dissector seemed to mix up the endianess of the
> capture. The source of the dissector seems to assume the CANopen data is
> encoded in big endian, altough afaik CANopen uses little endian for its
> data.
> 
> I contacted Yegor Yefremov, the contributor of the CANopen dissector,
> who is now just confused as I am: he made some captures on his own
> setup, on which the endianess is indeed different then from mine.
> 
> We both run on x86, so host endianess does not seem to be part of the
> problem.
> 
> Hereby I attach two capture files, one made on my setup, and one made by
> Yegor. Can oneone check which one has the proper endianess, and maybe
> take a look at the current CANopen dissector in wireshark to see if the
> implementation is ok?
> 
> Thank you,
> 
> Ico
> 
> attached:
> 
> 1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
> 2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86
> 

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Oliver Hartkopp]

On 05/10/2016 09:25 PM, Ico Doornekamp wrote:
> Sorry to resurrect this three your old thread, but it seems that the
> issue stil exists, and the source of the problem does not seem to lie in
> wireshark, but somewhere in the can-raw handling.
>
> There still seems to be an endianess problem with raw socket access to slcan
> devices. The original message from sep 2013 is pasted below this mail.
>
> I have found a simple way to reproduce, this is what I do:
>
> - setup a vcan device 'vcan0'
>
>    modprobe vcan
>    ip link add dev vcan0 type vcan
>    ip link set vcan0 up
>
> - setup a slcan device 'slcan0'. You do not need an actual slcan
>    interface, it is enough to slattach to any serial device
>
>    slcan_attach -s5 /dev/ttyUSB0
>    slcand -o -c -f -s5 ttyUSB0
>    ifconfig slcan0 up
>
> - send a CAN frame on vcan0 and observe in wireshark:
>
>    $ cansend vcan0 '123#00000000'
>
>    1 0.000000 -> CAN 12 STD: 0x00000123 00 00 00 00
>
>
> - send a CAN frame on slcan0 and observe in wireshark:
>
>   $ cansend slcan0 '123#00000000'
>
>   1 0.000000000 -> CAN 16 ERR: 0x03010000 00 00 00 00
>
>
> The problem resides in the endianess of the CAN ID that is decoded. On vcan0
> the proper address is seen (0x00000123), but on slcan0 the address is read in
> the wrong order (0x03010000).
>
> I have verified that the CAN message on the bus on slcan0 is actually
> sent with ID 0x123. Messages received from other devices are also shown
> with wrong endianess.

Hello Ico,

usually the CAN subsystem has no problems with host/network byte order:
The struct can_frame contains the CAN ID which is set into the CAN 
controller registers inside the CAN driver.

As wireshark uses the PF_PACKET socket to read the CAN frames it might 
make assumptions about the byte order of read elements.

Can you check the output from tst-packet on vcan0 / slcan0:

	./tst-packet -i vcan0

from

	https://github.com/linux-can/can-tests

Regards,
Oliver

>
>
> * On 2013-09-11 19:42:43 +0200, Ico wrote:
>
>> Recently I tried the CANopen module in wireshark to sniff on my slcan
>> interface, but the dissector seemed to mix up the endianess of the
>> capture. The source of the dissector seems to assume the CANopen data is
>> encoded in big endian, altough afaik CANopen uses little endian for its
>> data.
>>
>> I contacted Yegor Yefremov, the contributor of the CANopen dissector,
>> who is now just confused as I am: he made some captures on his own
>> setup, on which the endianess is indeed different then from mine.
>>
>> We both run on x86, so host endianess does not seem to be part of the
>> problem.
>>
>> Hereby I attach two capture files, one made on my setup, and one made by
>> Yegor. Can oneone check which one has the proper endianess, and maybe
>> take a look at the current CANopen dissector in wireshark to see if the
>> implementation is ok?
>>
>> Thank you,
>>
>> Ico
>>
>> attached:
>>
>> 1. capture-ico.pcap: CAN-232 interface, slcan, x86_64
>> 2. capture-yegor.pcap: VScom USB-CAN interface, slcal, x86
>>
>

Re: CAN libpcap capture endianess

[Oliver Hartkopp]

Hello Ico,

On 05/11/2016 09:48 AM, Ico Doornekamp wrote:
> * On 2016-05-11 09:40:41 +0200, Oliver Hartkopp wrote:
>
>> usually the CAN subsystem has no problems with host/network byte order:
>> The struct can_frame contains the CAN ID which is set into the CAN
>> controller registers inside the CAN driver.
>>
>> As wireshark uses the PF_PACKET socket to read the CAN frames it might
>> make assumptions about the byte order of read elements.
>>
>> Can you check the output from tst-packet on vcan0 / slcan0:
>>
>>      ./tst-packet -i vcan0
>
> Yes, this gives the expected result for both vcan and slcan:
>
>    $ sudo ./tst-packet
>    123  [4] 00 00 00 00
>    123  [4] 00 00 00 00
>
> Still it makes no sense to me that wireshark does seem to make a
> difference when sniffing on vcan and slcan:

That's strange indeed.

Both interfaces do not support IFF_ECHO (echo of sent CAN frames on 
driver level) so both should trigger this shortcut in af_can.c:

http://lxr.free-electrons.com/source/net/can/af_can.c#L284

Can you send the output of

ip -details link show vcan0
ip -details link show slcan0

??

>
>   1 0.000000 -> CAN 12 STD: 0x00000123 00 00 00 00
>   1 0.000000 -> CAN 16 ERR: 0x03010000 00 00 00 00

At least the CAN ID is 'AND'ed with CAN_ERR_MASK 0x1FFFFFFF :-)
That's the reason for the missing '2' due to  CAN_ERR_FLAG.

>
> I'll try to find the time to dig in the kernel and wireshark code to
> find out what causes the difference.

Btw, can you check if this patch fixes the issue:

diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index 9a3f15c..58ba098 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -202,16 +202,19 @@ static void slc_bump(struct slcan *sl)
  		}
  	}

-	skb = dev_alloc_skb(sizeof(struct can_frame) +
-			    sizeof(struct can_skb_priv));
-	if (!skb)
+	skb = netdev_alloc_skb(sl->dev, sizeof(struct can_skb_priv) +
+			       sizeof(struct can_frame));
+	if (unlikely(!skb))
  		return;

-	skb->dev = sl->dev;
  	skb->protocol = htons(ETH_P_CAN);
  	skb->pkt_type = PACKET_BROADCAST;
  	skb->ip_summed = CHECKSUM_UNNECESSARY;

+	skb_reset_mac_header(skb);
+	skb_reset_network_header(skb);
+	skb_reset_transport_header(skb);
+
  	can_skb_reserve(skb);
  	can_skb_prv(skb)->ifindex = sl->dev->ifindex;
  	can_skb_prv(skb)->skbcnt = 0;


I posted this patch in February 2015

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=969439016d2cf61fef53a973d7e6d2061c3793b1

and obviously forgot slcan.c ...

Thanks,
Oliver

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2016-05-11 10:17:13 +0200, Oliver Hartkopp wrote:
 
> That's strange indeed.
> 
> Can you send the output of
> 
> ip -details link show vcan0
> ip -details link show slcan0

$ ip -details link show vcan0
4: vcan0: <NOARP,UP,LOWER_UP> mtu 16 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/can  promiscuity 0 
    vcan 

$ ip -details link show slcan0
7: slcan0: <NOARP,UP,LOWER_UP> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 

> At least the CAN ID is 'AND'ed with CAN_ERR_MASK 0x1FFFFFFF :-)
> That's the reason for the missing '2' due to  CAN_ERR_FLAG.

Indeed, I figured that much already.

> Btw, can you check if this patch fixes the issue:

This pach seems to be already in the 4.4.0 kernel, which I'm running.

-- 
:wq
^X^Cy^K^X^C^C^C^C

Re: CAN libpcap capture endianess

[Oliver Hartkopp]

On 05/11/2016 02:28 PM, Ico Doornekamp wrote:
> * On 2016-05-11 10:17:13 +0200, Oliver Hartkopp wrote:
>
>> That's strange indeed.
>>
>> Can you send the output of
>>
>> ip -details link show vcan0
>> ip -details link show slcan0
>
> $ ip -details link show vcan0
> 4: vcan0: <NOARP,UP,LOWER_UP> mtu 16 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
>      link/can  promiscuity 0
>      vcan
>
> $ ip -details link show slcan0
> 7: slcan0: <NOARP,UP,LOWER_UP> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
>      link/can  promiscuity 0
>

When my posted patch does not have an effect it may be worth looking at 
the differences of the selected qdiscs (noqueue/pfifo).

>> At least the CAN ID is 'AND'ed with CAN_ERR_MASK 0x1FFFFFFF :-)
>> That's the reason for the missing '2' due to  CAN_ERR_FLAG.
>
> Indeed, I figured that much already.
>
>> Btw, can you check if this patch fixes the issue:
>
> This pach seems to be already in the 4.4.0 kernel, which I'm running.

Hm - no.

The patch I posted changes slcan.c - which the original patch did not touch.

The slcan.c patch is based on latest Linux 4.6.0-rc7-00055-gc511462 :-)

Please try it out.

Regards,
Oliver

Re: CAN libpcap capture endianess

[Ico Doornekamp]

* On 2016-05-11 15:25:46 +0200, Oliver Hartkopp wrote:
 
> When my posted patch does not have an effect it may be worth looking at 
> the differences of the selected qdiscs (noqueue/pfifo).

No difference with the patch, I'll look into the qdiscs

> Hm - no.

Sorry, my wrong - I missed the part where you said 'I forgot slcan.c', and just
took a look at the patch in the link.

-- 
:wq
^X^Cy^K^X^C^C^C^C