Paraphraser
commented
2 years ago Let's work backwards. I'm going to assume a Bullseye 64-bit installation using PiBuilder. Please let me know if your setup is different.
The first thing to check is:
$ tail -5 /etc/dhcpcd.conf
# patch needed for IOTstack - stops RPi freezing during boot.
# see https://github.com/SensorsIot/IOTstack/issues/219
# see https://github.com/SensorsIot/IOTstack/issues/253
allowinterfaces eth*,wlan*What that does is tells the DHCP client running in the Pi to only consider Ethernet and WiFi interfaces as candidates for dynamic address allocation. Without that in place, all the veth interfaces that Docker sets up when you bring up your stack also try to participate in something Docker is already doing. That can have knock-on effects at boot time (system stalls) or during network transients.
The second thing to check is:
$ grep "isc-dhcp-fix.sh" /etc/rc.local
/usr/bin/isc-dhcp-fix.sh eth0 wlan0 &Notice the "eth0" and "wlan0" arguments. That reflects the fact that my Pi has both of those interfaces active so both of them are being "kept alive" by the isc-dhcp-fix.sh script. It's important to realise that this line is setup by PiBuilder at install time. It isn't dynamic so if, for example, Ethernet wasn't "there" at PiBuilder time but WiFi was then that line will only have "wlan0" in it.
In other words, you should make sure that the interfaces provided as arguments on that line reflect what you actually need in practice.
The third thing to check is whether isc-dhcp-fix.sh is firing. The easiest way to do that is:
$ grep -a "isc-dhcp-fix" /var/log/syslogRemember that syslog rotates. For Buster and earlier that was every 24 hours. For Bullseye and later, it's every week (but there's a PiBuilder tutorial in how to put it back to 24 hours). The point is getting silence from that grep can mean either:
isc-dhcp-fix.shis present and firing but no interfaces have bounced since the last log rotation; orisc-dhcp-fix.shis either not installed, or is installed but not firing.
To make sure it is there:
pi@sec-dev:~$ cat /usr/bin/isc-dhcp-fix.sh
#!/bin/bash
logger "isc-dhcp-fix launched"
while [ $# -gt 0 ] ; do
for CARD in $@ ; do
ifconfig "$CARD" | grep -Po '(?<=inet )[\d.]+' &> /dev/null
if [ $? != 0 ]; then
logger "isc-dhcp-fix resetting $CARD"
ifconfig "$CARD" up
sleep 5
fi
sleep 1
done
sleep 1
doneTo make sure it can be run:
$ sudo /usr/bin/isc-dhcp-fix.sh eth0 wlan0Unless you get an error (eg no execute permission) you'll probably get silence. Wait about 10 seconds and then hit control+C, then run the grep again. You should at least get the "launched" message.
After any reboot, I generally get this triple:
Jun 11 14:25:58 sec-dev root: isc-dhcp-fix launched
Jun 11 14:25:58 sec-dev root: isc-dhcp-fix resetting eth0
Jun 11 14:26:04 sec-dev root: isc-dhcp-fix resetting wlan0Now I'll make a different assumption which is the interface arguments in /etc/rc.local are correct, that isc-dhcp-fix.sh is firing properly, and a grep of the log produces a ton of "resetting" messages.
If that's the case then I'd start to divide and conquer. If I had Ethernet but WiFi was being problematic, I'd probably disable WiFi for a while and see if Ethernet was more robust.
If Ethernet was flaky then I'd change my Ethernet cable to see if it influenced the behaviour. Then I'd try a different switch port or perhaps a totally different switch.
If I came to suspect the Raspberry Pi Ethernet port itself, I'd invert the problem by enabling WiFi and disabling the Ethernet port. If the problem persisted I'd then start to worry about what else might be going on inside the Pi.
For the record, I've got four Pi4s (one Buster, three Bullseye), all 4GB RAM running on SSDs, all dual Ethernet and WiFi, all built with PiBuilder. I do see occasional "resetting wlan0" messages (maybe one a week across all four machines) but, except at boot time or when there's an obvious explanation (like pulling out an Ethernet cable) it's very very rare for me to see a "resetting eth0" message.
To make the claim in the previous paragraph more "evidence" than "anecdote", I just grabbed all the logs from all four machines. That's the last 7 days plus the current day on each machine: 32 log files in total. I found 24 hits, all from my test Pi, all were the "triples" characteristic of a reboot (example above). The test machine is something I reboot all the time so that makes sense. The other three I rarely reboot so the only reasonable inference is isc-dhcp-fix.sh isn't firing because Ethernet and WiFi aren't bouncing.
While n=4 doesn't really prove all that much, it does at least demonstrate that the combination of Pi 4 + PiBuilder doesn't always result in network interface problems.
The last point I'll make is that, if you're seeing "resetting" messages when you run grep, those are just evidence of the script sensing that an interface has gone down. They are written to the log with logger so that you can open the log and search for them, then look to see what else is writing messages into the log that might guide you to the underlying problem. You also get a timestamp so you can cross-correlate with other files in the log directory, or logs kept by other devices on your network.
Hope something in all of the above helps you track down and nail this problem.
BlueWings172
Hello
My Raspberry Pi 4b randomly becomes inaccessible in LAN.
I have posted this issue months ago in the IOTstack page and and it I was suggested to use Pi Builder.
So I finally found the time to back my data up and give Pi Builder a try. The few first days were eventless but unfortunately then the Pi started disappearing from the network and becomes inaccessible several times a day which renders my setup completely useless. This happens regardless if the Pi is connect via WIFI or Ethernet. This is a real bummer because I've spent so much time trying to learn and implement new things. I'm using a brand new SD card.
I would appreciate any help.
Thanks