Hi Francesco,
On 06.01.26 21:39, Francesco Valla wrote:
Hello Harald, Oliver,
On Tue, Jan 06, 2026 at 08:43:42PM +0100, Oliver Hartkopp wrote:
On 06.01.26 17:50, Harald Mommer wrote:
With the plain 'cangen' you are not really flooding the interface, since
you are only sending a random CAN frame every 200ms. The only way I can
reproduce this behaviour in a consistent manner is running from the host:
while true; do cansend vcan0 134#00; done
which seems to generate the maximum amount of traffic.
This is not of course a realistic bus load, but is leading the system
(at least on my setup) to a corner case somewhere.
I have no idea how long the shell needs for a loop, always used cangen -g 0 to
stress the setup which is most probably faster than the shell interpreter, and
sometimes did this for both directions (RX and TX).
Full load is a realistic setup. And even if it was not, if something stopped
working or worse crashes torturing the setup this was a problem.
Yes. cangen -g 0 -i <interface> creates full load - even on real CAN
interfaces. You can also generate fixed content if you want to omit the
generation of randomized content. 'cangen -?' prints a help text.
I agree with both of you - I was simply arguing that a plain 'cangen'
with no parameters is not really loading the interface.
For some reason, I was only able to trigger the unwanted behavior with
cansend in a while loop and not with cangen -g 0, even with fixed ID and
payload. However, I suspect the issue is a matter of timing and
coincidences rather than load level.
Yes, the difference is, that you open a new CAN socket each time with
cansend, while cangen opens one socket and pushes lots of frames into it.
Btw. this should not lead to a stuck CAN interface.
Is the interface usable from another terminal (with cansend/candump) or
how does this 'stuck interface' look like?
Best regards,
Oliver
