A fairly new RevPi Core, nicely set up with a good power supply and wired ethernet.
Running really just Node-RED, with a couple of flows generating a heartbeat back to my Home Assistant Odroid, and switching one of the LEDs on/off at the front every 10 seconds so that I know it is still alive.
Problem is that I loose network connection - just vanishes for both Node-RED and the RevPi admin page. Nothing comes back given the IP address. This was happening every couple of days when I first had the device running, so I disabled the TeamViewer app, and it seemed to fix the issue, however it has happened again. To be clear, the RevPi itself is still running - Node-RED still doing things. Just can't get at the device from the network. It has a static IP address set.
Power recycle seems a blunt instrument to fix the issue. I have checked things are up to date, looked at the many reasons given online as to why this happens, tried a few fixes.
If anyone knows anything that would help...
- is this a known issue with the RevPi (or compute module 4) specifically? (clearly it is a known issue with Raspberry Pi generally, but I have one of those connected by WiFi and it runs for months on end without any problem)
- is there an easy way to schedule a machine reboot on the RevPi (blunt instrument reset every day)?
- is there a handy logging approach that I could set up to help monitor and record the network stuff so I could diagnose after the event?
- assuming I have to tie up a monitor and keyboard to be able to poke around 'live' when this next happens, any helpful ideas as to what I should be looking for? I am more familiar with GUI than CLI, so all of this is taking a long time to investigate!
A few pointers would be most welcome.
Thank you!
RevPi Core - drops off network
Re: RevPi Core - drops off network
Hello biscuit,
It's unfortunate that you're experiencing network connectivity issues with your RevPi Core. While it's not a common issue with the RevPi specifically, network problems can be caused by various factors. Here are some suggestions to help you troubleshoot and potentially resolve the issue:
It's unfortunate that you're experiencing network connectivity issues with your RevPi Core. While it's not a common issue with the RevPi specifically, network problems can be caused by various factors. Here are some suggestions to help you troubleshoot and potentially resolve the issue:
- Static IP Configuration:
- Logs:
Code: Select all
cat /var/log/syslog
dmesg | grep eth0
- Network Monitoring:
- Use tools like Wireshark to monitor network traffic. This can help identify any unusual or problematic network behavior.
- Power Supply:
- Update Firmware and Software:
- run a shell script that automatically restart the network
I suppose your TARGET IP address is: 192.168.1.1
Best RegardsCode: Select all
#!/bin/bash TARGET_IP="192.168.1.1" while true; do if ping -c 1 $TARGET_IP > /dev/null 2>&1; then echo "Ethernet connection is active" else echo "Ethernet connection is down, restarting network service" systemctl restart networking fi sleep 60 done
Ulrich Kouatang Biakoup | Technical Support
Re: RevPi Core - drops off network
Well it has died again. Last reboot after tinkering was 14th Feb. Died this morning 3am.
Symptoms:
- Node-RED is still running. One flow is changing the LED, which continues to change so I can see it is still working. Another flow is tracking the heap memory - this continued after 3am.
- Connected monitor shows last GUI. Keyboard and mouse dead, so can't get to see what else is running or what happened.
- Hard power recycle is required to restart.
Checklist.
- static IP. done that, all set, DNS set and all checked (same as my other Raspberry Pi which works fine)
- power supply is the one you use, 24v industrial heavy duty.
- update: done that (first thing - been through the start-up list, checked everything, updated everything)
Checking the logs gets
cat: /var/log/syslog: No such file or directory
After a lot of struggle, I can TigerVNC to the GUI, manage to get to the /var/log directory, find the kernal log, and check around 3:00 this morning.
Mar 1 02:59:54 RevPi96493 kernel: [117371.395646] smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -110
Mar 1 02:59:54 RevPi96493 kernel: [117371.395659] smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
Mar 1 02:59:54 RevPi96493 kernel: [117371.395664] smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
Mar 1 02:59:59 RevPi96493 kernel: [117376.355723] ftdi_sio ttyUSB2: failed to set flow control: -110
Mar 1 03:00:24 RevPi96493 kernel: [117401.475914] ftdi_sio ttyUSB2: failed to set flow control: -110
So problems with the core USB hub, falls over, kills eth0 and keyboard etc.
Causes (Google) are power supply (not a problem here) or other USB devices (USB hubs or USB to serial).
I have an industrial grade powered hub, and three USB to serial devices (RS485, RS232, CANbus). Not using any of them at the moment, just testing the RevPi until this problem goes away. So I guess that one of my USB (serial) devices is killing the USB. The questions are, which one, how long will it take to find this, and what do I replace it with that actually works?
Does anyone have experience of this problem, and was able to find a solution?
Does anyone have successful experience of running USB-serial adaptors on RevPi Core (or connect)?
Symptoms:
- Node-RED is still running. One flow is changing the LED, which continues to change so I can see it is still working. Another flow is tracking the heap memory - this continued after 3am.
- Connected monitor shows last GUI. Keyboard and mouse dead, so can't get to see what else is running or what happened.
- Hard power recycle is required to restart.
Checklist.
- static IP. done that, all set, DNS set and all checked (same as my other Raspberry Pi which works fine)
- power supply is the one you use, 24v industrial heavy duty.
- update: done that (first thing - been through the start-up list, checked everything, updated everything)
Checking the logs gets
cat: /var/log/syslog: No such file or directory
After a lot of struggle, I can TigerVNC to the GUI, manage to get to the /var/log directory, find the kernal log, and check around 3:00 this morning.
Mar 1 02:59:54 RevPi96493 kernel: [117371.395646] smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -110
Mar 1 02:59:54 RevPi96493 kernel: [117371.395659] smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
Mar 1 02:59:54 RevPi96493 kernel: [117371.395664] smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
Mar 1 02:59:59 RevPi96493 kernel: [117376.355723] ftdi_sio ttyUSB2: failed to set flow control: -110
Mar 1 03:00:24 RevPi96493 kernel: [117401.475914] ftdi_sio ttyUSB2: failed to set flow control: -110
So problems with the core USB hub, falls over, kills eth0 and keyboard etc.
Causes (Google) are power supply (not a problem here) or other USB devices (USB hubs or USB to serial).
I have an industrial grade powered hub, and three USB to serial devices (RS485, RS232, CANbus). Not using any of them at the moment, just testing the RevPi until this problem goes away. So I guess that one of my USB (serial) devices is killing the USB. The questions are, which one, how long will it take to find this, and what do I replace it with that actually works?
Does anyone have experience of this problem, and was able to find a solution?
Does anyone have successful experience of running USB-serial adaptors on RevPi Core (or connect)?
Last edited by biscuit on 03 Mar 2024, 11:55, edited 2 times in total.
Re: RevPi Core - drops off network
Update for anyone who reads old posts and is interested in an 'answer'.
Following the last network dropout, I removed just one USB device that I suspected most, the CANbus adapter. The RevPi has been running without incident since, so I am assuming that this was the cause.
Due to the time (and trouble) involved in 'debugging' these problematic USB devices, I am going to abandon this project in favour of another approach.
Following the last network dropout, I removed just one USB device that I suspected most, the CANbus adapter. The RevPi has been running without incident since, so I am assuming that this was the cause.
Due to the time (and trouble) involved in 'debugging' these problematic USB devices, I am going to abandon this project in favour of another approach.