Am 06.05.21 um 23:28 schrieb Bartosz Zdanowicz: >> Can you create a candump log from vcan0 to see, what's going on the bus? >> > On RPI after first send I got > pi@raspberrypi:~ $ candump can0 > can0 002 [8] 10 09 41 41 41 41 41 41 > > After the second message I got mentioned OSError and there is no data > on candump. Sending again I received next frame: > pi@raspberrypi:~ $ candump can0 > can0 002 [8] 10 09 41 41 41 41 41 41 > can0 002 [8] 10 09 41 41 41 41 41 41 > > On my local PC where I get no system Error I got one frame per every send: > bartosz ~/Work/DeltaThermal/can-isotp master candump vcan0 > vcan0 002 [8] 10 09 41 41 41 41 41 41 > vcan0 002 [8] 10 09 41 41 41 41 41 41 > vcan0 002 [8] 10 09 41 41 41 41 41 41 > vcan0 002 [8] 10 09 41 41 41 41 41 41 > vcan0 002 [8] 10 09 41 41 41 41 41 41 > vcan0 002 [8] 10 09 41 41 41 41 41 41 >> >> ... >> So how is Python getting this information? >> > In general, that's the biggest issue for me. Because in my real > application I'm using python select() and recv() on that socket. When > this error is raised, my select() on socket deduce something is > received and recv() function also throws an error. I just tried to get > a minimal example that reproduces the issue which is above. In those > cases I would expect timeout, not OSError. As expected, timeout error on missing flow control. Since it's tx side it just tells -ECOMM instead of -ETIMEDOUT . https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L10 https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L755 Is there a specific reason why you use select.select() instead of Socket.recv(timeout) / Socket.send() ? Best Regards, Patrick
