And the point above is that OctoPi is the same operating system as well. The only difference between OctoPi and Raspberry Pi OS is that OctoPi has OctoPrint and associated apps preconfigured.
If you are still absolutely dead set on this being an OctoPi issue then you should install your OS of choice on the pi, and follow the linux install guide. I suspect you'll still run into these wifi issues intermittently, like several other users of rpi4's, myself included.
Ah awesome, thanks for the clarification that it does happen after a "vanilla" install.
Is this limited to Wifi? I assume so and its tied to the Broadcom failure log entries (brcmfmac: brcmf_sdio_htclk:)
I may see if I can write a script that tail-f's the log and waits for a substantial number of these errors and then saves the last few pages to see if theres something in there that hints as to whats going on
(My 250GB SSD that is running my rig had several dozen Gigs of system log by the time I caught it.)
As far as we know, yes. No one has reported similar issues when using cable connections, only seems to be related to the wifi driver
Awesome, Im going to try catching the system/broadcom logs.
I notice my CPU was throttled... did we get any feedback on folks getting in via ethernet before rebooting and seeing this?
If you have seen this issue, please fill out this poll to help:
You'll probably find more info here: RPi4: WiFi client crashes often (brcmf_fw_crashed: Firmware has halted or crashed) Ā· Issue #3849 Ā· raspberrypi/linux Ā· GitHub
I have this same exact issue. Similar to other users here I am using a Unifi setup, and my controller reports that the device is active and connected... but I can't connect to it unless I force a reconnect from the Unifi controller. This is the only device where I've ever seen a problem like this.
I am also on unifi and using "reconnect" does indeed reconnect the pi. For now I guess I will just use the script provided by @egar
Issue started for me this week after I made a change to my Amplifi HD WiFi Settings. I had disabled 802.11v. Reverting back and will monitor.
If you guys continue to experience this a lot you may want to try the PowerFailure plugin that was recently released, it works for disconnects as well.
Experienced this Toay for the first time 10% into a Print.
It may also have happened yesterday on a couple of occasions too, as I had a couple of retarts while experimenting with things & though the Pi wasn't running.
On all occasions I could not ping it & it wasn't showing up in my Omada Wifi management.
I know it's a Pi issue, not an Octo Print issue, but will still comment on what I changed yesterday that caused the first problem; which at the time I didn't investigate to well.
Just power cycle'd it & then assumed it was fine.
The thing I changed yesterday though, was to enable I2C & installed the Micro Panel Plugin.
Disconnected the Display I bit later as mine was an SSD1106 & not compatible, but left the config unchanged & ordered a compatible screen.
Can't check a lot right now as a 4 hour print is in progress & I have got control back by plugging in an Ethernet cable & logging in thru it's IP.
Will probably end up leaving it wired; not point in going back; just a matter of routing a cable.
Cheers.
If I remember correctly, Ethernet connection will also stop working randomly not just WiFi.
People are saying plugging in Ethernet āwakes upā or ārestart driverā which is an alternative way to get WiFi to revive without having to reboot the Pi.
Latest AmpliFi Alien, I am not sure what fixes the issue. Pi or AmpliFi. It seems mostly stable. Maybe only restart once a year or less.
If Pi hasnāt made new changes to Networking driver, Iām still concerned cuz we all donāt know what exactly is the problem.
I think problem is there are several different issues with similar symptoms, for me the WiFi stack crashes, so Ethernet allows it to connect, Ethernet is not flakey as pis on Ethernet have not been rebooted for years.
It also means the āwakeā up methods donāt work for me as the stack is dead, in theory by removing and reinstalling the dynamic modules for WiFi it could be brought back to life but that is just to much like hard work, easier to reboot.
Lived with this issue fir a couple of years. For me the best solution is the reset button option
Unfortunately not, that just effectively does a stop/start network and fails because the kernel network wifi stack has died in a horrible way. You have to rmmod and then insmod them back in again (according to various forums), but I have never managed to get them to do it in an order that satisfies dependency. It's a known issue. Rebooting is easy.
I do have the network Health plugin for a year or so installed, before that I had the corn version but both fail to restart the network, you can watch it fail when you plug in via ethernet, hence my comment that many similar symptoms but different underlying issues.
I unfortunately don't have any good news to add but I too have been dealing with this issue on and off for a few years but recently it's been getting worse. What happens to me is a combination of things. I leave my server on 24/7 and only turn off the printer. Server is on a pi4 with active cooling. Nothing else running on it. I'll list the two main issues I have been having.
I have ruled out the router (tried multiple routers through the home). Signal strength (for a test moved the printer next to the router). Static/Dynamic IP (this made no difference with the above issues). It's not a bad pi (tried more than one). It's not corruption of the build (formatted and re-installed octoprint multiple times). It's probably not the printer (same issue, I have two printers).
I just want to note that similar issues have been noted in this thread and many other on several forums for a few years. So I believe the issue has yet to be found and may not be wide spread because in some cases it may not be a bug at all. The one thing almost all have in common is a hardline fixes the issue.
But given the lack of fix and similarity of issues among a smaller group of people I am theorizing the issue may have more to do with specific conditions. For example high static, electrical noise from printer/power supply ect.. I plan to do some tests including further isolating the pi and various changes to reduce electrical noise and see what happens. If i find anything significant I'll post my findings.
Well, I have some very interesting data. Please remember this only applies to me and may not directly apply to your situation.
My printer is under a desk that is only used for the printer and storing various stuff. The opening to the underside of the desk is covered by an old bed sheet held on by binder clips. I've had this same setup for a few years, the sheet is meant to keep heat in the area of the printer as I print allot of PETG. The printer is held off the floor by a cheap metal monitor riser. The raspberry pi is also on this metal riser so I didnāt suspect static issues. I am using is a pi4 in an ABS case powered by a homemade power supply(I have experience in electrical design, made it to stop power issues) that can output up-to 5amps at 5v.. The PI is only running octoprint and has no other tasks. I have been having multiple issues related to connections with no idea why they are happening. The WiFi is not far away, the connection strength is always strong. Much of the time the connection will cut out after a print is started. The print will continue and finish just fine but the pi will often not re-connect unless it is rebooted.
What I have learned over the past few weeks of testing. Keep in mind I have already ruled out issues with bad USB cables. I have tried countless.
Test 1: Increase distance between PI and printer by move PI up off the ground by 3 feet, still under desk.
This made no difference.
Test 2: Move the printer and pi to the top of the desk.
This did seem to improve the connection issues and also drastically improve the stuttering issue I was having with the webcam. But loss of connection was still an issue.
Test 3: Move printer back under desk but move PI to top of desk.
I didnāt have much faith in this one especially because I needed to use USB extenders. I was so very wrong. All issues vanished. Itās been almost two weeks with ZERO connection issues and the smoothest webcam stream I have ever seen. I must note there is major difference between the distance from the router if anything itās farther and more blocked off. The PI is also behind my laser printer and some books. Wi-Fi line of sight is worse. So this issue isn't signal strength.
Test 4: Verify findings from Test 3. I moved the PI closer to the ground but still not close to the desk.
Issues came back but not as bad. I did suffer 4 disconnects of 9 prints. Some stuttering on the webcam during this 24hour test.
Test 5: Verify findings from Test 3. Move PI back to location in Test 3 but cover with sheet to see if static or fabric is causing the issue.
Web cam stuttering as bad as before. Connection losses back suffering 2 connection losses in 8 prints.
While none of this is scientific it does have a theme. Static even in places we donāt expect there to be much can cause major issue. The Pi is currently only about 18ā from its previous location but since itās no longer close to the carpet and away from the noisy printer the issues are completely resolved. I have electrical design experience, but I overestimated the ESD resistance of the PI. I think itās possible this may be an unrealized issue for many others too.
Hope this helps someone.
Continuing the discussion from OctoPi losing network connection mid-print:
i'm having the same problem, or at least i tought that until an hour ago...my raspberry pi 4 runs days without any problem accessing it. but as soon as i print something it looses the connection mid print or after print. so i've created a script to check the network connection every 5 minutes. if it fails, it restarts the wifi interface.
what i've learned now, is that the cronjob doesn't even run anymore. it's not only a network problem, it looks like the device gets rebooted in a really strange state.
does anyone experience the same problem? or is this a complete different one?
syslog.log (245.7 KB)
kernel.log (36.0 KB)
octoprint0609.log (99.0 KB)
Does your print continue?
Normally, if just the network connection is lost, the printing is not affected.
If your Pi is rebooting or something, then the print job would be lost, and that's probably a different issue.
true! the printing is not affected. i was only irritated by this line
2023-09-06 09:25:25,197 - octoprint.startup - INFO - Starting OctoPrint 1.9.2
this was after the print was finished. but i have to check the log again, when the connection gets lost mid-print
Stumbled on to this thread while looking for something else (as you do on the interwebs).
Just to add to this, I too have been getting this:
My setup is on an Orange Pi Zero2. Had never experienced this anomaly when running OctoPrint on my Pi4.
Have implemented the script/crontask that @egar posted in this thread - (thank you).
