Ping not working in wsl2 debian.

[pnunn]

• Your Windows build number: 10.0.19041.207

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
  ping 8.8.8.8

• What's wrong / what should be happening instead:
  ping: socket: Operation not permitted

Is it possible that something is blocking icmp packets?
ssh works fine, so tcp seems to be OK.

Ta
Peter

[therealkenc]

Short answer, mortals don't have CAP_NET_RAW by default.

Dunno why SUID isn't set on Debian. Might be that they are using security.capabilities and those aren't getting picked up by WSL's tar on install, but that's speculation.

You can make the binary SUID like Ubuntu with chmod u+s, or newspeak is add the capability with setcap:

$ sudo setcap cap_net_raw+p /bin/ping

Borders tag linux-behavior, because WSL2 is doing what it's told. But the tar (distro install) hypothesis could be tested by putting a small busybox tarball together with a security.capabilities file, do a wsl.exe --import, and see what happens. Maybe that could be bent into an actionable under a different cover depending on the outcome.

[pnunn]

Thanks @therealkenc that is awsome.
setcap did the trick and all now seems to be working. I'll try and migrate my ubuntu wsl1 machine now and see what happens there.

Thanks again.
P.

[therealkenc]

Great. Alright let's call this linux-behavior. If someone wants to dive whether the security.capabilities xattr hypothesis is correct or otherwise that is a different enough ask that would have a different repro.

[NotTheDr01ds]

An alternative that I don't think was available last year when this was originally asked ...

To handle this in all WSL2 distributions using kernel >= 5.8, create or edit your %userprofile%\.wslconfig and add:

[wsl2]
kernelCommandLine = sysctl.net.ipv4.ping_group_range=\"0 2147483647\"

This sets the "Range of the group IDs (minimum and maximum group IDs, inclusive) that are allowed to create ICMP Echo sockets."

I kind of stumbled across this when I noticed that ping was working in a recent openSUSE WSL2 install, even though it was not SUID nor had any capabilities set. Normally my openSUSE installs have the same problem as Debian (but a different root cause).

It turns out that for openSUSE and some other distributions (e.g. Fedora, I believe, if you attempted a rootfs wsl --import) this is a YASI (Yet Another Systemd Issue). For those distributions, there is a Systemd unit that runs sysctl rules. This doesn't get enabled under WSL, of course.

The reason it was working for me, all of a sudden, is that I had run Systemd in one of my test distros (basic unshare/nsenter) a few days before, and I had not rebooted or done a wsl --shutdown since then. So my /proc/sys/net/ipv4/ping_group_range was 0 2147483647, purely by accident.

[NotTheDr01ds]

Also decided to test/confirm/refute the Debian side of things as @therealkenc suggested.

Dunno why SUID isn't set on Debian. Might be that they are using security.capabilities and those aren't getting picked up by WSL's tar on install, but that's speculation.

.... But the tar (distro install) hypothesis could be tested by putting a small busybox tarball together with a security.capabilities file, do a wsl.exe --import, and see what happens. Maybe that could be bent into an actionable under a different cover depending on the outcome.

Per this Debian mailing list, yes, on Debian this is due to the use of security capabilities. And the problem still exists in the Bullseye release in the Store (an update since this issue was originally raised).

However, it does not appear to be a wsl --import issue. I did create a busybox rootfs tarball as suggested, with the following:

drwxr-xr-x - root 10 Oct 16:53 bin
drwxr-xr-x - root 10 Oct 16:58 etc
drwxr-xr-x - root 10 Oct 19:59 lib
drwxr-xr-x - root 10 Oct 20:00 lib64
drwxr-xr-x - root 10 Oct 16:57 proc
drwxr-xr-x - root 10 Oct 20:10 root
drwxr-xr-x - root 10 Oct 17:47 sbin
drwxr-xr-x - root 10 Oct 21:03 usr

./bin:
.rwxr-xr-x 975k root 10 Oct 16:44 busybox
lrwxrwxrwx    7 root 10 Oct 16:53 sh -> busybox

./etc:
.rw-r--r-- 30 root 10 Oct 16:55 passwd  # root:x:0:0:root:/root:/bin/sh
.rw-r--r--  8 root 10 Oct 16:58 shells      # /bin/sh

./lib:
.rwxr-xr-x 2.0M root 10 Oct 18:41 libc.so.6
.rw-r--r--  31k root 10 Oct 18:40 libcap.so.2

./lib64:
.rwxr-xr-x 191k root 10 Oct 20:00 ld-linux-x86-64.so.2

./proc:

./root:
.rw-r--r--  21 root 10 Oct 20:10 test1.sh
.rw-r--r--  21 root 10 Oct 20:10 test2.sh

./sbin:
.rwxr-xr-x 14k root 10 Oct 17:47 getcap
.rwxr-xr-x 14k root 10 Oct 17:47 setcap

./usr:
drwxr-xr-x - root 10 Oct 21:03 bin

./usr/bin:

Pretty sure this is about the bare minimum for a busybox distro + getcap and supporting libraries (copied in from Ubuntu). Not that it should matter, but:

• /root/test1.sh was given cap_net_raw+p from within the Ubuntu environment where I was creating the rootfs
• /root/test1.sh was given cap_net_raw+p when chrooted into the busybox rootfs

Whether or nor the capabilities persisted did depend on the tar command, as @therealkenc suspected, but it's not a problem with wsl --import's tar. Some testing results:

• sudo tar -cvf ../busybox.tar . followed by sudo tar xvf ../busybox.tar in an empty sibling directory lost the capabilities
• sudo tar --xattrs -cvf ../busybox.tar . followed by sudo tar xvf ../busybox.tar in an empty sibling directory lost the capabilities
• sudo tar --xattrs -cvf ../busybox.tar . followed by sudo tar --xattrs -xvf ../busybox.tar in an empty sibling directory lost the capabilities
• sudo tar --xattrs -cvf ../busybox.tar . followed by sudo tar --xattrs-include="security.capability" -xvf ../busybox.tar in an empty sibling directory kept the capabilities intact.
• sudo tar -cvf ../busybox.tar . and using that tarball with wsl --import lost the capabilities
• sudo tar --xattrs -cvf ../busybox.tar . and using that tarball with wsl --import kept the capabilities intact

From this, it seems obvious that wsl --import is doing things right and including the security.capability xattrs when extracting the tarball. The Debian build system (or maintainer(s)) creating the rootfs tarball, however, is likely not adding --xattrs when creating it.

I'm not sure, but they may be using Debuerreotype. I know they use it for the Debian Docker image rootfs, and the project description "Reproducible, snapshot-based Debian rootfs builds (especially for Docker)" makes it sound like it may be used elsewhere, perhaps for the WSL rootfs. I'm guessing that ping isn't a problem in the Docker image since it is effectively running as root in its namespace. So the issue only manifests in WSL (and potentially other uses).

If they are using Debuerreotype, then they do already know about the issue (and here) apparently. Unfortunately, they put in a Docker-specific fix instead of adding --xattrs, since tar --xattrs results in a different tar file on every invocation (breaking their reproducible build system). I did confirm this, and each run of the working command above results in a different md5sum.

@therealkenc said:

Maybe that could be bent into an actionable under a different cover depending on the outcome.

Perhaps I'm mistaken, but I'm assuming that the WSL team has an upstream Debian contact that could look at this?

Even if they don't/can't fix the packaging issue, perhaps they could add the capability during the initial WSL configuration (username/password create) step? They should probably also do an audit on any other capabilities they are using that have been lost under WSL.

[balexiev]

It's worth noting that Debian doesn't use SUID by default, not only in WSL. So we have to use the capabilities option.

Standalone Debian installation
$ v /bin/ping
-rwxr-xr-x 1 root root 68076 Nov 10 2016 /bin/ping

user root capabilities:
# getcap /bin/ping
/bin/ping = cap_net_raw+ep

Debian WSL2
# getcap /bin/ping
/bin/ping cap_net_raw=p

$ getcap /bin/ping
$
(we see an empty response)

So what we need to get ping working is to run the following command (assuming the path is /bin/ping):
setcap 'cap_net_raw+p' /bin/ping

But if we run it as a normal user, we will get an error:
$ setcap 'cap_net_raw+p' /bin/ping
unable to set CAP_SETFCAP effective capability: Invalid argument

So, we use sudo:
$ sudo setcap 'cap_net_raw+p' /bin/ping
$ getcap /bin/ping
/bin/ping cap_net_raw=p
$
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=1.86 ms

Reference: https://blog.container-solutions.com/linux-capabilities-in-practice

[NotTheDr01ds]

It's worth noting ...

Apologies, but as far as I can tell all of what you wrote is covered above, mainly in therealkenc's comment and my confirmation of the capabilities hypothesis on Debian.

[aentwist]

For IPv6 see #4518

[odtmusisi19]

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

im stuck

[thespeck]

I'm stuck too.

[accnetdev]

Me too, it does not fix the issue. No connectivity here using WSL2 and Debian distro.

[sascha-wi]

bump