Octopi drops off the wireless network, sporadically, won't reconnect

What is the problem?

Basic problem: Wireless network connection is lost by Pi and it never regains it. Connection via name or IP does not work.

What did you already try to solve it?

Turned off wifi power save, both in /etc/rc.local (which is deprecated I hear) and cron job at reboot to turn off wlan0 power save.
When this wireless disconnect happens, I can access the pi only if I run an ethernet cable to it. Then, miraculously, both connections are active. However if the ethernet connection is removed, the wireless connection somehow deactivates. When ethernet is active, I can ping either IP address successfully. I can also ping via the hostname. When wired ethernet is removed, I cannot access the pi via the wireless IP, or the pi's hostname which is octorpi4.local

Ping when no wired ethernet, from laptop

% ping 192.168.40.210
PING 192.168.40.210 (192.168.40.210): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C

/etc/resolv.conf is not used by a mac. Below is the correct command for finding dns on a mac. *.119 is pihole, *.1 is the router.

% scutil --dns
DNS configuration (for scoped queries)

resolver #1
  search domain[0] : lan
  nameserver[0] : 192.168.40.119
  nameserver[1] : 192.168.40.1
  if_index : 15 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)
pi@octorpi4:~ $ cat /etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 192.168.40.1
pi@octorpi4:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.40.1    0.0.0.0         UG    202    0        0 eth0
default         192.168.40.1    0.0.0.0         UG    303    0        0 wlan0
192.168.40.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.40.0    0.0.0.0         255.255.255.0   U     303    0        0 wlan0
pi@octorpi4:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.40.216  netmask 255.255.255.0  broadcast 192.168.40.255
        inet6 fe80::5b3:1d1:f5b5:f412  prefixlen 64  scopeid 0x20<link>
        inet6 fd25:5c48:ff7a:2abf:adfc:c2a6:a26:a47e  prefixlen 64  scopeid 0x0<global>
        ether d8:3a:dd:2d:94:01  txqueuelen 1000  (Ethernet)
        RX packets 33600  bytes 8829836 (8.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12871  bytes 2846036 (2.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 15260459  bytes 149844684327 (139.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15260459  bytes 149844684327 (139.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.40.210  netmask 255.255.255.0  broadcast 192.168.40.255
        inet6 fe80::4e3:2548:f9a9:8fd7  prefixlen 64  scopeid 0x20<link>
        ether d8:3a:dd:2d:94:04  txqueuelen 1000  (Ethernet)
        RX packets 15217981  bytes 1385045963 (1.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 111075812  bytes 1780343302 (1.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Have you tried running in safe mode?

No

Did running in safe mode solve the problem?

Didn't try

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog... no bundle, no support, unless the reason you couldn't retrieve the bundle is your network issues

octoprint-systeminfo-20240516095629.zip (15.8 KB)

Additional information about your setup

Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ... as much data as possible

Google Nest WiFi Pro mesh router. Main node is connected to ethernet switch. Pi-hole on network to minimize ads. Router forwards DNS traffic to pihole. Works flawlessly. Wired and wireless devices are all on the same subnet. Laptop is a Mac running Sonoma 14.4.1, latest non beta OS. RPI4 boots from SSD disk attached to USB3. Not using the microSD card.

Having an ethernet cord run though a hallway across doorways is a safety hazard, especially in the evening. Not viable, except for testing. I've tried many "solutions", yet this Pi (and many of the other Pi's I have) just randomly drop off the network. It's quite frustrating. I don't think it's unique to OctoPi, but many of the Pi's suffer from a similar disease. My print server would go off the air a lot, fixed that by using ethernet, along with pihole. My sprinker controller running OpenSprinklerPi constantly disconnects, with exactly the same symptoms. Anyways, I'm here asking about Octopi. Any tips or guidance on this would be gratefully accepted.

You might want to edit octopi.txt in the boot partition and enable the network watchdog at the bottom. Set the IP to monitor to your router's IP address. The other option is installing the Network Health plugin.

Thanks, @jneilliii I will try the watchdog option. If that doesn't work, then I'll try the plugin.

Seems to have survived a reboot. I hope this works. Can you tell me what was done for this monitoring and network restart? I'd love to make something similar for my other Pi's. Is this similar to a cron job that periodically pings the network and if successful does nothing, but upon failure restarts networking?

On this version of the OS, what is the appropriate networking command? Been through so many changes, services, systemd, whatever, it's hard to keep track of what is being used these days. What is OctoPi using?

Well within the time of this post, the unit dropped off the air. It pinged fine after it's reboot, and the server came up. Now it is unresponsive on the web page and unresolvable via hostname. But I can ping it's IP address still. 192.168.40.210

% ping octorpi4.local
ping: cannot resolve octorpi4.local: Unknown host
% ping 192.168.40.210
PING 192.168.40.210 (192.168.40.210): 56 data bytes
64 bytes from 192.168.40.210: icmp_seq=0 ttl=64 time=7.152 ms
64 bytes from 192.168.40.210: icmp_seq=1 ttl=64 time=16.793 ms
...

I can ssh into the IP address. OctoPrint says I can log into http://octorpi4.local or http://192.168.40.210
Now I am running without ethernet and on wlan0 only, but name resolving seems weird on my system.

pi@octorpi4:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether d8:3a:dd:2d:94:01  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 922  bytes 2473431 (2.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 922  bytes 2473431 (2.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.40.210  netmask 255.255.255.0  broadcast 192.168.40.255
        inet6 fe80::4e3:2548:f9a9:8fd7  prefixlen 64  scopeid 0x20<link>
        ether d8:3a:dd:2d:94:04  txqueuelen 1000  (Ethernet)
        RX packets 5218  bytes 6572179 (6.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1171  bytes 1057584 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Perplexed. OctoPrint Connects fine using the IP, not the hostname, at least as of right now. Probably be different in 20 minutes.

There's a couple of PRs that were related to the network watchdog.

I have seen reports of strange things with mesh networks, so that might be what you are running into. That doesn't necessarily mean anything specific to OctoPi, but the underlying Raspberry Pi OS.

As I mentioned in my initial post, I don't think this is unique to Octopi, but more related to Pi in general. Of course, if wireless networking was perfect, I doubt those additions for network monitoring would have made it into the code base. Pi's have had funky wireless for a while, even with network dongles. My RPI2 with a wireless dongle drops off the network like its going out of style.

Not sure if these issues are a result of my mesh network or not. The mesh UI that is exposed these days is practically useless. The UI's are so dumbed down there practically no diagnostics that can be done. My router has no adjustment for dhcp lease time, for instance. The old routers was far harder to set up, but you could change things. This one, there's very little that can be altered.

Strangely, things are working, via name again. I added the pihole ip under resolv.conf, before my router ip and rebooted. But it seems resolv.conf got overwritten and is just for my router. Tough to keep up with the "new ways". Especially when the old ways flood the searches - and they are obsolete.

Ok, edited /etc/dhcpcd.conf and added pihole, then my router ip. The restarted dhcpcd service via

pi@octorpi4:/etc $ sudo systemctl restart dhcpcd.service

Then checked that /etc/resolv.conf was updated.

pi@octorpi4:/etc $ cat /etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 192.168.40.119
nameserver 192.168.40.1

I'm hoping that will help.