OctoPi losing network connection mid-print

Hello @NMe !

Because when you open a new thread, you are asked for some certain information.

Besides you are using a Pi 4B, we do not know nothing about the rest of your setup.
This thread started almost 2 years ago. There have been new OctoPi versions and new OctoPrint versions.
And even the router you use can matter.

Around 6-9 months ago (I think) Raspberry Pi published an update to the WiFi firmware which addressed some of the network crashes that people were seeing, but it was released after the last OctoPi image was created. So if you haven't already run sudo apt update and sudo apt upgrade. It doesn't fix every issue (since there's been a couple people I've spoken to on discord with other disconnect issues) but it has worked for some.

One of the most annoying things about more people jumping in with +1 type comments is that you don't know what they've tried already, or, as experience has shown they have a completely different problem.

1 Like

Because honestly that is all there is to know: I replaced the 3B+ I was using for the past year with a 4B earlier this week because the old one was overheating and I figured I'd just upgrade and invest in cooling for the new model. It's completely freshly installed from an image I flashed five days ago and besides the WiFi settings the only thing I've changed from stock is the camera settings. That, and I turned on native timelapses on my prints.

One thing I can add though: Octoprint was running for multiple days before I got around to doing my first print on the new Pi. It never disconnected, but as soon as I was five minutes into a print it all went down.

And yet this problem persists for dozens of people across these forums, Reddit and other places like Thingiverse. I get what you're trying to say but all the information that could be remotely relevant to the problem is already in this thread.

I would think that's unlikely because the old Pi worked fine on it for over a year.

While I understand that, all that you'll achieve by people asking the same question in a new thread is that people will repeat the same steps as they did in this one without anyone ever coming to an answer which is frustrating for everyone involved. At least in this thread you can assume that I've actually read the entire thing before posting.

Wait, so the image I flashed a few days ago is outdated and has been for half a year? Is this something common? Because that kind of affects how often I need to do a distro upgrade.

I'll give it a go though, I have run apt update but haven't done an apt upgrade just yet. Thanks!

It's not necessarily outdated, there just wasn't anything significantly newer that meant building a new image was necessary. Often Raspberry Pi would release new hardware that needed a new image to work, but that hasn't happened recently. Apt updates are for the most part all that's needed to update it.

The OctoPrint version on the image is kept up to date so that's always current when you download. I think it was in November this year that RPi OS upgraded to Debian 11 (bullseye), and following some adjustments the nightly builds look like they are OK. A new build might be published soon for the Debian bullseye update, but there's a fair bit of testing to go first. They were testing that update for at least 4 months and it still launched with a number of issues, they had to bring back the legacy one for a while and support both.

The issue is not necessarily specific to octopi image, it's the underlying OS. So I assume since you have already read this whole thread that the Network Health plugin did not help your situation in any way and that rebooting your router while it was in that broken state also did not bring it back online?

This is a very frustrating issue that we have. I have been scrounging forums all over the internet looking for a fix.
I seem to be having most of the same issues with losing network connection during a print, seems to be completely random and must be power cycled to re-establish connection.
Things I've tried; red light stays lit after connection issue, Verified sufficient power supply, tried multiple USB cables, keeping the pi cool and monitoring CPU temperature (never above 99*F).
Something odd that I haven't seen mentioned, is that if I disconnect the USB cable between the pi and the printer and print a job from an SD card the pi stays connected to the network without issues.
I'm awaiting an HDMI cable that's on order, hopefully I may be able to monitor what's going on with a monitor connected to the pi.
My Setup;
Rpi4b, Ender 3v2, SKR mini e3v2.

As of last week (Wednesday I think), that's also true for the kernel and bootloader.

I am having the same exact issues on fresh install with raspberry pi B and the newest version of octopi/octoprint.

As one other person mentioned above, which I am surprised no one else mentioned, my work around is to use the octoeverywhere plugin. Strangely enough when my local network can not access octoprint by IP/octopi.local and my router cannot even see the octoprint pi as connected to WIFI, going to octoprint through octoeverywhere will work.

Interesting enough that I know I didn’t do anything to my OctoPi. It looks like the problem disappeared entirely. All I know is my router had firmware update.

Beginning to think the problem may be between Pi and router.

I use AmpliFi Alien as a router

I upgraded my wireless router, problem solved.

Definitely appears to be an issue with the local network between the PI and router.

Good to know. We're one step closer finding the source of problem. I don't know exactly what has fixed in my recent firmware update but it certainly solves the issue with Pi.

Does anyone know what the correlation to this network issue would have to whether or not the pi is plugged into the printer?

Are there any known issues with connecting a pi to a SKR Mini e3 v2? (Maybe some bad feedback)

After much testing I have determined (in my case) the network only disconnects if the pi is actually connected to my printer.

So I am starting to see this problem now. I have the latest version of OctoPrint running on OctoPi with RPi 4B board.

2 hours into a 30+-hour print and the RPi is no longer on the network. It's still printing just fine, thankfully, but I cannot SSH into it (I gave it a static IP address) and it isn't even listed as one of the clients attached to my router. It's as if the wi-fi chip just decided to go offline or something.

It'll work again if I reboot the Pi, but I'll have to wait until this print is done; rebooting mid-print kills the print.

Any ideas?

There are 152 other posts in this thread, with a lot of ideas of how to solve the problem. From upgrading wifi router firmware, to the 'Network Health' plugin there's a lot of options to try to see what might fix it. I appreciate the estimated reading time is 28 minutes but not everything has to be read in full to find some ideas.
Try some of the existing ideas first.

I have 10 raspberry Pis on my network, 4 of them 4Bs and the rest Zero Ws. I have some of the running constantly for months.

None of them, except the octoprint one, drops off the network.

In fact, it was previously doing something else and didnt drop.

Anyone here done a vanilla RPi install and THEN added OctoPrint?

Also, anyone here seeing this issue on wired ethernet?

Im seeing massive errors in the system log that refer to Broadcom Mac :

Feb 18 16:22:51 octopi kernel: [24922.329744] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.329794] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.329839] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.329882] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.329923] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.329964] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330005] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330047] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330088] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330129] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330173] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330214] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.330258] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.331106] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.331809] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
Feb 18 16:22:51 octopi kernel: [24922.331976] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5
sudo modprobe -r brcmfmac

Will remove the wlan0 adapter and stop the errors.... however

sudo modprobe brcmfmac

will not add it back.

It's a bit of a sledgehammer approach, and if the wifi chip/module has frozen or faulted up at a low enough level it's just not enough. This works about 90% of the time for my rpi4, but sometimes it needs an actual power cycle.

This is a software issue. This device has been on my network for literally months before I flashed it to OctoPi.

Firmware looks the same:

Working:

pi@raspberrypi:~ $ ls /lib/firmware/brcm
BCM43430A1.hcd            brcmfmac43242a.bin        brcmfmac43436-sdio.clm_blob  brcmfmac4354-sdio.bin
BCM43430B0.hcd            brcmfmac4329-sdio.bin     brcmfmac43436-sdio.txt       brcmfmac43569.bin
BCM4345C0.hcd             brcmfmac4330-sdio.bin     brcmfmac43436s-sdio.bin      brcmfmac4356-pcie.bin
BCM4345C5.hcd             brcmfmac43340-sdio.bin    brcmfmac43436s-sdio.txt      brcmfmac4356-sdio.bin
bcm43xx-0.fw              brcmfmac4334-sdio.bin     brcmfmac43455-sdio.bin       brcmfmac43570-pcie.bin
bcm43xx_hdr-0.fw          brcmfmac4335-sdio.bin     brcmfmac43455-sdio.clm_blob  brcmfmac4358-pcie.bin
brcmfmac43143.bin         brcmfmac43362-sdio.bin    brcmfmac43455-sdio.txt       brcmfmac43602-pcie.ap.bin
brcmfmac43143-sdio.bin    brcmfmac4339-sdio.bin     brcmfmac43456-sdio.bin       brcmfmac43602-pcie.bin
brcmfmac43236b.bin        brcmfmac43430a0-sdio.bin  brcmfmac43456-sdio.clm_blob  brcmfmac4366b-pcie.bin
brcmfmac43241b0-sdio.bin  brcmfmac43430-sdio.bin    brcmfmac43456-sdio.txt       brcmfmac4371-pcie.bin
brcmfmac43241b4-sdio.bin  brcmfmac43430-sdio.txt    brcmfmac4350c2-pcie.bin      brcmfmac4373.bin
brcmfmac43241b5-sdio.bin  brcmfmac43436-sdio.bin    brcmfmac4350-pcie.bin        brcmfmac4373-sdio.bin
pi@raspberrypi:~ $

Octopi:

root@octopi:/home/pi# ls /lib/firmware/brcm
BCM43430A1.hcd		  brcmfmac43242a.bin	    brcmfmac43436-sdio.clm_blob  brcmfmac4354-sdio.bin
BCM43430B0.hcd		  brcmfmac4329-sdio.bin     brcmfmac43436-sdio.txt	 brcmfmac43569.bin
BCM4345C0.hcd		  brcmfmac4330-sdio.bin     brcmfmac43436s-sdio.bin	 brcmfmac4356-pcie.bin
BCM4345C5.hcd		  brcmfmac43340-sdio.bin    brcmfmac43436s-sdio.txt	 brcmfmac4356-sdio.bin
bcm43xx-0.fw		  brcmfmac4334-sdio.bin     brcmfmac43455-sdio.bin	 brcmfmac43570-pcie.bin
bcm43xx_hdr-0.fw	  brcmfmac4335-sdio.bin     brcmfmac43455-sdio.clm_blob  brcmfmac4358-pcie.bin
brcmfmac43143.bin	  brcmfmac43362-sdio.bin    brcmfmac43455-sdio.txt	 brcmfmac43602-pcie.ap.bin
brcmfmac43143-sdio.bin	  brcmfmac4339-sdio.bin     brcmfmac43456-sdio.bin	 brcmfmac43602-pcie.bin
brcmfmac43236b.bin	  brcmfmac43430a0-sdio.bin  brcmfmac43456-sdio.clm_blob  brcmfmac4366b-pcie.bin
brcmfmac43241b0-sdio.bin  brcmfmac43430-sdio.bin    brcmfmac43456-sdio.txt	 brcmfmac4371-pcie.bin
brcmfmac43241b4-sdio.bin  brcmfmac43430-sdio.txt    brcmfmac4350c2-pcie.bin	 brcmfmac4373.bin
brcmfmac43241b5-sdio.bin  brcmfmac43436-sdio.bin    brcmfmac4350-pcie.bin	 brcmfmac4373-sdio.bin

That would usually be expected - OctoPi is Raspberry Pi OS Lite with OctoPrint pre-installed on it. All the firmware & stuff should be exactly the same. The OctoPi image was originally built early 2021 (now with an updated kernel/bootloader), so it will be a bit different than the current RPi OS images which may have seen updates.

You could try an OctoPi nightly build to test if RPi foundation have fixed the issues recently (the firmware update that was supposed to fix it still has some issues) - the builds are in the RPi imager selection or linked from OctoPrint.org - Download & Setup OctoPrint.

What I am saying is that my existing RPi4s witht he same firmware are rock solid for months.