.local names can only be resolved from wsl2 connected via Ethernet but not via WiFi

[eriktews]

Environment

Windows build number: 2004
Your Distribution version: Ubuntu
Whether the issue is on WSL 2 and/or WSL 1: WSL2 only, it doesn't work on WSL1 at all

Steps to reproduce

Install Ubuntu on WSL2 and maybe install avahi-daemon as well. It's not required to start dbus and/or avahi-daemon. Connect you laptop via Ethernet to a network with other hosts that can be resolved using mDNS. Then just run ping abc.local in Ubuntu and it should just work fine. However when you disconnect the Ethernet cable and connect your host to the network via WiFi, then the ping command doesn't work anymore.

I then booted into Linux natively on the same machine and there I was able to resolve the host via Ethernet and via WiFi, so it's not a problem of the local WiFi router.

Expected behavior

I think .local names should resolve just fine.

Actual behavior

Resolving .local names from Ubuntu doesn't work when the host system is connected via WiFi instead of Ethernet.

Related issues

It sounds like #384 and #3365 are related but they are already closed.

[edinc]

Just came across the same issue when trying to connect to my raspberry pi. Installed avahi-daemon and started the service, but still:

❯ ssh [email protected]
ssh: Could not resolve hostname raspberrypi.local: Name or service not known

[eriktews]

So now it sometimes works via WiFi here as well. However I cannot say yet when it happens and when it doesn't happen. The only thing I can say is that I installed wireshark and it looked like the mDNS request went out but no response came back while a request from the Windows system directly (launching ping via cmd/powershell) would be properly answered by the other host.

[vjancik]

I can't get it to work even on ethernet either. Same setup.

At daemon startup, this occurs:

Host name conflict, retrying with <HOSTNAME>-2

and apparently the original maps to the host Windows machine, which I can confirm by resolving to it from another machine on the local network (or from WSL for that matter).

Unanswered query (from WSL):

5 4.874430800 172.22.127.177 → 224.0.0.251  MDNS 83 Standard query 0x0000 A raspberrypi.local, "QM" question AAAA raspberrypi.local, "QM" question

Answered Windows host IP resolution (from WSL):

 34 265.110408000 fe80::215:5dff:fefb:ca31 → ff02::fb     MDNS 103 Standard query 0x0000 A <HOSTNAME>.local, "QM" question AAAA <HOSTNAME>.local, "QM" question
 35 265.110463800 172.22.127.177 → 224.0.0.251  MDNS 83 Standard query 0x0000 A <HOSTNAME>.local, "QM" question AAAA <HOSTNAME>.local, "QM" question
 36 265.111658400 172.22.112.1 → 224.0.0.251  MDNS 135 Standard query response 0x0000 A, cache flush 172.22.112.1 AAAA, cache flush fe80::149d:d920:25b8:4b37 NSEC, cache flush <HOSTNAME>.local
 37 265.111941100 fe80::149d:d920:25b8:4b37 → ff02::fb     MDNS 152 Standard query response 0x0000 A 172.22.112.1 AAAA fe80::149d:d920:25b8:4b37
 38 265.113199300 172.22.112.1 → 224.0.0.251  MDNS 132 Standard query response 0x0000 A 172.22.112.1 AAAA fe80::149d:d920:25b8:4b37

I have confirmed with WireShark on the host machine, that the MDNS requests don't get "mirrored / bridged" from the vEthernet (WSL) virtual bridge adapter, to the physical Ethernet adapter the same way they get bridged for normal packets.

Probably because the bridge network is a valid subnet, and there's no implicit reason to forward a multicast packet to another (gateway) network. Even though that is undesirable in this case.

[vjancik]

Update:
Not running avahi-daemon in WSL at all, makes resolving .local addresses resolve successfully.

As long as MDNS support is enabled on the Windows host (which apparently it is) then trying to resolve a .local address directly using a normal DNS request

7 1.013978000 172.19.210.190 → 172.19.208.1 DNS 77 Standard query 0xca9c A raspberrypi.local
8 1.013990900 172.19.210.190 → 172.19.208.1 DNS 77 Standard query 0x4587 AAAA raspberrypi.local
9 1.027835500 172.19.208.1 → 224.0.0.251  MDNS 77 Standard query 0x0000 A raspberrypi.local, "QM" question
10 1.029148900 fe80::bd59:20fb:7514:15dc → ff02::fb     MDNS 97 Standard query 0x0000 A raspberrypi.local, "QM" question
11 1.032137000 172.19.208.1 → 172.19.210.190 DNS 110 Standard query response 0xca9c A raspberrypi.local A 192.168.0.117
12 1.034535100 172.19.208.1 → 224.0.0.251  MDNS 77 Standard query 0x0000 AAAA raspberrypi.local, "QM" question
13 1.035766800 fe80::bd59:20fb:7514:15dc → ff02::fb     MDNS 97 Standard query 0x0000 AAAA raspberrypi.local, "QM" question
14 1.039550500 172.19.208.1 → 172.19.210.190 DNS 122 Standard query response 0x4587 AAAA raspberrypi.local AAAA fe80::c58c:12ee:af24:b1e8

prompts the host to issue an MDNS request and forward the reply as a DNS reply to the WSL DNS request. It works automagically.

[dc366]

I am having a similar issue. I can resolve the MDNS from Windows cmd, but not from Ubuntu/WSL2. The behavior is not consistent either. I have tried both stopping and starting avahi-daemon within Ubuntu/WSL2.

From Windows cmd:

>ping owrt.local

Pinging OWRT.local [192.168.87.202] with 32 bytes of data:
Reply from 192.168.87.202: bytes=32 time=3ms TTL=64
Reply from 192.168.87.202: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.87.202:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 3ms, Average = 2ms

>ping backupbot.local

Pinging backupbot [192.168.87.181] with 32 bytes of data:
Reply from 192.168.87.181: bytes=32 time=8ms TTL=64
Reply from 192.168.87.181: bytes=32 time=2ms TTL=64
Reply from 192.168.87.181: bytes=32 time=3ms TTL=64

Ping statistics for 192.168.87.181:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 8ms, Average = 4ms`

From Ubuntu on WSL2 (with and without avahi-daemon running):

$ sudo service avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                                                                [ OK ]
$ ping owrt.local
ping: owrt.local: Name or service not known
$ ping backupbot.local
ping: backupbot.local: Name or service not known
$ sudo service avahi-daemon stop
 * Stopping Avahi mDNS/DNS-SD Daemon avahi-daemon                                                                [ OK ]
$ ping backupbot.local
ping: backupbot.local: Name or service not known
$ ping owrt.local
PING OWRT.local (192.168.87.202) 56(84) bytes of data.
64 bytes from 192.168.87.202 (192.168.87.202): icmp_seq=1 ttl=63 time=4.23 ms
64 bytes from 192.168.87.202 (192.168.87.202): icmp_seq=2 ttl=63 time=1.91 ms
64 bytes from 192.168.87.202 (192.168.87.202): icmp_seq=3 ttl=63 time=5.07 ms
64 bytes from 192.168.87.202 (192.168.87.202): icmp_seq=4 ttl=63 time=6.03 ms
^C
--- OWRT.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3099ms
rtt min/avg/max/mdev = 1.906/4.307/6.026/1.525 ms

[dc366]

I am having a similar issue. I can resolve the MDNS from Windows cmd, but not from Ubuntu/WSL2. The behavior is not consistent either. I have tried both stopping and starting avahi-daemon within Ubuntu/WSL2.

Retracting my comment above about 'inconsistent behavior' - this is not specific to Ubuntu/WSL2 on my network and may be due to the version of avahi-daemon on one specific host (backupbot.local).

However, my notes above confirm the behavior noted by vjancik - that closing avahi-daemon in wsl2/ubuntu allows the .local name to resolve successfully, owrt.local in my example.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!