Hey Gina,
I did the following steps:
Next step:
So for what ever reason disabling the discovery plugin "solved" this problem. Somehow it's related to it.
Should I still downgrade to 1.4.2?
What can I do to narrow this problem further?
Ok, a downgrade is not needed for further tests then, but just in case, here's the FAQ entry on that:
Also linked in every single release and release candidate announcement btw 
So it IS the switch to python-zeroconf or something in the adaptation of the code of the Discovery plugin to it. Huh... That is going to be a tough nut to crack, I have absolutely no idea right now how to even approach this.
Hi again Gina,
When disabling the discovery plugin, the unit is completely unknown on the network, doesn't even respond as 127.0.0.1.
When reverting to 1.4.2, works like a charm....
So obviously something weird happens when updating.
If you look at my logs, the following sequence is related to zeroconf:
2020-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
This happens only in 1.5.0, my logfile is also referring to 1.4.2 that I upgraded yesterday....
Is it related?
Many thanks
Jean
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):
.local domain resolves to 127.0.0.1pybonjour to python-zeroconf in 1.5.0 and takes care of service discovery (not hostname resolution)). For @audryhome, disabling said plugin however does not change behaviourpython-zeroconf)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.
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.