OctoPi losing network connection mid-print

Get Help Networking
61

I have setup my Octopi to use static IP address so this is no longer part of the problem. I can confirm from router logs and from octopi logs that DHCP leases are no longer performed.

What I have from my router log for the last disconnect:

Mar 6 16:04:52 wlceventd: wlceventd_proc_event(526): eth4: Auth DC:A6:32:C0:09:DB, status: Successful (0), rssi:0
Mar 6 16:04:52 wlceventd: wlceventd_proc_event(507): eth5: Disassoc DC:A6:32:C0:09:DB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 6 16:04:52 wlceventd: wlceventd_proc_event(507): eth5: Disassoc DC:A6:32:C0:09:DB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 6 16:04:52 wlceventd: wlceventd_proc_event(536): eth4: ReAssoc DC:A6:32:C0:09:DB, status: Successful (0), rssi:0
Mar 6 16:05:17 wlceventd: wlceventd_proc_event(490): eth4: Deauth_ind DC:A6:32:C0:09:DB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

At the same time, the octoprint.log displays these messages:

2021-03-06 16:03:11,367 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 1794}
2021-03-06 16:03:47,285 - octoprint.plugins.octopod - INFO - Could not load image from url
2021-03-06 16:07:03,882 - octoprint.plugins.octopod - INFO - Could not load image from url
2021-03-06 16:07:23,915 - octoprint.plugins.octopod - WARNING - Could not send message: HTTPConnectionPool(host='octopodprint.com', port=80): Max retries exceeded with url: //v1/push_printer (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xa80432b0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))
2021-03-06 16:07:43,942 - octoprint.plugins.octopod - INFO - Could not send Silent job message: HTTPConnectionPool(host='octopodprint.com', port=80): Max retries exceeded with url: //v1/push_printer (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xa7fffe50>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')) State: Printing

It appears that the Octopi stopped communicating with the router and after a few failures, the router dropped the connection. Then without the connection, Octoprint could no longer communicate with the outside world.

A reboot of the Octopi will reestablish the connection. Rebooting the router may do that same but have not tried that due to the disruptive effect it has on the rest of the network connected devices.

I have tried disabling plugins installed in the few days before this issue started, but still had the failures. I'm now considering disabling all plugins and testing for a few days to see if it is something that was added.

62

reply is "Power save: off"

Earlier I upgraded to the latest nightly build 1.0.0. Same result about one hour into the print.
However I remembered having read that restarting the router fixes the issue. So I tried that and since then the pi stayed connected.
I do think now, that it has something to do with the wifi connection and how it communicates with the router. Not that this helps...

63

I'm pretty sure it hase nothing to do with any plugins. My Octoprint is out of the box. Only have the PSU plugin enabled as I've got a relay on the printers power line. And still same issue.

64

I decided to test this. I changed DHCP lease time renewal from 24 hours to 15 minutes. I let it run its course for 3 days; it did renew 288 times without failure.

Clearly, not a DHCP lease issue. It's something else.

egar, thanks for the log. My log has the same initial communication failure as yours. I don't know which other log to look at to find the specific cause.

Is it truly Pi 4 that's having that symptom? Pi 3 and prior don't have that problem?

65

I have this problem with a pi 3b+

66

No, Pi 3b+ here, too.

67

I MIGHT have found the cause for the disruptions.
Two days ago I fiddled with my router and, among other things, found, that it has a feature to scan the surrounding network. There are dozens of wifi networks in the vicinity. No surprise there as I live in a densly populated area. Anyways, I turned on a function, that switches channel based on usage by other routers. Since then I did not have any more disconnects!

1 Like
68

I went just over a week with no disconnects. I thought I had unknowingly solved by problem, but it is back. Last two print attempts, the Octopi dropped from the network. The first one in less than 15 minutes after starting up the Octopi and beginning a print. The second time it failed in about an hour.

The only thing this is telling me it is not uptime or print duration related. It can happen quickly after startup. But, it only happens during printing.

69

I think @NilsH may be onto something... I have a (free) app on my (Android) phone called WiFi Analyzer. There are multiple apps available for both Android and iOS so you should be able to find one.

When I run this app, it displays a graph of all the WiFi nodes it can see on a graph with channel number on the x-axis and signal strength on the y-axis. If your phone is near your printer, make sure that "your" WiFi signal is the strongest one and its on a different channel than the next strongest one(s).

Many WiFi servers default to channel 6 (in the US) so that is usually the most crowded channel. Channels 1-2 and 11+ are far enough away from 6 that there shouldn't be any interference.

During printing, the RPi is busier handling USB serial traffic and may not respond to WiFi traffic (especially retransmissions) as quickly as when it is idle.

Let us know what you discover.

70

I don't know if raspberry foundation fixed the issues with HDMI connected with 1080p and Channel 1 wifi or not, so you may want to avoid that one.

71

I'm using channel 11 and have no WiFi issues at all. I do have a stronger signal from someone else's WiFi on channel 6 and I have an RPi 3B so 5MHz is not an option for me.

In addition to the OctoPi that runs my LulzBot TAZ 6, I have over 20 other devices active on 2.4MHz (including a second RPi 3B). I have an RPi 3B+ but it is currently wired.

72

My Octopi is in my basement and near the router. If I do a wireless survey in the basement, the only Wifi the Octopi can see is my router. The router is using only channels not used by my neighbors, so I doubt (in my case) that it is wifi channel based.

I found some info on the web where others are having some similar problems and have borrowed from other's scripts to run a job every 5 minutes to check on the wireless LAN connection. If it finds it dropped the script will reset the interface and log an event. Running my first print job with this script in place. If it works, I'll post instructions here.

73

Add me to the list of people having this issue. The RPi stops responding to network requests, but the print is continuing.....crossing fingers I'm 31hours into a 36 hour print. After this print finishes, I'll try the disabling of power saving change. Also I have a RPi 4 and this has happened a few times now.

74

Update on my script to monitor the wifi connection --

I printed for about 7 hours yesterday and did not have any disconnects. The script to reset the interface never needed to execute. I'm uncertain if I just did not experience the intermittent failure or if the first part of the script that pings my router every 5 minutes is keeping the connection alive.

More testing will be needed to determine if the problem still occurs and if so, will the interface reset recover the connection. I've got success and failure logs being written from the script, so I'll be able to determine if it happens again. Stay tuned...

75

well, after many days of my newest pi4 being online with no issues I went to connect to it today and it's disconnected from the network.

In my case now, the pi is still showing an ip address assigned, and it is able to ping the router, but another client on the same network cannot ping the pi.

76

For what it's worth. I'm having the same issues. The Pi can stay up for several days and then seems to inconsistently lose WiFi during a print job. The good news is that the print job is unaffected and completes normally (including one that ran for 42 hours after I lost comms).

I checked the router and the Pi is registered ok to DHCP, but will not respond to a Ping. I tried changing routers and that hasn't seemed to have made any difference in behaviour. Only a power cycle reset restores the comms.

The reset of the network devices are running properly, including two WEMO switches that I use to control the Pi and the printer.

browser.user_agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36 Edg/89.0.774.54
connectivity.connection_check : 8.8.8.8:53
connectivity.connection_ok : true
connectivity.enabled : true
connectivity.online : true
connectivity.resolution_check : octoprint.org
connectivity.resolution_ok : true
env.hardware.cores : 4
env.hardware.freq : 1500
env.hardware.ram : 3959300096
env.os.bits : 32
env.os.id : linux
env.os.platform : linux
env.plugins.pi_support.model : Raspberry Pi 4 Model B Rev 1.2
env.plugins.pi_support.octopi_version : 0.18.0
env.plugins.pi_support.throttle_state : 0x0
env.python.pip : 20.2.4
env.python.version : 3.7.3
env.python.virtualenv : true
octoprint.safe_mode : false
octoprint.version : 1.5.3

77

How do we reach out to developers about this matter? I think it’s beyond our scope. I doubt it’s something we can do.

Likely network component or Raspian OS (based on Debian Linux).

Where can we raise a ticket?

78

I'd start in the Raspberry Pi Forums which you can find starting at https://www.raspberrypi.org/

79

My Octopi has now been up 5 days since I put in my script to monitor for a failed network connection. During that time, I have 37 hours of printing. No network failures have occurred.

I suspect that the cron job that pings my router every 5 minutes is keeping the network connection alive. Although I don't know why the failure was happening, I'm going to call this problem done (for now). I seem to have an effective workaround in place.

If anyone is interested. Here is my script and the crontab setup. This isn't all original work, I borrowed pieces from a lot of other's work I found on Raspberry and Linux forums.

Script - I called it netcheck.sh

#!/bin/bash

# Set variables

NOW=$(date +"%m-%d-%y %r")
IFACE='wlan0'
PINGIP='192.168.50.1'
LOG_PATH="/var/log/network.log"

# Ping remote IP and reset interface if needed

echo "$NOW - Run Check" >> $LOG_PATH

/bin/ping -c 2 -I $IFACE $PINGIP > /dev/null 2> /dev/null

if [ $? != 0 ] ; then
    echo "$NOW Network is down - RESET" >> $LOG_PATH
    ip link set dev $IFACE down
    sleep 5
    ip link set dev $IFACE up
fi

Crontab entry

*/5 * * * * /home/pi/scripts/netcheck.sh > /dev/null 2>&1
80

Hi all,

I've also been (and probably still am) struggling with this issue. Same symptoms as most of you have described.

I am currently experimenting with the the octoprint settings "Serial Connections -> Intervals & timeouts": Have anyone else tinkered with this as a potential fix to this problem?

I have generally increased all timeouts in one go, and so far it looks promising (although too ealy to celebrate anything). I just wanted to throw it out there in case the idea makes sense to any of you. I'll update again here once it fails, or in a week or so if it's stable.

Here's a cope of my settings (sorry for the messy copy):
Query intervals
Temperature interval (polling)
5s When printing or idle
2s When idle and a target temperature is set
Temperature interval (autoreport)
2s Autoreport interval to request from firmware
SD status interval (polling)
1s When printing from the printer's SD
SD status interval (autoreport)
1s Autoreport interval to request from firmware
Timeouts
Communication timeout
120s busy protocol support not detected
10s busy protocol support detected
Connection timeout
60s
Autodetection timeout
30s First handshake attempt
3s Consecutive handshake attempts
Position query timeout
10s
Advanced options
Initial baudrate detection pause
1s
Some controllers need a bit of a breather before baudrate detection after initial connect. If baudrate detection fails due to a hanging controller, try increasing this value.
Max. consecutive timeouts while idle
0 Set to 0 to disable consecutive timeout detection and handling.
Max. consecutive timeouts while printing
0 Set to 0 to disable consecutive timeout detection and handling.
Max. consecutive timeouts during long running commands
0 Set to 0 to disable consecutive timeout detection and handling.