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
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.
I noticed that the zeroconf service discovery was announcing service entries for all interfaces on the machine, including the loopback device (aka 127.0.0.1). And for some reason which I currently do not understand that made the party responsible for multicast DNS on the machine, avahi, change the host name resolution to 127.0.0.1 in some cases. But I could not get it to do this on my end unless I explicitly limited the announced interfaces to only the loopback device.
In any case, my current fix is to ignore loopback and linklocal interfaces, that seems to have it made to work for those of you affected who reported back so far:
However, I will have to investigate further to figure out what exactly causes things to even go sideways here. The thing is, OctoPrint's zeroconf implementation really only sends packages to a multicast address on the LAN to announce its _octoprint._tcp.local and _http._tcp.local services. At no point does it try to reconfigure name resolution or get in touch with avahi, at least as far as I so far see. So, whatever is happening here, it is a side effect that as far as I so far understood zeroconf should not be possible, yet it happens for some of you. I'll have to dig into the RFCs again and probably also try to make sense of avahi and python-zeroconf's source to have a chance at ever understanding what is happening here.
If you look at my octoprint.log, you'll find an error related to zeroconf. Seems some data supplied to init is not friendly for it, then it complains about it.
the lines:
"2020-12-03 11:09:24,444 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:24:24,446 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:39:24,449 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 11:54:24,452 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 12:09:24,455 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-12-03 12:13:42,696 - octoprint.vendor.zeroconf - WARNING - Choked at offset 0 while unpacking '\n\xba\x10\x00'
2020-12-03 12:13:42,697 - 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 655, in init
self.read_header()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/vendor/zeroconf.py", line 680, in read_header
) = self.unpack(b"!6H")
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/vendor/zeroconf.py", line 667, in unpack
info = struct.unpack(format_, self.data[self.offset : self.offset + length])
error: unpack requires a string argument of length 12
"
This happens only in 1.5.0, not in 1.4.2 (beg of file ) nor 1.5.1 last lines. Is there a link?
I don't think it's related tbh, or it would have shown up in the logs from @Spybyte and also in my own when I rigged my setup to force the issue to show up.
I know this thread is kind of old, but I have Octoprint 1.6.1 and I'm getting the same error unless I disable the discovery plugin, which is bad. I have Windows 10 on my PC, a Raspberry Pi 3 b+, and this issue is very annoying. Some please help! I see that supposedly 1.5.1 solved it, but it appears to be back.
I asm having the same issue with a Raspberry Pi 3A+, I have tried to install Octopi 0.18 with Octoprint 1.8.4 (build 20220927151125) multiple times via Raspberry Pi Imager.
I was just never able to connect via the hostname on my laptop with Windows 10 Pro, very annoying. I think it might be a windows problem as I can connect via my Android phone when on the same wifi network.
This is my workaround for now:
On the machine that you are ssh'ing from (say, your "laptop" or whatever), put an entry in the /etc/hosts files (for Unix/Linux/Mac, it is /etc/hosts. On Windows, it is C:\windows\system32\drivers\etc\hosts), associating the IP address with a name. Then you can use that name in future. This always works, but the annoyance is that you have to do it on each machine that you want to be able to ssh from.
ik this is an old thread but i recently had this issue too but my case was becase i tried setting the hostname from the raspberry pi imager when at first installing octoprint. i just got a new micro SD card, reinstalled a fresh octoprint OS without setting hostname, and it worked fine
you can also create a backup of the existing octoprint before switching the SD card, this will keep most of your setting and webcam and also will backup existing files on the local Raspberry Pi
I was using a raspberry Pi 4 Model B with the Ender3V3SE
