I've seen similar issues on my RPi 4. My wireless router is a Netgear R6900 and sometimes I just lose connectivity to the Pi, even though everything else (such as TouchUI on a locally connected HDMI screen) keeps working fine. Turning off WiFi power saving by adding
iwconfig wlan0 power off
to the end of /etc/rc.local (before the exit 0 line) seems to make it occur less often, but it does still happen on occasion.
Rebooting the router makes the connection come back.
I started this thread and still don't have a resolution... I'm pleased to have company in this misery, but I wish someone knew the cause.
I had a failure over the last few days that I attribute to a corrupted SD card. This morning I did a fresh flash on a new card, configured OctoPi, and started a new print. While viewing the camera on OctoPod and standing next to my printer, I lost all connectivity. I can't ping OctoPi. I can't see what's going on with the printer, but the print continues, apparently unaware of any problems.
OctoPi is a custom packaging of Raspbian Lite. I believe this is an operating system networking issue and this forum doesn't have any members with the right expertise to resolve this issue.
I suggest that everyone having this problem move to the Raspberry Pi forums and report the issue against Raspbian Lite instead of OctoPi. Feel free to post a link to that discussion here.
Mine seems to be a ip lease time - time out.
I am brand new to any Pi stuff.
I just had this happen in the middle of a 4 hour print for the first time. (i have been running the newest octopi version with a pi4 2gig for about 2 weeks with a camera on for monitoring, this is the first time the printer had been left on for more than a few hours).
I noticed that it was about 24 hours since i had turned on the machine the day prior.
ok so here is the skinny
printer was on for a long time, mostly idle end of job waiting on me.
started a new print job 1/2 way done
monitoring remotely via w10 desktop / firefox
page goes dead / server offline.
panic
tried a few times to get back in / nada
google
saw this post where above poster said that once wifi router was rebooted connection came back
rebooted my ap
bingo back on line
so...
restarting the pi via menu should fix this, granted this would have to be done prior to loosing the connection.
i do not know how to make this happen, other than doing it manually before starting a print, and certainly you cant restart the pi in the middle of a job.
But there has to be a way to script a poll for a new ip lease, cell phones do it all the time.
Like i said earlier i don't know pi, but i know for sure that the pi does not go "offline", its still doing its thing, but because the ip lease has timed out there is no connection back to it.
This is also why someone said that while this is happening, if you plug in a lan cable it restarts the wifi connection as well because the pi now has a new lease.
If anyone knows how to script this or knows of a plug in for OCTOPRINT this is your hint.
Just to add to the list, I've started getting these issues mid print on a Pi4 as well, to the point where I can't even ping it. Prints keep going though, without fail.
Takes a reboot and sometimes have to remove the usb connection to the CR10s ProV2 to get it to connect via browser again.
Not network related as it was fine for some months and signal is super strong.
One thing though, I did install Octoprint MQTT plugin on the pi to start hooking it up to my OpenHAB recently, and on thinking back, maybe that's the common denominator when it started. It's possible I effed up some setting there, but it did seem ok'ish at least for a few days after, I think...
In the middle of a 28hr print so when it's finished, I'll try removing the plugin and see if it behaves again.
Another thing of note, since the problem started, the video feed has become far more 'janky' until it stops working completely...so something might be flooding the network.
So I disabled MQTT plugin and it seems to be responding right through the first print.
That's not to say it's the MQTT plugins fault, as I may have changed a few settings that caused issues.
Will do some more investigation and report back.
EDIT: Nope, network died on the second print again, so it's not related to the MQTT plugin being enabled.
Will continue to try whittling it down.
EDIT2: FYI, found this https://www.raspberrypi.org/forums/viewtopic.php?t=247783
...and trying out the first temp fix for turning off power save, as noted above by @tinfoilsoldier
EDIT3: My issue seemed to be a blend of the power saving, as well as a local Asus router issue (kernel errors in log). Found I could still ping (after power fix) from other servers around the house, so at least my issue with regard to Raspbian OS/Octoprint is considered ok now.
Just to upvote this, I've started experiencing the same behavior. Fairly new installation of OctoPi flashed from the latest stable image to a Pi3B. Only plugins are OctoLapse and the Dashboard. I think the DHCP lease renewal is a good clue and will be checking to see if that is a possible cause.
Update: I've also confirmed that connecting the physical ethernet cable not only restores connectivity via the wire but also restores the WiFi connection.
Another update: I assigned a static IP to the WiFi interface which seemed to work for a few days but once again the Pi went offline during a print. It didn't interfere with the print but lost all WiFi connectivity. As before, plugging the physical ethernet cable in activated the WLAN port. I even saw the WLAN port go down with the ethernet cable connected. To bring it back I disconnected and then reconnected the ethernet cable. Very strange indeed.
I am new to the Octopi seen however I am coming up with the disconnecting from Wifi octoprint.log (447.9 KB)
I would love some help
your log indicates an issue downloading the latest update and installing it. based on some of the errors it appears as if it's losing it's network connection altogether. you might get better results with the octopi 0.18rc2 release. This will flash a more recent version of OctoPrint out of the box, and potentially resolve and SD card corruption that may or may not exist in your install.
So I would need to uninstall the current pi to then reinstall
you could try to SSH to the pi and do system updates to see if it helps. the trick is we need to know when it's lost its connection is it able to be accessed via ssh? Do you happen to be using an ASUS router to connect to for wifi? There's a setting that has been identified that can cause issues with pi.
Subscribing ;).
Running Pi 4B, dual fans, heatsinks, etc. Have tape on the USB 5V pin, etc.
Everything about the Pi works - prints continue to run after Wifi goes down - but the wifi problem is super annoying.
So far I have had positive results by running a kernel update with the following commands. It has been stable for me for 3 days. I can not guarantee that this won't cause other unexpected results because it upgrades the base kernel drivers to "latest" instead of "stable".
sudo rpi-update
sudo apt update
sudo apt upgrade
I experienced that problem after 8-16 hours from powering on. Apparently, when DHCP lease expires, Pi goes into limbo. To trigger force DHCP renewal is to reboot router, Pi will reconnect and refresh DHCP. Problem will recur regardless.
Around 4 days ago, I saw someone suggestion to try OctoPi 0.18 RC2. I erased my SD card and put the RC2 (release candidate 2) and restored my backup configuration. It's now 4th day, it hasn't even lose connection. My faith has been restored.
Screen from my terminal:
Give it a try.
Yes, that's why I went ahead with OctoPi reinstall with next build rather than breaking anything using sudo apt update. So far the 0.18 RC2 is good to me in term of network connection.
They do mention there are issues to be ironed out but I've looked at their issues, none of them apply what I do. All is good.
OctoPi 0.18 was released stable just under month ago, though there were no changes from RC2 -> stable release.
Yes, this really makes sense. After using 0.18.0, it's broken. I'm now using 0.18.x RC2 which works the best.
That's a little strange, because what Charlie was saying is that they are functionally the same. 0.18rc2 became 0.18 stable with no changes.
Just want to let you know this build (RC2) just finally experienced that symptom again - the only difference was... happened on 7th day (assuming that's my duration of DHCP lease as per defined by my router) rather than happening everyday.
Strange enough, if you assign static IP for it, it still needs to be refreshed every time DHCP lease expires?