So I might have an idea (or at least, a way to reproduce) and I'd like to know if it solves problems for anyone encountering this to set
discovery:
interfaces:
- wlan0
in their config.yaml. You might have to substitute wlan0 with whatever your primary network interface is (check with ifconfig) - probably either wlan0 for wireless or eth0 for wired connection. If this fixes it, I might be able to push out 1.5.1 with a fix contained.
Henrys-MBP-2:Downloads henryhbk$ ping octopi.local
PING octopi.local (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.030 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.038 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.031 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.034 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.033 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.053 ms
^C
--- octopi.local ping statistics ---
9 packets transmitted, 9 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.030/0.037/0.053/0.007 ms
Henrys-MBP-2:Downloads henryhbk$
So all worked fine. Which Is what I expected (since the browser has no problem accessing octoprint via that address)
Oh and other interesting thing:
ssh henryhbk@octopi.local
Warning: Permanently added the ECDSA host key for IP address '192.168.1.55' to the list of known hosts.
So clearly ssh decodes the actual LAN IP address from the .local?
Hi,
Not sure if I can add something of real value since I don’t have the knowledge, but I wanted to let you know I had the exact same thing happen as @audryhome describes in the first post.
I use a Mac running Big Sur
I have two RPI3 with Octoprint on them
After I updated the first to 1.5 and restarted it I had to use IP adress to connect to it.
A week later my other Octoprint (1.42) still worked with the .local adress and after I updated it to 1.5 the exact same thing happened.
I have an app, Lan scanner I think its called, in my Mac that scans the network and after the updates to 1.5 it no longer finds that name (don’t know whats it called). It lists the other stuff like mac adress, vendor and such.
Not sure I have the time but if I do, would my logs help?
You may try to install WSL (Windows Subsystem for Linux). The version 1 is just a Posix emulation over the NT kernel, and it allows you to install your favorite X86-64 Linux distro and install the packages from there. WSL1 may emulate what you need directly over the NT kernel.
WSL2 is "just" a tightly integrated virtual machine. I use it for PrusaSlicer development for Linux and I am very thankful to Microsoft for that option. Running network services under WSL2 will likely not what you want though as the network communication will likely be routed between the virtualized linux and the Windows machine.
Same problem for me since update to 1.5 : no more access to octopi.local while using direct IP it is working.
My desktop OS is windows 7.
But when using octoclient with iPhone on iOS 14 still with the octopi.local it does work.
@bubnikv I in fact tried under WSL2 and ran into issues due to the virtualization. Logging into the VM was easier than trying to see if I could get back a WSL1 console without nuking my WSL2 setup.
@milcent are you also getting 127.0.0.1 as address back when running ping octopi.local?
All in all, I have a fix I think. At least @Spybyte could confirm it works on their end, so I'm going to just hope for the best and roll it out as part of a 1.5.1 hotfix release instead of waiting for more feedback.
Hi Gina,
Made same test.
1st call is OK, exactly the same as you (except octoprint name) from a debian VM
further calls are timed out, including those very tolerant with a timeout of 60 sec.
ping from a debian VM on my Windows machine answer 127.0.0.1
ping from windows itself answer the correct address
Octoprint working as expected, the symptom for me being able to see my Pi Camera in the control tab.
What does this mean?
Could you also try
Yes
Everyone affected by this, please try
as mentioned before. I'm pretty hopeful that it fixes things and is the base of the hotfix I'm currently pushing through final testing.
Hi Gina,
did it, cycle power to be sure
config.yaml is updated, the sequence you proposed
discovery:
interfaces:
- wlan0
It works for the moment, but also worked before....at least this morning.
Using a fresh rasbian lite on a RPI3 connected on LAN
I did another test:
Install dnsutils on both machines (raspberrypi and smallbox)
When I run
dig -p 5353 @224.0.0.251 raspberrypi.local on the small box, 100% return with correct answer
When I run
dig -p 5353 @224.0.0.251 smallbox.local on the raspberrypi, return a timeout.
connected then the fresh rpi via Wifi, same outcome.
So there is something on the octoprint machine that changes the dns behavior.
Another idea?
I've just pushed out 1.5.1. Please switch to that, see if issues persist.
Done
1.5.1 installed, and now the dig command works. proof here:
pi@raspberrypi:~ $ dig -p 5353 @224.0.0.251 smallbox.local
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> -p 5353 @224.0.0.251 smallbox.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52116
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;smallbox.local. IN A
;; ANSWER SECTION:
smallbox.local. 10 IN A 192.168.2.140
;; Query time: 6 msec
;; SERVER: 192.168.2.140#5353(224.0.0.251)
;; WHEN: Fri Dec 04 11:09:50 GMT 2020
;; MSG SIZE rcvd: 48
also find here my octoprint.log file if it helps you
octoprint.log (649.9 KB)
So it's solved for you, I understand this correctly? If so: phew. I hate having to try to fix stuff I can't reproduce 
Many thanks again Gina, I will now update from 1.4.2 to 1.5.1 my other box and see what's happening.
In any case, I will do the follow up, and don't hesitate to ask if you need some experiment, I have a lot of RPIs and other boxes (UDOOs, ODROIDs... ) and will be happy to help.
Just for my curiosity: what did you change?
Kind Regards
Jean
Updated my other box, everything fine so far.
Same behavior as the 1st updated box, no problem
So, that is really strange.
I noticed that the zeroconf service discovery was announcing service entries for all interfaces on the machine, including the loopback device (aka 127.0.0.1). And for some reason which I currently do not understand that made the party responsible for multicast DNS on the machine, avahi, change the host name resolution to 127.0.0.1 in some cases. But I could not get it to do this on my end unless I explicitly limited the announced interfaces to only the loopback device.
In any case, my current fix is to ignore loopback and linklocal interfaces, that seems to have it made to work for those of you affected who reported back so far:
However, I will have to investigate further to figure out what exactly causes things to even go sideways here. The thing is, OctoPrint's zeroconf implementation really only sends packages to a multicast address on the LAN to announce its _octoprint._tcp.local and _http._tcp.local services. At no point does it try to reconfigure name resolution or get in touch with avahi, at least as far as I so far see. So, whatever is happening here, it is a side effect that as far as I so far understood zeroconf should not be possible, yet it happens for some of you. I'll have to dig into the RFCs again and probably also try to make sense of avahi and python-zeroconf's source to have a chance at ever understanding what is happening here.
If you look at my octoprint.log, you'll find an error related to zeroconf. Seems some data supplied to init is not friendly for it, then it complains about it.
the lines:
"2020-12-03 11:09:24,444 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:24:24,446 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:39:24,449 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:54:24,452 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 12:09:24,455 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 12:13:42,696 - octoprint.vendor.zeroconf - WARNING - Choked at offset 0 while unpacking '\n\xba\x10\x00'
2020-12-03 12:13:42,697 - octoprint.vendor.zeroconf - WARNING - Exception occurred:
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/vendor/zeroconf.py", line 655, in init
self.read_header()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/vendor/zeroconf.py", line 680, in read_header
) = self.unpack(b"!6H")
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/vendor/zeroconf.py", line 667, in unpack
info = struct.unpack(format_, self.data[self.offset : self.offset + length])
error: unpack requires a string argument of length 12
"
This happens only in 1.5.0, not in 1.4.2 (beg of file ) nor 1.5.1 last lines. Is there a link?
That looks like something in that zeroconf install was corrupted. However, that has not shown up in other logs.
edit correction, something that zeroconf received maybe?
I will downgrade my other box to 1.5.0 then try again to trap this error.
What do you think?