Octopi.local Not Responding

Get Help Networking
1

What is the problem?

"All of a sudden" octoprint will no longer respond using octopi.local, but it will respond to it's static IP address. I have used this Pi setup for years, always using octopi.local to connect. One day, something changed. Sometimes, the Pi would answer to octopi.local, sometimes it wouldn't. Sometimes rebooting my computer or the router or the Pi itself would help, sometimes it wouldn't. Now, it will NEVER connect using octopi.local. I've just lived with it, so I'm not sure what changed around that time. I've since probably upgraded Ubuntu and octoprint both.

What did you already try to solve it?

I tried threatening it, but that didn't help ¯\_(ツ)_/¯

I have tried using multiple browsers, but octopi.local isn't responsive through 'ping' either, so...

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog... no bundle, no support, unless the reason you couldn't retrieve the bundle is your network issues

octoprint-systeminfo-20240306012611.zip (94.7 KB)

Additional information about your setup

Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ... as much data as possible

I am connecting FROM a Dell Latitide e7450 laptop running Ubuntu 22.04 LTS THROUGH a Linksys E5350 Wi-Fi Router running Firmware Version 1.0.00 build 32 TO octoprint Version 1.9.2 running on a Raspberry Pi Model B Revision 2.

2

Does just octopi (without the .local) work as hostname?

3

No. When I tried that, Firefox automatically tried to do a search on it instead. So I used http://octopi and got the same "Hmm. We’re having trouble finding that site" error. Just for giggles, I tried both http://octopi.local and https://octopi.local and get the same error.

4

The name octopi.local is a Bonjour feature and requires support within your local network.

The name octopi will only resolve if your local network includes a DNS server. A DNS server can be (but doesn't have to be) provided by the same system that provides a DHCP server.

I don't believe it just "quit working". More likely an update / upgrade / hardware change caused the issue and "sometimes rebooting would help" is more likely "changing the order of rebooting".

First you need to identify if / where your DNS and DHCP servers are running. On the RPi with the name of octopi, provide the output of 'ifconfig' and 'cat /etc/resolv.conf'. Run the same commands on the laptop. Connect to the web interface on the Linksys router and look at DHCP and/or DNS configuration.

5

Since this is a long winded post, let me thank you up front for your reply!

Oh, yeah... That was what I was getting at. I just meant that, at the time, which was so long ago, I wasn't paying close enough attention to everything to know WHICH variable changed.

I've provided the ifconfig and resolv.conf results below, but... Since you mention DNS and DHCP, I need to clarify something. So... the router that I am connecting to here - the Linksys - is only acting as a switch and wireless connection. On the Linksys, DHCP is disabled.

Screenshot from 2024-03-06 12-15-42

I notice, though, that in the ifconfig of the Pi, the DNS server is set to 192.168.1.254, which is the address of the main AT&T u-verse modem/router.

Subnets & DHCP 2024-03-06
Subnets & DHCP 2024-03-061600×1967 217 KB

This has been the setup ever since I began using octoprint, years ago. The Linksys IS a new router, but I don't remember if that was before or after these issues.

ifconfig (on Pi):

eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:a4:0d:6d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 292100 bytes 1336719629 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 292100 bytes 1336719629 (1.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.80 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::bc29:367d:ec2e:3496 prefixlen 64 scopeid 0x20
inet6 2600:1702:1670:860::45 prefixlen 128 scopeid 0x0
inet6 2600:1702:1670:860:4dc:956e:bf0c:3b84 prefixlen 64 scopeid 0x0
ether b8:27:eb:f1:58:38 txqueuelen 1000 (Ethernet)
RX packets 588052 bytes 78444347 (74.8 MiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 1011472 bytes 1393984330 (1.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

cat /etc/resolv.conf (on Pi):

Generated by resolvconf

domain attlocal.net
nameserver 192.168.1.254
nameserver 2600:1702:1670:860::1

ifconfig (on laptop):

eno1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 20:47:47:a8:7a:07 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7200000-f7220000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 515060 bytes 385584110 (385.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 515060 bytes 385584110 (385.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wgpia0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 10.15.186.154 netmask 255.255.255.255 destination 10.15.186.154
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 9827623 bytes 12767360680 (12.7 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5950998 bytes 727458968 (727.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.1.255
ether 5c:e0:c5:65:ef:d7 txqueuelen 1000 (Ethernet)
RX packets 30815918 bytes 36664550201 (36.6 GB)
RX errors 0 dropped 239709 overruns 0 frame 0
TX packets 16707286 bytes 8410795328 (8.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

cat /etc/resolv.conf (on laptop):

nameserver 127.0.0.53
options edns0 trust-ad
search .

6

The laptop isn't using the same DNS server as the RPi. If it was, then I believe that octopi.attlocal.net would be the name you would use to connect it and octopi would probably work as well.

The laptop DNS could be configured to use 192.168.1.254 as its upstream DNS server but we don't have enough information to determine that yet.

Please provide the output of dig octopi, dig octopi.attlocal.net, and nslookup octopi on both the RPi and the laptop. If dig and/or nslookup don't exist, `sudo apt install dnsutils' should work on the RPi and maybe the laptop too.

The laptop appears to have a static IP address. If you changed it to DHCP then everything might just work.

BTW, I'm assuming that the WAN port on the Linksys is not being used, i.e. you have configured it as an Access Point.

7

I can't think of / remember a reason that I configured the laptop with a static IP, other than the fact that I needed to do that to the other systems on the network, so... I suppose I could try changing that to dynamic.

Correct.

dig octopi (on Pi):

; <<>> DiG 9.11.5-P4-5.1+deb10u10-Raspbian <<>> octopi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61734
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;octopi. IN A

;; ANSWER SECTION:
octopi. 0 IN A 192.168.1.80

;; Query time: 47 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Mar 07 00:02:47 GMT 2024
;; MSG SIZE rcvd: 51

dig octopi.attlocal.net (on Pi):

; <<>> DiG 9.11.5-P4-5.1+deb10u10-Raspbian <<>> octopi.attlocal.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59819
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;octopi.attlocal.net. IN A

;; ANSWER SECTION:
octopi.attlocal.net. 0 IN A 192.168.1.80

;; Query time: 48 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Mar 07 00:03:58 GMT 2024
;; MSG SIZE rcvd: 64

nslookup octopi (on Pi):

Server: 192.168.1.254
Address: 192.168.1.254#53

Name: octopi.attlocal.net
Address: 192.168.1.80
Name: octopi.attlocal.net
Address: 2600:1702:1670:860::45
Name: octopi.attlocal.net
Address: 2600:1702:1670:860:4dc:956e:bf0c:3b84
Name: octopi.attlocal.net
Address: fe80::bc29:367d:ec2e:3496

dig octopi (on laptop):

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> octopi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5403
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;octopi. IN A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Mar 06 18:04:53 CST 2024
;; MSG SIZE rcvd: 35

dig octopi.attlocal.net (on laptop):

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> octopi.attlocal.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36607
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;octopi.attlocal.net. IN A

;; Query time: 180 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Mar 06 18:05:31 CST 2024
;; MSG SIZE rcvd: 48

nslookup octopi (on laptop):

Server: 127.0.0.53
Address: 127.0.0.53#53

** server can't find octopi: SERVFAIL

8

I think I may have found the issue. Under Static IP on the laptop, for some reason I was using 1.1.1.1 and 1.0.0.1 as the DNS servers. I don't remember my logic behind that at the time, but when I deleted that - still retaining the static IP configuration - I can now access the Pi through octopi.local.

Hopefully it will continue working. I really appreciate all of your help!

3 Likes
9

Aaah that makes sense

Glad you got it working :tentacle:

1 Like
10

Octo Pi only response to http://. NOT Secure. https://
rule out any dns issues by using the ip on you network.
Crome now requires https://
use a browser that does force everything to https://

or over ride in the browser settings.

11

Yeah... I did find that, for some reason, DNS on the laptop was set to 1.1.1.1 instead of my local 192.168.1.254 for the router. Once I changed that, it started working. Thank you. I appreciate the reply.

12

do you mean :
"use a browser that doesN'T force everything to https://"
??

1 Like
13

Correct does NOT force to https://

14

Periodically (couple months or problems) you should clear your DNS cache.
Go to a CMD prompt and run "ipconfig /flushdns".

-JC

15

forget DNS or trying to use static IP addresses. Use the address http://127.0.0.1, and it will connect all the time. Works for me. This is the loopback ip address on all systems.

16

I tried that on both firefox and brave. Brave says that it cannot connect. Firefox says the same thing and auto"corrects" http to https.

17

That only works if OctoPrint runs on the same system as the browser.

1 Like
18

I thought that's what they were talking about. You are correct, 127.0.0.1 is the local loopback address for Octoprint running on the same machine. If Octoprint is running on a separate machine, I have always used the IP address of the PI and not relied on a DNS lookup. Accessing Octoprint via the PI's IP address has always worked for me.

The first thing I do when I install Octoprint is to set up a static IP address for the PI. There are plenty of turorials on the web on how to do this.

I have an IP plan I keep on an Excel spreadsheet with IP ranges for particular devices (for example: 192.168.0.20-30 is for desktop computers, 192.168.0.31-40 is for misc devices, like Octoprint).

I currently have a version of Octoprint running on a Pi 4B with a local 7" display (I am going to rebuild it with a 10" display) and use Chromium on the Pi to control Octoprint locally. I then use the local loopback address to access Octoprint.

19

try using your pi ip or try connecting it to a network becuase sometimes the pi dosent connect to the network