I did, no answer.
I also apparently solved the problem by connecting directly with LAN (dhcp), then editing the /etc/wpa_supplicant/wpa_supplicant.conf to erase the wifi passwd, then rebooting (same outcome) then reestablishing the password then rebooting again in wifi and IT SEEMS TO WORKS NOW.
Would be interested if you can do the same and check the outcome.....
Will test all the day with a octoprint.log monitoring through tail -f ~.octoprint/logs/.... and will report if any issue.
I've created a ticket for this on the bug tracker:
Currently can't make heads nor tails off of it and still can't reproduce. Will see what I can do about the latter today.
I at least now figured out how to do manual mdns queries to check what actually gets reported back on the DNS level.
Here's what I'm currently seeing using dig:
gina@nuc-ubuntu:~$ dig -p 5353 @224.0.0.251 octopia.local
; <<>> DiG 9.16.1-Ubuntu <<>> -p 5353 @224.0.0.251 octopia.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: 51998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;octopia.local. IN A
;; ANSWER SECTION:
octopiA.local. 10 IN A 192.168.1.184
;; Query time: 240 msec
;; SERVER: 192.168.1.184#5353(224.0.0.251)
;; WHEN: Do Dez 03 15:42:45 CET 2020
;; MSG SIZE rcvd: 55
gina@nuc-ubuntu:~$ dig -p 5353 @224.0.0.251 octopib.local
; <<>> DiG 9.16.1-Ubuntu <<>> -p 5353 @224.0.0.251 octopib.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: 18004
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;octopib.local. IN A
;; ANSWER SECTION:
octopiB.local. 10 IN A 192.168.1.153
;; Query time: 168 msec
;; SERVER: 192.168.1.153#5353(224.0.0.251)
;; WHEN: Do Dez 03 15:42:49 CET 2020
;; MSG SIZE rcvd: 55
I could not get it to work on windows sadly, this was on an Ubuntu VM I had lying around, but it will work on a Pi too, after an apt update && apt install dnsutils. If anyone encountering this could run dig -p 5353 @224.0.0.251 octopi.local (or whatever hostname it is you are trying to resolve) from a separate machine to the one causing trouble, that might give us some more hints.
As you can see, I still cannot reproduce this at all. Both hostnames resolve correctly, not to 127.0.0.1. octopia is the same OctoPrint 1.5.0/OctoPi 0.17.0 instance from yesterday, octopib the same OctoPrint 1.5.0/OctoPi 0.18.0rc1 instance but with disabled discovery plugin (though that did not change anything here either).
I found a solution that worked for me. I wrote it down in the ticket. But I reverted the config and tried dig.
dig -p 5353 @224.0.0.251 mk3s.local
; <<>> DiG 9.10.6 <<>> -p 5353 @224.0.0.251 mk3s.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: 30250
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mk3s.local. IN A
;; ANSWER SECTION:
openhab-lan.local. 3600 IN A 192.168.1.251
;; Query time: 32 msec
;; SERVER: 192.168.1.251#5353(224.0.0.251)
;; WHEN: Thu Dec 03 16:04:47 CET 2020
;; MSG SIZE rcvd: 56
It looks strange, because of the answer section. This is a total different IP (it's my server for home automatisation). On the other hand, the result is the same with the configuration that works for me.
Consider me even more confused now. I'm starting to think there might be some caching going on somewhere.
Saw your answer, still have to compare that to things here. It's all very mysterious I gotta say, and the fact that I cannot for the life of me get it to break on my end doesn't make it easier either.
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