CAN frames lost when stmin > 0 about can-isotp HOT 9 CLOSED

Closed due to applied fix 3852256

from can-isotp.

Hi,
I tested your setup (including the python command line) with isotprev with either '-m 64' and without '-m' option (meaning STmin = 0) and I got this

I'm running the latest Linux 4.20.0-rc6-00161 with latest isotp.c.

What kind of machine are you running on? Can you send a candump -td dump?

from can-isotp.

Running on a virtualized ubuntu 16.04 using VMware Workstation V11.0
uname -a gives Linux ubuntu 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

candump with timings gives:

from can-isotp.

Strangley enough. I've compiled the module with debug enabled and the module started to behave properly. I then recompiled without debug (by #undef DBG...) and the issue came back.

Kind of look like the call to printk has some sort of effect on timings

In Debug mode, I got this in my kernel log

from can-isotp.

This is really strange! No idea why it misses every second frame on a virtual CAN that not even has a tx queue that might be too small.
Can you please send the output of <ip -det link show vcan0> ?

I've simplified the kernel version dependent stuff and also added the reserved skb space and some debug info in a branch for Linux 4.17+
https://github.com/hartkopp/can-isotp/tree/4.17+

As you are currently using a 4.15 kernel I created an extra branch for you:
https://github.com/hartkopp/can-isotp/tree/4.15py

Can you please try to test this version on your box (without debug output)?
Thanks,
Oliver

from can-isotp.

Output of ip -det link show vcan0 is

3: vcan0: <NOARP,UP,LOWER_UP> mtu 72 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/can promiscuity 0
vcan

I tried your branch 4.15py and made sure that debug was disabled. Seems to have fixed the issue.
I did have to add an include to linux/can/skb.h otherwise I couldn't compile. Compiler complains that struct can_skb_priv is undefined.

I don't really grasp the intent behind your changes, can you briefly explains what you did?

from can-isotp.

Ugh - missed the include in f9fcd45 then, sorry.

The reason behind the skb reserved space can be found in the comments here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/include/linux/can/skb.h

I simply missed to add the skb reserved space handling in the isotp implementation - and additionally the issues you had on your machine never showed up on my setups. Pretty weird.

Will fix the master branch soon. @hfn92 had the same problem here linux-can/can-utils#113 these days - so I wonder why this didn't show up earlier ...

I'll put both of you in the Reported-by: credits then. Thanks!

from can-isotp.

Thanks,
On my side, I really never used an IsoTp socket against a raw socket until last week. So it would be possible that the issue existed for a long time and I didn't notice

from can-isotp.

Yes. The effect occurs, when you access the local 'echoed' CAN frames, which are modified in the reception path. Therefore a connection over 'real' CAN interfaces to other real devices are not affected as the outgoing skb is handled by the CAN driver correctly. So it should only be visible when dumping the outgoing (echo'ed) traffic or on virtual CAN interfaces - which echo'es the CAN frame too.
No idea why I didn't see it on my machine ...

from can-isotp.