lathiat
drill fails with "Error: error sending query: Could not send or receive, because of network error" on the FreeBSD CI
I got to the point where I ran all the smoke tests on the FreeBSD CI (with duct tape and popsicle sticks for now). They all pass apart from https://github.com/avahi/avahi/blob/30a32db559741db95db7d7dccdcb5c3fc359ed90/.github/workflows/smoke-tests.sh#L86-L89
drill fails there with Error: error sending query: Could not send or receive, because of network error.
My first guess was that it was blocked by the firewall there but having taken a quick look at the logs it doesn't seem firewalls of any kind are turned on there. Either way it needs looking into.
I get the same error when running on my laptop. It feels like the command waits for a reply from some service, but which one?
The first command tries to make sure that avahi can reply to basic legacy unicast queries with its own hostname via the loopback interface and services aren't even involved when
drill "@127.0.0.1" -p5353 $(hostname).local ANY
is run. Is there any chance you can collect packets going over the loopback interface when it happens to see whether there are replies from avahi at all? It should be something like
19:59:53.489615 IP 127.0.0.1.48573 > 127.0.0.1.mdns: 47386+ ANY (QM)? vbox.local. (28)
19:59:53.489931 IP 127.0.0.1.mdns > 127.0.0.1.48573: 47386*- 2/0/0 AAAA ::1, A 127.0.0.1 (72)
I can run on the FreeBSD CI later but I haven't gotten round to it yet.
I reproduced it elsewhere on Linux and to judge from
21:15:52.906120 IP localhost.41359 > localhost.53: 38663+ ANY? 0a12059c0953.local. (36)
21:15:52.906222 IP localhost > localhost: ICMP localhost udp port 53 unreachable, length 72
in some cases that command doesn't actually take the port into account. I replaced it with
drill -p 5353 @127.0.0.1 $(hostname).local ANY
where -p comes first and it did work:
21:21:40.462359 IP localhost.40389 > localhost.5353: 51503+ ANY (QM)? 0a12059c0953.local. (36)
21:21:40.463021 IP localhost.5353 > localhost.40389: 51503*- 2/0/0 AAAA ::1, A 127.0.0.1 (80)
It works on the FreeBSD CI with the loopback interface as well so I'll open a PR.
+ drill -p5353 @127.0.0.1 freebsd.local ANY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36178
;; flags: qr aa ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; freebsd.local. IN ANY
;; ANSWER SECTION:
freebsd.local. 10 IN AAAA ::1
freebsd.local. 10 IN A 127.0.0.1
freebsd.local. 10 IN HINFO "AMD64" "FREEBSD"
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 7 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Nov 13 22:05:03 2025
;; MSG SIZE rcvd: 101
It still fails with 224.0.0.1 on the FreeBSD CI though.
+ drill -p5353 @224.0.0.1 freebsd.local ANY
Error: error sending query: Could not send or receive, because of network error
It should actually send queries to 224.0.0.251 instead of 224.0.0.1. I'll change that.
The IPv6 part still fails though
+ drill -p5353 @ff02::fb freebsd.local ANY
Error: error sending query: Error creating socket
I have about zero knowledge about IPv6, so I asked our networking folks about this issue.
They said that the address should contain a "scope id" and suggested to use this command instead:
drill -p5353 @ff02::fb%lo0 freebsd.local ANY
Note the added %lo0 at the end of the address.
Last time I checked IPv6 wasn't even enabled there so the first step would be to enable it. That being said I set up a bunch of FreeBSD boxes and it seems in general drill isn't suitable for various IPv6-related things.
$ drill -p5353 @ff02::fb%lo0 freebsd.local ANY
Error: could not find any address for the name: `ff02::fb%lo0'
It apparently treats it as a domain name and tries to resolve it. The same happens with non-loopback interfaces like %em1. The -I flag outright rejects scoped addresses with -I must be a valid IP[v6] address.. I also saw https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270920 and so on.
drill -p5353 @::1 freebsd.local ANY works on FreeBSD though (and doesn't work on Linux).
Either way the smoke tests aren't actually that thorough yet so if all else fails the IPv6 part can be skipped on FreeBSD for the time being.
(On an unrelated note I actually reproduced https://github.com/avahi/avahi/issues/560 with FreeBSD 14.1 and with FreeBSD 14.3 it isn't reproducible. If the networking folks know what it was and what could have been fixed in the kernel to get avahi to keep track of the interfaces again it would be great to figure it out).