I had the same problem. The I restarted my pi and it worked. Did you try to restart and ping it afterwards?
Yes, it works for some time, then fall back to 127.0.0.1.
I did what Gina suggested and it worked perfectly as before in 1.4.2.
This tells me something in 1.5.0 is breaking the stuff.... but what?
Look at my log as I suggested. I have an exception in zeroconf.py only in 1.5.0, not in 1.4.2.
Hope it helps
octoprint.log (522.7 KB)
It also doesn't seem to be related to the Python version:
Jean's version: Detected environment is Python 2.7.16 under Linux (linux2)
My version: Detected environment is Python 3.7.3 under Linux (linux)
Björn
That it not even resolves to anything anymore when you disable the plugin sounds very strange indeed, because as I said, name resolution isn't handled by that, only the service announcements. I'll see if I can reproduce this.
In the meantime, just to summarize what we so far know (even though right now I have no idea at all how to even begin to debug this):
- The symptom is that the
.localdomain resolves to 127.0.0.1 - It is related to something in 1.5.0 as the issue goes away when rolling back to 1.4.2.
- For @Spybyte it can be fixed by disabling the discovery plugin (which was switched from
pybonjourtopython-zeroconfin 1.5.0 and takes care of service discovery (not hostname resolution)). For @audryhome, disabling said plugin however does not change behaviour - For @audryhome, there's also a network error during initialization of the discovery plugin and a negative connection check, hinting at some issue there
- The issue is unrelated to Python 2 vs 3 (which is good to know because Python 2 uses a vendored version of
python-zeroconf) - Both of you run OctoPi 0.17.0
So far I'm not yet seeing any real pattern here, apart from OctoPi 0.17.0, and I'd expect a lot more people to chime in here if that was a general issue with that and 1.5.0.
@audryhome What I'm seeing in your log is that the connectivity check also fails right after your exception, and then stays negative on the following startup:
020-12-01 13:44:28,476 - 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 2237, in send
bytes_sent = s.sendto(packet, 0, (addr, port))
error: [Errno 101] Network is unreachable
2020-12-01 13:46:00,663 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-01 13:46:07,061 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity changed from online to offline
2020-12-01 13:46:07,062 - octoprint.util.connectivity.connectivity_checker - INFO - Connecting to 8.8.8.8:53 is not working
2020-12-01 13:46:07,063 - octoprint.util.connectivity.connectivity_checker - INFO - Resolving octoprint.org is not working
2020-12-01 13:54:12,221 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.2.42
2020-12-01 13:34:09,097 - octoprint.startup - INFO - ******************************************************************************
2020-12-01 13:34:09,099 - octoprint.startup - INFO - Starting OctoPrint 1.5.0
2020-12-01 13:34:09,100 - octoprint.startup - INFO - ******************************************************************************
2020-12-01 13:34:15,914 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity state is currently: offline
2020-12-01 13:34:15,915 - octoprint.util.connectivity.connectivity_checker - INFO - Connecting to 8.8.8.8:53 is not working
2020-12-01 13:34:15,918 - octoprint.util.connectivity.connectivity_checker - INFO - Resolving octoprint.org is not working
Can your OctoPrint instance reach the internet? Because it is telling me it can't. We should rule out that something funky is going on with your network connection here causing both the mdns name resolution and the connection issue - the loss of internet connectivity could indicate some routing problem.
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?