I disabled Discovery and rebooted in Safe Mode. Same symptoms. Network shuts down, printer keeps printing.
Any hints on where to look for WiFi error messages?
I disabled Discovery and rebooted in Safe Mode. Same symptoms. Network shuts down, printer keeps printing.
Any hints on where to look for WiFi error messages?
Whoa... something on your network at 192.168.0.141 and 192.168.0.192 is spamming this poor machine with UPNP discovery requests. That's unusual. Any idea what devices are behind those IP addresses? And considering that for some reason it can't figure out how to reply to them (which will happen if it isn't able to successfully send an UDP datagram to that address from any of its own) - on what network is that instance?
What's interesting is that each of those log floods also coincides with OctoPrint detecting a connectivity change from online to offline. Considering that it still receives UDP messages though that it tries to reply to, I wonder if it is only semi connected? Really odd...
If I were you, I'd first try to figure out what those two devices are (just in case they could be related). And then - ethernet cable and monitoring the wifi reception.
192.168.0.141 is a Windows 10 Professional system that runs my backups and my media center. 192.168.0.192 is my main desktop, also Windows 10 Professional, where I run my slicer(s) and monitor OctoPrint. Both of these machines have been on my network since I first got my printer and OctoPrint. Over a year ago and many, many versions of OctoPrint.
192.168.0.141 does have iTunes so there is Apple software loaded (but not iCloud) and there is an iPad and an iPhone on the network.
I have installed an ethernet wire and OctoPrint and SSH are again happy (as is the printer, happy to be printing again). More research into WiFi will commence post haste.
According to "ifconfig" and "iwconfig", wlan0 is up but does not have an IP address on my network. An "ifdown wlan0" and "ifup wlan0" and its back on my network again.
I'll reboot my access point and see if that helps any.
I rebooted my WiFi access point and everything appears to be back to normal.
I will note that my own instance sometimes lately acts as if it's not responding to its name (Bonjour problems?) so I note that anything that tries to ask-by-hostname just grinds away: ssh, scp, browser, vnc. I've dedicated IP addresses in my Netgear router so I know it's not DHCP lease.
This seems to be a new thing, perhaps two months old at most.
macOS for workstation and there's no Windows anywhere on my network.
Netgear CN3000 and (Netgear) Orbi wi-fi repeaters
v1.3.10, of course
Raspberry Pi 3B and a Robo C2 printer
Using the IP address seems to be a lot happier in these cases.
Note that this is one of those lonnnnnnng-troubleshooting things where I'm watching it to see if it reoccurs. The last thing I did was to modify my /etc/haproxy/haproxy.cfg
in two places:
global
tune.ssl.default-dh-param 2048
...
frontend public
bind *:80
bind 0.0.0.0:443 ssl crt /etc/ssl/snakeoil.pem
In other words, I removed the IPv6 stuff out of there (and I addressed a problem that was showing up in one of the logs which referred to tune.ssl...)
I'm crossing my fingers but I haven't seen the problem since doing this, for what it's worth. No guarantees, though.
I'm reviving this thread as I'm getting the same issue.
Sometimes Octopi stops responding midprint and is not reachable via SSH.
However the print continues perfectly.
Using Octoprint on an Raspberry Pi 4 Model B
OctoPrint Version 1.5.3
OctoPi 0.18.0
I attached the Octoprint Log from the last time this did happen.
octoprint.log.2021-03-10.zip (1.6 MB)
Hello @TheTommynator !
Are you connecting via WiFi? If yes, some routers have a power save function for WiFi. It may have been activated.
I'm connecting via WiFi.
But the OctoPi appears as offline in the router then when it freezes.
And a print job is continuing?
Yes! The print job did finish normal.
Restarting the router didn't help reconnecting.
Are you connecting via IP or via http://octopi.local
?
Tried both of them and didn't get any response on both ways.
After restarting the OctoPi everything works normal until it randomly crashes and doesn't respond.
Have you tried in safe mode?
This is most likely due to the DHCP lease expiring. OctoPi hasn't crashed, its just that the WiFi doesn't have a valid IP address. The RPi is supposed to renew the lease when it expires but for some reason, it does not.
One solution is to assign a static IP address to the RPi.
Have to try that still.
Difficult to test it because it happens so randomly.
We have a similar thread going on here - OctoPi losing network connection mid-print
No answers to the problem yet, but the info there may be helpful in tracking down the source of the issue.
So right now OctoPi again stopped responding during print. The print is still going on but the OctoPi is unreachable.
I assigned a static IP address and started it in safe mode. Still no luck though...
If your problem is network connectivity (and this sounds 100% like it is) then safe mode won't help you. Since you assigned a static IP it isn't DHCP leases either. Next step is testing with an ethernet cable. If that works, something's making your Pi get kicked off the network.
Want to mention second bug (not first time I've seen that problem, had to power cycle).
There are two separate bugs:
[#1] wlan0 would be down, egar had a great script solution (restart network service if it's down)
[#2] wlan0 would be permanent down, not even egar's script would fix it (see screenshot)