I used my pi with 1.4 installed and pinged the machine with 1.5. It also resolves the new version with 127.0.0.1.
So i tested this behaviour with a Mac Client (Big Sur) and from a RaspberryPi.
Don't see anything hinting at network issues or similar in your log @Spybyte. So whatever it is we saw in the log from @audryhome, it's not necessarily related.
A reboot would indeed be a good idea, maybe something somewhere hiccuped.
Might also be interesting to see if rolling back to 1.4.2 fixes it again. I really don't know how the upgrade could even do this as - again - the hostname resolution part is OctoPi, not OctoPrint, on OS level and not something I could influence in any way. The only thing I control is the discovery plugin for the service discovery. What those of you affected by this on 1.5.0 could do however, just to rule this out, is disable the discovery plugin, see if that changes behaviour.
So, two things to try here:
- Disable the discovery plugin & restart OctoPrint. See if that changes things, report back on the outcome.
- Downgrade to 1.4.2. See if this changes things, report back on the outcome.
I cannot reproduce this, so I have to rely on people who can to collaborate in analysis.
I'm a developer myself. So I exactly understand that you need these information. I will do as you described. My print will take approx. 1h. After that I will do the first step and come back to you.
1 Like
Hi Gina,
I am connected through wifi, exactly like my other box, same configuration.
I am connected through a Windows 7 Pro PC running chrome.
The weird thing is: this works immediately after boot, able to connect to smallbox.local, then after some time, service is broken.
Looks like a timeout somewhere decided to shut down the service....
Will repeat your test locally and let you know.
Thanks
Jean
Hey Gina,
I did the following steps:
- ping -> 127.0.0.1
- shutdown pi
- ping -> cannot resolve mk3s.lokal: Unknown host
- start pi
- ping -> 127.0.0.1
Next step:
- disabled discovery plugin
- octoprint server didn't respond
- restarted pi
- ping -> 192.168.1.85
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):
- 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?