There is this thread. My initial problem was also, that PrusaSlicer wasn't able to connect to 1.5. So I assume it's the same problem.
My Octoprint instance can reach the internet, this is the way I use the wifi connection to update octoprint from the PI and always making sure my system is updated the same way (apt-get update... ) .
Could it be a side effect with any plugin reaching internet?
I can test again with all my plugins disabled to see if you think it's relevant.
Testing in safe mode could indeed add more data here, could you both try that?
I have this specific issue as well, I reverted to 1.4.2 and the issue is still there. I'm on a Big Sur mac os. I had a lot of the common issues with the 1.5 update and they persist after reverting. I will submit a bug report instead of thread hijacking with the other issues.
Did you reboot after the rollback? If so I think we can rule out this being 1.5.0 specific in your case.
I did a full reboot after with no success. I am going to wipe my server and flash my 1.4.2 image and start fresh but I will post my logs before the reimage to try to help out.
1 Like
SafeMode did not solve the problem. I also set octoprint to safe mode and restarted the pi. Also no success.
Hi @foosel,
another thing I just found out. My OctoPi's name is mk3s.local. If the plugin is disabled, I can ping the server. When I enable the plugin mk3s.local will be resolved to 127.0.0.1. So far nothing new. But with the activated plugin I have a "new" hostname mk3s-2.local which has the proper IP.
So with disabled plugin:
ping mk3s.local -> proper IP
ping mk3s-2.local -> host not found
with enabled plugin:
ping mk3s.local -> 127.0.0.1
ping mk3s-2.local -> proper IP
Maybe this helps.
Can someone please verify this?
Gina,
The network error occurs ONLY with 1.5.0. If you look before starting at beginning of file, when I was starting up 1.4.2 this error never happened.
So the network error happens with 1.5.0 only. I didn't change anything elsewhere between 2 consecutive boots.
@foosel I also am getting an overheat warning since the update so I am going to try some active cooling to see if my pi hardware is causing the issue
I did upgrade again to 1.5.0, then switch the unit off to be sure, then reboot again in safe mode.
Same result, responds as 127.0.0.1, unit only adressable through its IP address
Jean
Keep it on topic please, this is completely unrelated.
I put a fan on it and cooling the hardware allowed me to connect with octopi.local but could be a coincidence.
I was able to use just the IP LAN address (192.168.1.55) rather than the zeroconf IP address which worked fine. So it seems to be related to the zeroconf in some way. But at least the easy workaround of using the LAN address is easy.
Hey,
Could you check if you can ping <your host>–2.local?
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.
1 Like
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.