Octopi loses network connection after being fine for hours

rjp23 · April 17, 2020, 8:06pm

I've had Octopi running fine and printing for 10+ hours but it suddenly loses network connection so I can't login to it (either via web-browswer at octopi.local or via SSH).

As I can't access it, I can't (yet) post any logs.

It's still continuing to print fine so I don't want to do a hard reset on it until the print finishes. I assume withoiut being able to connect, there's no way to force it to reconnect to the network?

OutsourcedGuru · April 17, 2020, 8:25pm

Let it print and hope for the best.

When it's finished, you might:

plug in an Ethernet cable and see if you can suddenly connect to it
plug in a keyboard/mouse/monitor, log in and run an ifconfig
visit your network router to see if it's short-leased the IP address, issuing a different one

rjp23 · April 17, 2020, 8:47pm

It turns out that why octopi.local has stopped working, I can access it directly via the IP address. Does that suggest some kind of bonjour issue or something?

I'm on a mac and octopi is running on a rasperberry pi 3b.

octooprint.log just says

2020-04-17 15:05:50,609 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 15:20:50,612 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 15:35:50,615 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 15:50:50,618 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 16:05:50,621 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 16:20:50,627 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 16:35:50,630 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 16:50:50,635 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 17:05:50,638 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 17:20:50,640 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 17:35:50,641 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 17:50:50,646 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 18:05:50,651 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 18:20:50,652 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 18:35:50,655 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 18:50:50,656 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 19:05:50,658 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 19:20:50,662 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 19:35:50,667 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 19:50:50,681 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 20:05:50,688 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 20:20:50,691 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 20:35:50,695 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 20:40:12,581 - octoprint.server.util.sockjs - INFO - Client connection closed: fe80::41e:400d:4ef5:fdfa
2020-04-17 20:50:50,697 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 21:05:50,700 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 21:20:50,706 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-04-17 21:35:50,710 - octoprint.server.heartbeat - INFO - Server heartbeat <3

rjp23 · April 17, 2020, 8:53pm

There's also a LOT of this in the syslog

Apr 17 20:47:32 octopi kernel: [35323.201652] br-4423851514ca: port 1(veth13b8fe3) entered disabled state
Apr 17 20:47:32 octopi dhcpcd[526]: veth13b8fe3: removing interface
Apr 17 20:47:32 octopi systemd[1]: run-docker-netns-d8f2ba9d20f7.mount: Succeeded.
Apr 17 20:47:32 octopi systemd[1]: var-lib-docker-containers-d69ea97c5b53aa7d0b6a2263ec78a65e627e17813b9aca2f28546acc0bda4d04-mounts-shm.mount$
Apr 17 20:47:32 octopi systemd[1]: var-lib-docker-overlay2-6c842a1c05c651a16709c52dd4bc8f0dcf87d1b56466608cac6823509ef682e6-merged.mount: Succ$
Apr 17 20:47:32 octopi dhcpcd[526]: br-4423851514ca: using IPv4LL address 169.254.69.70
Apr 17 20:47:32 octopi avahi-daemon[292]: Registering new address record for 169.254.69.70 on br-4423851514ca.IPv4.
Apr 17 20:47:32 octopi dhcpcd[526]: br-4423851514ca: adding route to 169.254.0.0/16
Apr 17 20:47:33 octopi dhcpcd[526]: br-4423851514ca: carrier lost
Apr 17 20:47:33 octopi dhcpcd[526]: br-4423851514ca: deleting address fe80::6c56:64bb:80b1:742d
Apr 17 20:47:33 octopi avahi-daemon[292]: Withdrawing address record for fe80::6c56:64bb:80b1:742d on br-4423851514ca.
Apr 17 20:47:33 octopi avahi-daemon[292]: Leaving mDNS multicast group on interface br-4423851514ca.IPv6 with address fe80::6c56:64bb:80b1:742$
Apr 17 20:47:33 octopi avahi-daemon[292]: Interface br-4423851514ca.IPv6 no longer relevant for mDNS.
Apr 17 20:47:33 octopi avahi-daemon[292]: Withdrawing address record for 169.254.69.70 on br-4423851514ca.
Apr 17 20:47:33 octopi dhcpcd[526]: br-4423851514ca: deleting route to 169.254.0.0/16
Apr 17 20:48:32 octopi kernel: [35382.843685] br-4423851514ca: port 1(veth3f30c7f) entered blocking state
Apr 17 20:48:32 octopi kernel: [35382.843701] br-4423851514ca: port 1(veth3f30c7f) entered disabled state
Apr 17 20:48:32 octopi kernel: [35382.844295] device veth3f30c7f entered promiscuous mode
Apr 17 20:48:32 octopi kernel: [35382.844958] IPv6: ADDRCONF(NETDEV_UP): veth3f30c7f: link is not ready
Apr 17 20:48:32 octopi dhcpcd[526]: veth038ab0a: waiting for carrier
Apr 17 20:48:32 octopi kernel: [35382.953414] IPv6: ADDRCONF(NETDEV_UP): veth038ab0a: link is not ready
Apr 17 20:48:32 octopi kernel: [35382.953438] IPv6: ADDRCONF(NETDEV_CHANGE): veth038ab0a: link becomes ready
Apr 17 20:48:32 octopi kernel: [35382.953544] IPv6: ADDRCONF(NETDEV_CHANGE): veth3f30c7f: link becomes ready
Apr 17 20:48:32 octopi kernel: [35382.953609] br-4423851514ca: port 1(veth3f30c7f) entered blocking state
Apr 17 20:48:32 octopi kernel: [35382.953614] br-4423851514ca: port 1(veth3f30c7f) entered forwarding state
Apr 17 20:48:32 octopi dhcpcd[526]: veth3f30c7f: IAID 17:89:55:dd
Apr 17 20:48:32 octopi dhcpcd[526]: veth3f30c7f: adding address fe80::2615:c1ee:322f:ca94
Apr 17 20:48:32 octopi dhcpcd[526]: veth038ab0a: carrier acquired

OutsourcedGuru · April 17, 2020, 9:46pm

This indicates that earlier your MacBook resolved octopi.local into an IPv6-based address and used that. So then you suggest that you then lost this connection (client to server) so it's possible that something changed for the IPv6 information or the broadcast address related to octopi.local during this period of time. Or maybe the MacBook cleared its arp cache during that same period.

Alright, so you've got something on your Pi which uses Docker. Did you install anything other than the flashed OctoPi IMG file?

rjp23 · April 17, 2020, 9:59pm

It's literally just octopi installed on the pi.

I've changed the setting on my router to set the IP address rather than allowing DHCP to see if hard-coding that helps to solve it.

OutsourcedGuru · April 17, 2020, 11:06pm

I dunno but something doesn't seem right with the syslog that's shown. Did you go into raspi-config -> Network and change anything there?

5ft24 · April 18, 2020, 8:35am

I've always had issues when the RPI was running with IPV6 enabled. If you log into the pi and do "sudo nano /boot/cmdline.txt
And at the very end of the line add "ipv6.disable=1"
Do not press enter!!!
do a CTRL X then Y and reboot

Roc4k · April 23, 2020, 4:30am

I do the updates when they come but I have had this running for quite a long time!

ChristophD · April 17, 2021, 2:17pm

I had spent weeks trying to debug network connection loss issues on my RPi 3B+ and what finally solved it for me were doing three things at the same time:

Setting a static IP address
Disabling WLAN power management
Disabling IPv6 as mentioned by 5ft24 earlier in the thread

Since then I haven't had a single issue with the network connection.