naugehyde

I'll be interested to see if others can recreate the problem on different hardware and different canboat connections. I have a waveshare CAN hat rig that I'll try later today....

One stopgap solution against any plugin (not just rpi-monitor) that's doing whatever rpi-monitor is doing and causing CAN0 to go down is to set the "noDataReceivedTimeout" suboption for the connection...

Thanks, that's interesting. FYI rpi-monitor spawns system shells and executes system calls (mpstat etc) to get its data. It's possible one or more of the commands is blocking the CAN...

The config is the vanilla config prescribed by the manufacturer: auto can0 iface can0 inet manual pre-up /sbin/ip link set can0 type can bitrate 250000 up /sbin/ifconfig can0 up down...

Excellent! Thank you. Will give this a go ASAP and let you know. On Mon, Sep 18, 2023 at 7:29 AM Matti Airas ***@***.***> wrote: > I recommend adding "restart-ms...

FYI the bug is easily recreated by setting rpi-monitor's interval to 1s. I'm not near my boat today and can only connect to it over 2G so it may take...

Before CAN0 failure: 4: can0: mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 link/can promiscuity 0 minmtu 0 maxmtu 0 can state ERROR-ACTIVE restart-ms 0 bitrate...

Yes. Something is stalling the RX at the canboatjs level (socketcan functions normally throughout) and causing a timeout that fails silently. The offending plugin that triggered all of this (rpi-monitor)...

Thanks for the code. Will put it to use soon. If it's a resource issue owing to the overhead of frequent shell creation, Nodejs's garbage collection cycle could be running...

I agree that the RX buffers on the MCP2515 _may_ be insufficient for some scenarios. In a large harbor like mine (Marina Del Rey) the N2K stream is flooded with...