2

This is an reversal of this question. Strangely I haven't been able to find cases of people wanting to connect to a remote machine from their WSL instance.

In my case, I have a Raspberry Pi whose hostname is rasppi.local, and I'm trying to SSH into it via my WSL Ubuntu instance, but getting a "Temporary failure in name resolution" issue.

What has been tried so far:

  • ssh username@rasppi.local from the Windows machine hosting WSL works fine (Powershell);
  • ssh username@rasppi.local from WSL in the Windows machine fails (Ubuntu);
  • ssh username@<rasppi IP> from both the Windows machine and WSL work;
  • ping <rasppi IP> from the Windows machine and WSL work and all packets are retrieved without any loss;
  • ping superuser.com from both the Windows machine and WSL work.

Output for ssh username@rasppi.local -vvv

The output for ssh username@rasppi.local -vvv in WSL is as follows:

OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "rasppi.local" port 22
ssh: Could not resolve hostname rasppi.local: Name or service not known

Output for ping superuser.com

In Windows Powershell:

PING superuser.com [151.101.129.69] 32 bytes of data:
Response from 151.101.129.69: bytes=32 time=6ms TTL=54

In WSL:

PING superuser.com (151.101.129.69) 56(84) bytes of data.
64 bytes from 151.101.129.69 (151.101.129.69): icmp_seq=1 ttl=54 time=5.59 ms

Output for ip addr

In WSL:

21: eth0: <> mtu 1500 group default qlen 1
    link/ether 02:50:f2:69:1d:00
20: eth1: <> mtu 1500 group default qlen 1
    link/ether 34:73:5a:e0:07:3f
    inet 169.254.28.69/16 brd 169.254.255.255 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::b2ff:c07f:aa77:2b0b/64 scope link dynamic
       valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP> mtu 1500 group default qlen 1
    link/loopback 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host dynamic
       valid_lft forever preferred_lft forever
9: wifi0: <BROADCAST,MULTICAST,UP> mtu 1500 group default qlen 1
    link/ieee802.11 00:d7:6d:09:8c:7e
    inet 192.168.0.22/24 brd 192.168.0.255 scope global dynamic
       valid_lft 2853sec preferred_lft 2853sec
    inet6 2804:14c:1d9:870e:65ac:2928:291f:6c96/64 scope global dynamic
       valid_lft 86283sec preferred_lft 71883sec
    inet6 2804:14c:1d9:870e:6415:bdaa:71ef:128e/128 scope global dynamic
       valid_lft 86283sec preferred_lft 71883sec
    inet6 fe80::7a77:b29:df4a:a9c5/64 scope link dynamic
       valid_lft forever preferred_lft forever
11: wifi1: <> mtu 1500 group default qlen 1
    link/ieee802.11 00:d7:6d:09:8c:7f
    inet 169.254.41.240/16 brd 169.254.255.255 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::d936:f662:1d15:c5ad/64 scope link dynamic
       valid_lft forever preferred_lft forever
10: wifi2: <> mtu 1500 group default qlen 1
    link/ieee802.11 02:d7:6d:09:8c:7e
    inet 169.254.0.167/16 brd 169.254.255.255 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::84fb:86e5:80a3:cf38/64 scope link dynamic
       valid_lft forever preferred_lft forever

Output for route

In WSL:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       0.0.0.0         255.0.0.0       U     256    0        0 lo
127.0.0.1       0.0.0.0         255.255.255.255 U     256    0        0 lo
127.255.255.255 0.0.0.0         255.255.255.255 U     256    0        0 lo
224.0.0.0       0.0.0.0         240.0.0.0       U     256    0        0 lo
255.255.255.255 0.0.0.0         255.255.255.255 U     256    0        0 lo
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wifi0
192.168.0.22    0.0.0.0         255.255.255.255 U     256    0        0 wifi0
192.168.0.255   0.0.0.0         255.255.255.255 U     256    0        0 wifi0
224.0.0.0       0.0.0.0         240.0.0.0       U     256    0        0 wifi0
255.255.255.255 199.262.0.1     255.255.255.255 U     0      0        0 wifi0
0.0.0.0         199.262.0.1     255.255.255.255 U     0      0        0 wifi0

Note that pinging the Raspberry Pi IP's directly works in both Powershell and WSL, so it most likely is a SSH configuration within WSL.

What is missing here in order to connect using the hostname rasppi.local?

In case it's relevant, I'm trying to set up a Taskserver client in the WSL instance, while the server remains in the Raspberry Pi. I could set it a client directly in the Pi and then access via SSH on Powershell, but it seems sub-optimal given that the Pi should be used as a server only. If someone thinks otherwise, I'd appreciate info as this is my first time dealing with networking and servers.

manoelpqueiroz
  • 381

1 Answers1

4

What is missing here in order to connect using the hostname rasppi.local?

You've confirmed that using the IP address works, which I expected it would. So as @SeñorCMasMas mentioned in the comments, this looks to be purely a name resolution issue.

Also, as @GordonDavisson mentioned in the comments, the .local domain indicates that mDNS, rather than DNS, is being used.

Side-note/alternative 1: The best workaround if you have trouble with any of the below would be to set the Pi to have a fixed IP address, and hard-code that address in your WSL distribution's /etc/hosts file. Or just access it by that IP address.

With that said, mDNS support has been in WSL2 for a number of years now, and I can't imagine a still-supported version of Windows at this point that wouldn't include it in the installed WSL2 version.

However, WSL1 does not support mDNS. So naturally, my first guess is that you are using WSL1 and not WSL2. You can check this with:

wsl.exe -l -v

If your WSL distribution shows that it is running as WSL1, then rasppi.local (or any other .local just isn't going to resolve). If, on the other hand, it is showing WSL2, then update the question and I'll noodle some more.

As a workaround (for either WSL1 or WSL2), you could lookup the IP address using PowerShell, since you've said that mDNS resolution works there. The following works for me on Bash on Ubuntu 20.04 on WSL1:

> rasppi=$(pwsh.exe -c '([System.Net.Dns]::GetHostAddresses("rasppi.local","InterNetwork")).IPAddressToString' | tr -d '\r')
> echo $rasppi
# Should see IP
> ssh $rasppi
# Should "resolve"

This assumes you have PowerShell Core ('pwsh.exe') installed. If you have Windows PowerShell ('powershell.exe'), it looks like the syntax is going to be different, and I haven't ironed that one out yet.

Given the note about running the Taskserver client in WSL, you'd need to somehow update the Taskserver config to use either that environment variable, or write/modify the config based

Alternatively, if you find you are running WSL1 and if your system supports WSL2, you could convert to the distribution. In general, WSL2 is going to be more feature-rich and robust, with few downsides as compared to WSL1.

You'll find plenty of instructions for converting, but the general steps are to:

  1. Backup your existing WSL distribution (if critical) with:

    wsl --export <distro_name> <path/to/backup.tar>

  2. Then convert with:

    wsl --set-version <distro_name> 2
NotTheDr01ds
  • 28,025