New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't resolve ".local" (mDNS) hosnames #384

Closed
aseering opened this Issue May 17, 2016 · 22 comments

Comments

Projects
None yet
@aseering
Copy link
Contributor

aseering commented May 17, 2016

I have an existing stock Ubuntu server on my network. Let's say its hostname is "my-server". (The following should work with a stock Mac as well; not sure about Windows servers?)

If I open up a regular Command Prompt, I can do the following:

C:\Users\me>ping my-server.local

Pinging my-server [10.0.0.1] with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=3ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64

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

But from Bash-on-Windows:

bash-on-windows$ ping my-server.local
ping: unknown host my-server.local

For comparison, from a real Ubuntu machine on the same network, I can do:

real-linux$ ping my-server.local
PING my-server.local (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.206 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.138 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.130 ms
(...)

Granted, ping wouldn't work even if it could resolve the name due to #18 , but other tools like curl or ssh would work if appropriate services were running on the server. I'm just trying to post a minimal reproducer.

@aseering

This comment has been minimized.

Copy link
Contributor

aseering commented May 17, 2016

mDNS resolution on Ubuntu is normally provided by Avahi. But the following doesn't work:

$ sudo apt-get install -y avahi-daemon
(... installs Avahi ...)
$ sudo service avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                                                                       Segmentation fault (core dumped)
$ sudo /usr/sbin/avahi-daemon
Found user 'avahi' (UID 106) and group 'avahi' (GID 113).
Successfully dropped root privileges.
avahi-daemon 0.6.31 starting up.
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.6.31 exiting.

dbus doesn't work due to #376 .

Unfortunately, I haven't been able to reproduce the segfault while running under strace. Nor under gdb, which just hangs and/or otherwise behaves badly.

@lilred

This comment has been minimized.

Copy link

lilred commented May 29, 2017

Oooh, I just hit this one. It was quite a head-scratcher! I'm curious as to whether there's been any progress on this :o

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Jun 6, 2017

On one of the latest builds:

$ apt-get install -y avahi-daemon
$ /etc/init.d/dbus start
$ /usr/sbin/avahi-daemon

Process 588 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
Found user 'avahi' (UID 112) and group 'avahi' (GID 116).
Successfully dropped root privileges.
avahi-daemon 0.6.32-rc starting up.
Successfully called chroot().
Successfully dropped remaining capabilities.
No service file found in /etc/avahi/services.
*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
SO_REUSEPORT failed: Protocol not available
*** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
SO_REUSEPORT failed: Protocol not available
netlink.c: SO_PASSCRED: Invalid argument
on: starting up: iface-linux.c:380: avahi_interface_monitor_sync: Assertion `m' failed.
Aborted (core dumped)

From the output above, we can see few blocking issues here. Those would be; support for the socket option SO_REUSEPORT and SO_PASSCRED for netlink sockets. Support for SO_REUSEPORT requires some work from the core Windows networking team and the WSL team is working with them on that.
SO_PASSCRED for netlink sockets seems entirely in control of WSL and should be trivial. No ETA for either of them yet.

@Plazmaz

This comment has been minimized.

Copy link

Plazmaz commented Jun 22, 2017

This also makes it impossible to run certain configurations of webpack

@Vipor26

This comment has been minimized.

Copy link

Vipor26 commented Jun 26, 2017

I hit this while trying to do some work on my pi powered quadrupeds. Back to using my mac terminal.

@scivision

This comment has been minimized.

Copy link

scivision commented Aug 2, 2017

Lack of Avahi support in WSL makes it difficult to use WSL/WIndows PCs in teaching labs with increasingly ubiquitous Raspberry PI and the like in engineering education.

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Aug 4, 2017

@scivision - I looked into this a bit. As explained previously, there were two blocking issues.

  1. Lack of SO_REUSEPORT in WSL (and in Windows in general).
  2. Lack of SO_PASSCRED on NETLINK sockets.

After stubbing (1) (because there is no support from Windows networking stack), implementing (2) and few other minor changes, it seems like avahi-daemon is happy.

:~# service dbus start
 * Starting system message bus dbus                                    [ OK ]
:~# service avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                      [ OK ]
:~# avahi-resolve-address 192.168.0.52
192.168.0.52    xxxxx.corp.microsoft.com
:~#

I will get the PR out and try to get this in time for Fall Creators Update.

If you look at the avahi-daemon logs (with this change), it still complains about IP_ADD(DROP)_MEMBERSHIP, but that can be taken up as a separate issue. It appears to be functional otherwise, in my limited testing.

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Aug 25, 2017

This should be fixed in 16273

@sgrebnov

This comment has been minimized.

Copy link
Member

sgrebnov commented Sep 14, 2017

Confirm upgrading to the latest Windows Insider Preview build (1709 build 16288.1) fixed SO_REUSEPORT related issue for me. Thanks

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Sep 14, 2017

@sgrebnov - Thanks for confirming.

I am marking this issue closed. If it persists after upgrading to 16273, please let us know and we can reopen it.

@OhMeadhbh

This comment has been minimized.

Copy link

OhMeadhbh commented Jun 14, 2018

So I understand that we consider this bug "fixed," but I was wondering if the functionality described above will ever be implemented. It would be very cool for mDNS / ZeroConf to actually work on WSL.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jun 14, 2018

but I was wondering if the functionality described above will ever be implemented

I suspect it already is; just not on port 5353 because there is already something listening there. It is very roughly analogous to asking whether Samba servers will ever work in WSL. They do. But not on port 445. [No one has looked real close though, ref #2664]

@OhMeadhbh

This comment has been minimized.

Copy link

OhMeadhbh commented Jun 14, 2018

the title of this issue is "can't resolve '.local' (mDNS) hostnames" and not "can i listen on port 5353."

i'm asking if we'll ever be able to resolve .local (mDNS) hostnames.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jun 15, 2018

That's a fair question- I read your "above" ambiguously because this issue morphed immediately into "avahi-daemon dies".

The issue title is likely a Windows ask not a WSL ask. Effectively, your ask is this. If you have a compliant mDNS service that is serving up .local local names correctly in Windows, then it is possible the ping scenario in the OP (ie the client side) would "just work". If it doesn't, that would be a great new issue submission, but it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side. That is what I was getting at with the comment about no one (that I am aware of) having looked real close.

[In the interest of completeness, if WSL had its own virtualized ethernet network devices avahi-daemon would work too, in isolation. But that's a different ask.]

@OhMeadhbh

This comment has been minimized.

Copy link

OhMeadhbh commented Jun 15, 2018

no. mDNS already works on Windows 10. in fact, my work around is to use cmd.exe to do the resolution with a command like ping -4 whatever.local and then copy the ip address into a bash window.

i assure you, my request is for mDNS name resolution to work on WSL.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jun 15, 2018

i assure you, my request is for mDNS name resolution to work on WSL.

And I assure you, if it doesn't work, that would be a great new issue submission. But it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side that identified a diverge in behaviour in WSL versus say a Real Linux Ubuntu in a VM connected to the same mDNS service on Windows.

Which no one (that I am aware of) has looked into.

@OhMeadhbh

This comment has been minimized.

Copy link

OhMeadhbh commented Jun 15, 2018

scroll up to the top of this page.

aseering gives an example of the behaviour on native linux and then an example on WSL. note that the two systems behave differently despite the same software being installed.

aseering mentions another issue (issue #18), but as I have stated, this is not what i'm talking about. I'm talking about how WSL can't resolve ".local" (mDNS) hostnames. This is independent of the ping utility.

There is also a dependency on dbus working. If it needs to be fixed before this bug can be resolved, then it should be fixed and both this issue and issue #376 should remain open until they are fixed.

Are you really saying this bug was closed because no one can demonstrate mDNS resolution fails in WSL but does not fail under Windows 10? Because this is EXACTLY what this issue demonstrates.

Perhaps someone should look into it.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jun 15, 2018

gives an example of the behaviour on native linux and then an example on WSL on native linux and then an example on WSL. note that the two systems behave differently despite the same software being installed.

On Native Linux mDNS services are normally provided by Avahi. As you assured me, your request is for mDNS name resolution to work on WSL, not the Avahi mDNS service. It is not the same software installed. One is Avahi. One is the Windows 10 mDNS service.

There is also a dependency on dbus working

There are no known outstanding issues with dbus in WSL. If you find any problems with dbus, please feel encouraged to open a new issue describing the diverge.

Are you really saying this bug was closed because no one can demonstrate mDNS resolution fails in WSL but does not fail under Windows 10?

I am really saying: that if it doesn't work, that would be a great new issue submission. But it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side that identified a diverge in behaviour in WSL versus say a Real Linux Ubuntu in a VM connected to the same mDNS service on Windows.

@kjcole

This comment has been minimized.

Copy link

kjcole commented Jul 2, 2018

My problem (and I'll pour through this and other posts again) is that I have code I've written that works on Linux (Ubuntu and Arch) and Mac OS X. Both the Python code and C# code work fine on Linux and Mac OS X. I am now working with someone else's Windows 10 box, and, wanting all my regular tools , cranked up WSL a la Ubuntu, and cannot get the code to resolve the "*.local" stuff that works in the other two OS's. (If I recall correctly, CygWin did not suffer from this lack of understanding the last time I tried such a thing, but that was many moons ago.)

@davydka

This comment has been minimized.

Copy link

davydka commented Oct 2, 2018

I really think this issue should be reopened. It would be great if WSL handled mDNS out of the box, or if one simply had to apt install avahi-daemon; sudo service avahi-daemon start
Being able to resolve ".local" network names without copying->pasting ip addresses should be possible.

edit: I'm still seeing this issue on build 17134.286, any assistance is appreciated.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Oct 2, 2018

Sunil closed this one as spirituality dupe #376 and suggested a new issue be opened on other blockers. The current (as of this writing) well-formed landing zone for avahi-daemon is #3365.

@davydka

This comment has been minimized.

Copy link

davydka commented Oct 2, 2018

Thank you I will monitor there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment