lost frames when running isotpsend

[ayoubensi]

Hello,

i'm facing a bit confusing problem with isotp module,

First, i used to get the isotp module for CAN communication in an embedded arm target, i have built the kernel module on my host machine (ubuntu 14.04 kernel version 4.4.0 ) and load it to the kernel as instructed (insmod ...) and then test it successfully with a peak-CAN device :

then comes the next step to build the kernel to the Embedded target (arm cortexa9hf with yocto based linux kernel "version : 3.10"), using its SDK, i managed this and i cross compiled the ISOTP module and transfer it to the target, after connecting to target (ssh connection) i loaded the driver to the kernel and try to test it using the CAN−ISOTP utilities (isotpsend, isotpdump) but i got nothing :

the frames are not getting out of the target's CAN controller !

I want to know if the issue could be from the ISOTP module or the CAN hardware driver (which is integrated in the kernel) or the Software running on the target which already provides a CAN API which is split into two parts;

• One part is for sending and receiving data and is based on the standard Linux PF_CAN
  socket interface.
• The other part is the configuration part which is done via D-Bus :
  

If someone could help me i'll be very grateful

[marckleinebudde]

Can you send RAW CAN frames with cansend and receive them via candump?

[ayoubensi]

Hello, Unfortunately No, when sending with cansend, the candump does not show anything, the picture below show that clearly Best. [image: image.png] Le mer. 2 juin 2021 à 11:00, Marc Kleine-Budde ***@***.***> a écrit :

…

Can you send RAW CAN frames with cansend and receive them via candump? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#299 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHAFRUGB3GRDREC5D3WNFLTQX6K3ANCNFSM456KXKNA> .

-- -------------------------------------------- AYOUB ISMAIL *Élève ingénieur en informatique * *Spécialité Systèmes et Logiciels Embarqués(SLE)* *************************************************************************************** * Linkedin <https://www.linkedin.com/in/ayoub-ismail-b77796132>* Téléphone: (+216) 26 003 274

[marckleinebudde]

I think pictures and reply-via-mail doesn't work.

BTW: Instead of pictures you can copy/paste the console output and mark it as code via the web interface.

If cansend and candump is not working, then it's not a ISOTP issue. Check you CAN setup for common bitrate and proper termination first.

[ayoubensi]

Hello again ! Sorry i didn't know that pictures did not show up, so i've tried to send CAN frames through *cansend* : $ cansend can0 123#2233445566778899 $ cansend can0 123#2233445566778899 $ cansend can0 123#2233445566778899 i got nothing in *candump* command : $ candump can0 Also i was given a demo application for CAN that writes random frames using CAN_RAW sockets and it worked successfully ( i was able to see frames by candump) i tried to debug the source of cansend and compare it to the demo app i just noticed that the only difference when initializing SocketCAn using *struct sockaddr_can addr *is that : the demo app affects : *addr.can_family = PF_CAN;* the cansend affects : *addr.can_family = AF_CAN;* Is there a difference ? otherwise ...could the problem be from the CAN hardware ? Thank you very much for your help.

[marckleinebudde]

AF_CAN and PF_CAN are the same:

include/linux/socket.h:207:#define AF_CAN               29      /* Controller Area Network      */
include/linux/socket.h:261:#define PF_CAN               AF_CAN

Please test you demo application again. There is no reason why it work, but not cansend. Have you checked that both interfaces are up, using the same bitrate and the bus is properly terminated?

[hartkopp]

The output of

ip -det link show can0

and

uname -a

would be interesting too.
Linux 3.10 is really old stuff so it would be interesting to know the patch level and the driver states.
E.g. when there is a out-of-tree c_can driver with unknown patches integrated in Yocto ...

[ayoubensi]

@hartkopp
The bus state shows "PASSIVE" state, although i was running a demo app that uses the can0 interface and writes can frames:

[marckleinebudde]

Have you checked that both interfaces are up, using the same bitrate and the bus is properly terminated?

[ayoubensi]

well, yes, i checked the wiring many times, i'm connecting my embedded target's CAN interface(can0 with 250 000 bitrate) to a peak-can-device which is connected to my laptop (also named can0 with the same bitrate) just to test if the CAN frames are getting out correctly from the embedded target...

[marckleinebudde]

Is the bus is properly terminated?

[ayoubensi]

yes it is properly terminated

[hartkopp]

what does the '-r' option in
./can_demo -i can0 -r 250000
mean?
Does the can_demo set the bitrate too?
Because cansend does NOT do such things.

[ayoubensi]

yes the ./can_demo sets the bitrate ( given with th option -r ) using the a Dbus API...

[hartkopp]

yes the ./can_demo sets the bitrate ( given with th option -r ) using the a Dbus API...

And what happens after ./can_demo has terminated? Is the bitrate still set and the interface still 'up'?
E.g. cansend assumes the CAN interfaces to be up and running.

And this is done with the ip tool:
https://www.kernel.org/doc/html/latest/networking/can.html#the-can-network-device-driver-interface

I wonder if the 'actiacan' driver behaves correctly like a standard Linux/SocketCAN driver in terms of configuration. The 'actiacan' driver is not in mainline Linux and I wasn't able to get information about it on the internet ...

[marckleinebudde]

@hartkopp it's probably one of those devices:
https://actia.se/media/2106/tgu-r-access-produktblad.pdf
https://www.actia.se/media/2192/acu6-pro-automotive_product-brief_v35.pdf
https://www.actia.se/media/2193/acu6-pro-off-highway_product-brief_v36.pdf

Maybe we should send them a GPL request. 😄

[hartkopp]

Wierd! I assume we do not have the CAN FD version's but the one with a single Classical CAN - but in any case Linux 3.10.17 is horrible EOL. Even the 3.10.108 is 3.5 years old m(

[marckleinebudde]

If the interface is ERROR-PASSIVE and the TX error counter is 127, it usually means the bus is properly terminated, but the sender is the only CAN unit on the bus.

[ayoubensi]

Hi !

@hartkopp the CAN interface is always up when the embedded device get powered, i just checked now because i don't have access to the device 24h by 24h :

it seems also the bitrate has been maintained 250000 since last use with the demo app :

also i tried to invoke the can utlities one more time :

but i still get nothing on candump can0
this is very strange, the TX value has changed from 0 to 96 .B after executing cansend :

you mentioned the CAN FD version and the classical CAN, i parsed the demo app source again and i found that the CAN frame structure used is struct can_frame frame unlike the can utility "cansend" which uses struct canfd_frame frame, could the issue be from that ? because although the configuration of the CAN interface is done via a Dbus API which is not classical , it seems the interface is fine in terms of termination and status...

[ayoubensi]

@marckleinebudde could the candump show frames even if the CAN unit is only on the bus ? and could ERROR-PASSIVE or ERROR-ACTIVE could tell us more about the traffic on the bus and whether the CAN driver is working fine or not ? i'm trying to parse the transmission of the CAN frame from the higher layer to the lower layer (physical layer) , if the socket CAN has been created and bounded successfully to the CAN interface, could we be certain that thewrite() function will work perfectly as we expect ?

[marckleinebudde]

could the candump show frames even if the CAN unit is only on the bus ?

Usually not, depends on the driver.

and could ERROR-PASSIVE or ERROR-ACTIVE could tell us more about the traffic on the bus and whether the CAN driver is working fine or not ?

If you send a single CAN frame and the interface goes to ERROR-PASSIVE and the TX error counter is 127, it usually means the bus is properly terminated, but the sender is the only CAN unit on the bus.

i'm trying to parse the transmission of the CAN frame from the higher layer to the lower layer (physical layer) , if the socket CAN has been created and bounded successfully to the CAN interface, could we be certain that the write() function will work perfectly as we expect ?

I suggest to use ip to configure your CAN interface and cansend, candump for testing. I don't have access to your demo app, nor the dbus interface for configuration.

[ayoubensi]

@marckleinebudde command not found ...

[marckleinebudde]

You don't need sudo if you're already root.

[ayoubensi]

@marckleinebudde sorry i always forget that trick when working with this embedded device, BTW, it seems that even with ip link command we can't configure the CAN interface which is already up (the target has 2 CAN interfaces can0 and can1, i tested both of them with ip link ) :

[hartkopp]

You need to set the interface into "down" state before setting the bitrate.
Changing the bitrate 'on the fly' is not supported ;-)