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 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.
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.
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)
