aspnet:8.0 image missing iputils-ping package

[MarcMenghin]

Describe the bug

I have a Service running in a container of mcr.microsoft.com/dotnet/aspnet:8.0. This Sevice does a Ping using System.Net.NetworkInformation.Ping which is not possible because of this missing package.

I would expect that all provided core functionality from .NET works in these containers. Especially if it is the System.Net Namespace. So, I guess this is a bug.

My current workaround is the following in my Docker files:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
RUN ["apt-get", "update"]
RUN ["apt-get", "install", "-y", "iputils-ping"]

But this increases the docker image build time and size considerably (15MB+) for such a small utility package.

Which .NET image(s) are you using?

mcr.microsoft.com/dotnet/aspnet:8.0

Steps to reproduce

No response

Other information

No response

Output of docker version

Output of docker info

[lbussell]

Hi @MarcMenghin, there are two things going on here. First I would like to address the size issue.

The size increase you are seeing in your example is coming from using apt-get inefficiently with Docker layers. In your Dockerfile snippet, RUN ["apt-get", "update"] will download approximately ~15-20 MB of apt cache that is not cleaned up automatically. By not cleaning it up manually, that cache is included in your image and shipped along with it. The recommended way to install packages in Debian/Ubuntu container images is:

RUN apt-get update \
    && apt-get install -y --no-install-recommends iputils-ping \
    && rm -rf /var/lib/apt/lists/*

It is important that all of that happens in the same RUN instruction since each RUN instruction creates an additional image layer. This approach will reduce the size impact from ~15-20 MB to about ~100-200 kB, just the size of the iputils-ping pacakge itself.

---

OK, the ping issue.

The .NET runtime uses raw ICMP sockets directly. It only shells out to ping if something about the network configuration does not allow .NET to use raw sockets.

Referenced .NET Runtime code:

• Ping.Unix.cs
• RawSocketPermissions.cs

I initially could not reproduce your issue. Then, I discovered that it only fails when running as non-root user. Are you by any chance running your container with a non-root user @MarcMenghin?

I think this is due to CapEff being 0 for Docker non-root users. This means it's missing the CAP_NET_RAW capability (as well as all other capabilities), so the non-root user can't open raw sockets.

Installing libcap2-bin and running setcap cap_net_raw+ep /app/pingtest works to allow the dotnet apphost to open raw ports when running under the non-root user. However, I don't know the security implications of this and I wouldn't recommend it without more research.

Related: dotnet/runtime#103838 - includes discussion about potentially using SOCK_DGRAM sockets for .NET's Ping functionality, but looks like that never materialized. /cc @dotnet/ncl

So for now, @MarcMenghin, I'd recommend the size fix. We have no plans to add new packages to .NET 8, 9, or 10 images since that would be a breaking change. Maybe we can get DGRAM sockets working for Ping in .NET 11 but that's not something we would backport I think.

Repro details/instructions

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

COPY <<EOF pingtest.csproj
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>
EOF

COPY <<EOF Program.cs
using System.Net.NetworkInformation;
var host = "8.8.8.8";
try
{
    var ping = new Ping();
    var reply = ping.Send(host, 3000);
    Console.WriteLine($"Ping {host}: {reply.Status} ({reply.RoundtripTime}ms)");
}
catch (Exception ex)
{
    Console.WriteLine($"Ping {host}: Error - {ex.GetType().Name}: {ex.Message}");
    if (ex.InnerException is not null)
        Console.WriteLine($"  Inner: {ex.InnerException.GetType().Name}: {ex.InnerException.Message}");
}
EOF

RUN dotnet publish -c Release -o /out

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["dotnet", "pingtest.dll"]

Output:

$ docker build --pull --no-cache -t ping-test .
$ docker run --rm ping-test
...
Ping 8.8.8.8: Success (7ms)
$ docker run --user 1654 --rm ping-test
...
Ping 8.8.8.8: PlatformNotSupportedException: The system's ping utility could not be found.

[MarcMenghin]

Thank you for the detailed information. Your conclusions seem to be correct. I do run my services as non-root user. For now, I will use the size reducing command you provided.

Just one related question: Are there known performance implications with ICMP Sockets vs using ping? I suspect the later will be a slower process.

[lbussell]

My intuition is that shelling out to ping is slower, but I must defer to @dotnet/ncl for more detail than that.

[wfurt]

While starting separate process is more expensive I don't think there is visible difference. Windows has API for ICMP that does not require privilege but Linux did not. So the fallback is using ping utility that is SUID. I would personally feel the use of ping is somewhat rare and easily fixable by anyone why cares.

[lbussell]

I am leaving this open/untriaged so that we can discuss whether to add ping to .NET 11+ images at the next triage meeting.