iputils after the removals: four small network probes you can build from source

Four tools remain after the removals table

iputils started as a broad collection of small Linux networking utilities and has since been pruned hard. The current tool list in the project README is short: arping, clockdiff, ping and tracepath. Each has its own source file or directory in the repository layout, with arping.c, clockdiff.c and tracepath.c sitting at the top level and ping living in its own subdirectory alongside the shared iputils_common.c and iputils_common.h helpers.

The removed side of the table is the more interesting part, because it shows the maintainers drawing a line around protocols that had been superseded. ninfod, rarpd and rdisc were pulled out in 20211215, with rarpd and rdisc described as superseded by the DHCP protocol. tftpd went in 20210722 and the table points at tftp-hpa and dnsmasq instead. traceroute6 also went in 20210722, with mtr, traceroute and tracepath listed as the replacements.

That last row is the practical one for anyone reaching for the old name. tracepath stays inside the package while traceroute6 does not, so an upgrade path already exists inside iputils itself rather than requiring a new dependency.

A configure wrapper that hands the real build to Meson

The build has two entry points, and the ordering between them is not obvious from the file list alone. At the top level there is a `configure` script, and there is also `meson.build`, `meson_options.txt`, `build-aux/`, `build.sh` and `ci/`. The README describes configuration as adjustable for prefix and for what is being built, pointing readers at meson_options.txt and meson.build for those knobs, and it notes that build dependencies are listed in scripts under the ci directory.

So the configure step is not the whole build system. It appears to prepare the tree, and Meson plus the Ninja generator do the real compilation. That split has a consequence for anyone building inside a package manager or a container image: the configure invocation is not optional, and a build that skips it will not reach the point where the tools exist.

The top level Makefile is a thin convenience layer over that setup rather than a second build system. Its targets delegate to Ninja inside the builddir directory, including a test target reachable through the check target.

The install sequence the README gives you

The README offers exactly two lines for getting the tools onto a system, and both are shown as a single block.

$ ./configure && meson build
# cd builddir && meson install

Read this as three actions. First the configure script runs and Meson generates the build tree. Then `meson build` compiles it. Then you move into the build directory and run the install step, which is where the binaries land under the configured prefix.

Two things are worth checking before you run this. The install step inherits whatever prefix was set during configuration, and the README says the prefix is one of the adjustable options, so if you need the tools somewhere other than the default prefix you must set it during the configure phase rather than after the build exists. The second is the libc: the README lists glibc, uClibc-ng and musl as the supported C libraries, so a system built against something else is outside what the project claims to support.

The Makefile gives you the same operations wrapped in named targets, which is what a distribution packaging recipe would tend to call.

Each probe sits at a different layer of the stack

The four surviving tools are not four flavours of one idea. arping answers at the link layer, working with the ARP exchange rather than with routed IP traffic, and it is the reason the file is a single .c file at the top of the tree. clockdiff measures the difference between the time reported by a remote host and the local clock, which makes it a time comparison tool rather than a reachability tool.

ping is the one that received structural attention: instead of a single source file it has a subdirectory, which suggests that its implementation is split across several translation units. The shared code that all of them draw on sits in iputils_common.c and iputils_common.h, with ipv6.h and md5.h and md5.c providing the address family header and a message digest implementation. git-version.h.meson sits at the top level, which points to the version string being generated during the Meson build rather than hand maintained.

tracepath is listed with its own source file and is the tool that answers where the path stops without needing administrative privilege to send the probe packets. The README describes the coding style for most tools as ancient, and asks that new code follow the Linux kernel coding style, which is a fair signal about the state of the code that predates the current maintainers.

Contributing rules that assume kernel style and kernel habits

The contributing section is unusually specific for a utility package, and it reads like it was written with kernel maintainers in mind. Bug reports should document how to reproduce the issue and should note the kernel and distribution used, and contributors are asked to test the latest master branch rather than a tagged release. Finding the commit that introduced a problem helps, with bisecting named explicitly as the technique.

Pull requests carry the same expectations. New features need a description of why they are useful. Commits should be signed with a Signed-off-by trailer, and reviewers are asked to add a Reviewed-by trailer when they comment. There is one workflow instruction that will surprise anyone coming from a typical Git hosting site: to update code in an existing pull request, push with force to the same branch rather than opening a new pull request.

Tests should ideally use network namespaces so they do not interfere with the rest of the system. That is a meaningful constraint for anyone running the suite on a shared build machine, because a namespace based test run needs the privileges to create namespaces. Localization lives on Fedora Weblate, and the top level po directory matches that arrangement.

Where iputils is the wrong tool

There is a clear case for not building this yourself. If a Linux system already ships working ping, arping, clockdiff and tracepath binaries through its distribution packages, compiling the upstream sources adds build dependencies and a Meson toolchain for no functional gain. The value of iputils is highest on minimal embedded images, on systems where the distribution versions of these tools are missing or where specific utilities have been dropped, and for distributions that need to rebuild with a different prefix or a reduced tool set.

The second limit is scope. iputils no longer contains anything for ARP daemon duties, TFTP serving, router discovery, or traceroute over IPv6, and the README lists what replaced those rather than what to install. Anyone arriving expecting the historic tool list will find a much narrower package.

The third limit is licensing and packaging friction. The licence is recorded as a custom licence that GitHub cannot classify, with the terms living in the LICENSE file at the repository root, so a redistribution review has to read that file directly instead of relying on a standard SPDX identifier. For a package of a handful of programs that is a small but non zero cost.

Release cadence and what upgrading actually means

The repository is not archived, and the last push was on 2026-10-16, so the tree reflects recent work rather than a frozen snapshot. The release tags move on a numeric scheme: the releases listed are 20250605, 20250602 and 20240905. Those names read as calendar dates in YYYYMMDD form rather than semantic versions, which means there is no major or minor version to reason about when you upgrade. You either take a dated tag or you build from master.

The project's own advice points at the second option for anyone debugging. Testing the latest master branch is requested of bug reporters, so a released tag and the current tree can behave differently, and the difference is where a fix might live. For an operator who wants a reproducible build, pinning to a dated tag is the only stable choice; for anyone chasing a specific defect, building master is what the maintainers ask contributors to use.

The CHANGES file and the Documentation directory are present at the top level, alongside a SECURITY.md and an iputils.doap, but the repository listing alone does not describe what security policy or release notes are recorded there.

Editorial conclusion

iputils suits maintainers of embedded and distribution Linux images who want the canonical ping, arping, clockdiff and tracepath sources rather than a packaged binary set, and it suits anyone who needs to adjust what gets built through meson_options.txt. It is the wrong choice for a workstation that already has working copies of these tools, and for anyone expecting the older rarpd, rdisc, tftpd or traceroute6 behaviour, since those were removed and are only pointed at replacements in a table. Before adopting it, check the libc your target actually uses against the three supported ones, and confirm that the version you pull, the last push being on 2026-10-16, still carries the tools you need.

Frequently asked questions

Official sources

1. iputils/iputils on GitHub
2. Issues
3. README
4. Releases