search

hartkopp / can-isotp

Linux Kernel Module for ISO 15765-2:2016 CAN transport protocol PLEASE NOTE: This module is part of the mainline Linux kernel since version 5.10
Other
239 stars 69 forks source link

Is there a timeout between Consecutive Frames on isotprecv? #34

Closed Thomseeen closed 3 years ago

Thomseeen commented 3 years ago

In my current set up I am running a real CAN-bus with three different devices to produce ISO-TP messages and one Ethernet adapter used as a sink for those messages.

  1. A real ECU, that quickly responds to the Flow Control Frame. I can see the full conversation via candump and the assembled message via isotpsniffer and isotprecv (which is used to produce the Consecutive Frame).
  2. A second adapter, USB, to generate messages on my own. Works just as 1. does. All raw CAN frames visible via candump and the assembled PDUs via isotpsniffer and isotprecv.
  3. The curious one. A OBD-Simulator. Once again I can see all messages via candump and isotpsniffer can reassemble them, but isotprecv doesn't! Could this be caused as the OBD simulator responds quite slow? About 2ms for the first CF after the Flow Control Frame but 50ms till the second/last CF after the FCF. Maybe a timeout? It's weird as isotpsniffer seems like it doesn't timeout in this way.
$ isotprecv -s 7E0 -d 7E8 can0 -p 0 -l

$ candump -L can0,7FF:700 
(0000012752.119897) can0 7DF#0209020000000000
(0000012752.121322) can0 7E8#1014490201574458
(0000012752.121678) can0 7E0#3000000000000000
(0000012752.122951) can0 7E8#212D53494D303031
(0000012753.171596) can0 7E8#2239323132333435

$ isotpsniffer -s 7E0 -d 7E8 can0
 can0  7E8  [20]  49 02 01 57 44 58 2D 53 49 4D 30 30 31 39 32 31 32 33 34 35  - 'I..WDX-SIM0019212345'
hartkopp commented 3 years ago

There is a gap of nearly 1049ms not 49ms in your log. And yes, there is a timeout of 1 sec when the PDU transmission is active. Any idea what delays the second CAN frame for more than one second?

Thomseeen commented 3 years ago

I suppose it's just the Simulation Board and it's implementation. If this is intended behavior it is fine, 1s is a lot... just seemed inconsistent and hence confusing with the behavior of the isotpsniffer application.

hartkopp commented 3 years ago

Good point about the inconsistency! In fact in listen-only mode (which is used by isotpsniffer) the timeouts are not enabled: https://github.com/hartkopp/can-isotp/blob/master/net/can/isotp.c#L597 Will check if that can be changed without side effects.

hartkopp commented 3 years ago

Sent a fix for it on the linux-can ML: https://lore.kernel.org/linux-can/20201019120229.89326-1-socketcan@hartkopp.net/ Thanks Thomas!