# bandwhich: per-process bandwidth in the terminal, and what passive maintenance means for you

> bandwhich is a Rust CLI that sniffs a network interface and attributes traffic to processes, connections and remote hosts. It installs from prebuilt binaries or cargo, needs packet-capture privileges, and is in passive maintenance.

**imsnif/bandwhich** — Terminal bandwidth utilization tool

- Repository: https://github.com/imsnif/bandwhich
- Stars: 11,991 · Forks: 352
- Language: Rust
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/imsnif-bandwhich

## What bandwhich answers that top and iftop do not

The README describes bandwhich as a CLI utility for displaying current network utilization by process, connection and remote IP or hostname. That list is the point. A tool that only shows interface throughput tells you the link is busy; bandwhich tells you which local process owns the socket behind that traffic, and which remote address it is talking to. The README's own framing is that it sniffs a network interface, records IP packet size, and cross-references that against process information from the /proc filesystem on Linux, lsof on macOS, or WinApi on Windows. It is aimed at the person who is already on the box: a developer wondering why an idle-looking machine is uploading, an operator on a small server where installing a full monitoring stack is disproportionate, or anyone debugging a container host where the process table is the only inventory you have. The output is a live terminal view, and the README notes it is responsive to terminal window size, displaying less information when there is no room for it. That design choice matters more than it sounds: on a narrow split pane or an SSH session from a phone, the tool degrades rather than wrapping into noise.

## Packet sniffing plus process lookup: the actual mechanism

Two data sources are joined at runtime. The first is the capture path: bandwhich sniffs a given network interface with pnet and records IP packet sizes, which is why it needs raw socket and packet capture capabilities. The second is the process path, which is platform-specific and visible in Cargo.toml. On Linux and Android the crate procfs is used, and the README explains the capability split precisely: cap_sys_ptrace and cap_dac_read_search allow access to /proc/<pid>/fd/ so bandwhich can determine which open port belongs to which process, while cap_net_raw and cap_net_admin allow capturing packets at all. On macOS and FreeBSD the dependency is regex, consistent with parsing lsof output; on Windows the dependencies are netstat2 and sysinfo, with WinApi mentioned in the README. Name resolution is a third, softer layer: the README says it attempts to resolve IPs to hostnames in the background using reverse DNS on a best effort basis, and the resolver comes from hickory-resolver. Best effort is the honest word here. If reverse DNS is slow or unavailable, the address column simply stays numeric, and the -n, --no-resolve flag exists to skip the attempt entirely. The UI layer is ratatui with crossterm, and the runtime is tokio with only the rt and sync features enabled, so this is not an async-heavy design; it is a capture loop feeding a rendering loop.

## Installing bandwhich on Ubuntu and other Linux distributions

The README points to INSTALL.md for per-platform instructions and to a repology badge for downstream packaging status, so the package name differs between distributions; check INSTALL.md rather than guessing. The two portable routes are a prebuilt binary from the releases page, which the README lists for Linux x64 and aarch64 with full support and armv7hf on a best effort basis, and building from source. Building is a three-command sequence the README gives directly:

```bash
git clone https://github.com/imsnif/bandwhich.git
cd bandwhich
cargo build --release
```

The README says the minimum supported Rust version is the rust-version field in Cargo.toml, and that field currently reads 1.88.0, so an older toolchain will fail before compilation starts. After installing, Linux needs one of two privilege setups. The recommended one for a single-user machine or a trusted multi-user machine is setcap, which the README gives as:

```bash
sudo setcap cap_sys_ptrace,cap_dac_read_search,cap_net_raw,cap_net_admin+ep $(command -v bandwhich)
bandwhich
```

The README is explicit that this is not recommended if you want to ensure users cannot see others' traffic, because it grants every unprivileged user the same monitoring reach. The alternative is privilege escalation on each run, `sudo bandwhich`, which the README suggests for administrators of multi-user environments. A real trap the README calls out: if bandwhich lives in your home directory, sudo may not preserve your PATH and you get command not found. The documented workarounds include `sudo env "PATH=$PATH" bandwhich` and `sudo $(command -v bandwhich)`.

## A first run, and the flags that change what you see

With privileges settled, the plain invocation is just the binary name, and the README's usage block lists the options that reshape the view. To pin the capture to one interface, for example eth0:

```bash
bandwhich --interface eth0
```

If reverse DNS is adding latency or producing noisy names on a busy network, disable it and read raw addresses:

```bash
bandwhich --no-resolve
```

For scripting or for piping into another tool, the README documents -r, --raw for machine friendlier output. To narrow the display rather than the capture, the README offers -p, --processes for the processes table only, -c, --connections for the connections table only, and -a, --addresses for remote addresses. DNS traffic is hidden by default and shown with -s, --show-dns, and -d, --dns-server takes a DNS server IP to use instead of the system default. Verbosity is adjustable with -v and -q, and --log-to writes debug logging to a file, which is the option to reach for when the display is empty and you need to know whether capture or process lookup failed. On Windows, the README says you might need to install npcap first for packet capture; without it, expect nothing to appear.

## Where bandwhich is the wrong tool

The most concrete limitation is stated by the project itself. The README's project status section says bandwhich is in passive maintenance: critical issues will be addressed, but no new features are being worked on, and the stated reason is a lack of funding or manpower rather than a technical dead end. Pull requests are welcomed, and the README invites long-term contributors to apply for co-maintainership. For an adopter, that translates into a specific risk profile: bug fixes for serious problems are plausible, new platform support or new views are not. The last push to the repository was on 2026-08-01, and the most recent release listed is v0.23.1 from 2024-10-08, so the release cadence is slow even though the tree is not frozen. There are also structural limits. Privileges are required, and the setcap route widens visibility for every user on the machine, which is a poor fit for shared hosts with untrusted accounts. The process attribution depends on the operating system's process and socket tables, so it cannot see traffic that never reaches the local interface in a readable form, and it cannot attribute traffic to a process on another host. Finally, this is a live view, not a recording system: the README documents no retention, export or alerting, and --log-to is described as debug logging, not as a traffic log. If you need historical per-flow data, this is the wrong layer.

## bandwhich versus nethogs, iftop and bmon

The related searches around this project cluster on nethogs, iftop and bmon, and the differences are worth stating plainly rather than treating them as interchangeable. nethogs also attributes bandwidth to processes, which is the closest overlap, but bandwhich additionally breaks traffic down by connection and by remote IP or hostname in the same view, and it resolves those remote addresses through reverse DNS. iftop is oriented around host pairs and the flows between them; it answers who you are talking to, not which local process is doing the talking, so it is the better pick when the question is about a remote peer and the worse pick when the question is about a local culprit. bmon is an interface-level monitor: it shows throughput per interface and is useful for capacity questions, but it does not join traffic to a process table at all. bandwhich's distinguishing move is that join, and its cost is the privilege requirement that comes with reading /proc/<pid>/fd/ and capturing packets. If you cannot grant those capabilities, the process column is exactly what you lose.

## Maintenance cost, licensing and what to check before you commit

The maintenance picture is the deciding factor for most teams. The README states passive maintenance in plain terms, and the repository's last push on 2026-08-01 confirms it is not abandoned, but the gap between that push and the v0.23.1 release of 2024-10-08 tells you releases are infrequent. Upgrade cost is low in practice: it is a single static binary, installed either from a distribution package, a release artifact or cargo build --release, and there is no daemon, no database and no configuration file to migrate. The one version-sensitive item is the Rust toolchain floor, rust-version = "1.88.0" in Cargo.toml, which only matters if you build from source; binary users never see it. On licensing, the Cargo.toml declares license = "MIT" and the repository carries LICENSE.md, which is permissive and imposes no copyleft obligation on your own code. That is the extent of what can be said here; whether MIT satisfies a particular corporate policy or redistribution plan is a question for your own legal review, not something the repository answers. The dependency tree is ordinary for a Rust CLI of this kind (clap, ratatui, crossterm, tokio, pnet), but note that Cargo.toml lists a dev-dependency pulled from a git URL, which matters only if you run the test suite.

## Conclusion

Adopt bandwhich if you want a single terminal view that answers which process is using the link right now, and if you are comfortable granting packet-capture capabilities or running it under sudo. Do not adopt it if you need per-flow history, alerting or a maintained feature roadmap, because the README states the project is in passive maintenance and only critical issues will be addressed. Before rolling it out, verify three things on your own machines: that your kernel and Rust toolchain meet the rust-version = "1.88.0" floor if you build from source, that setcap cap_sys_ptrace,cap_dac_read_search,cap_net_raw,cap_net_admin+ep succeeds on the installed binary, and that on Windows npcap is already present.

## FAQ

### What is a free tool for monitoring bandwidth per process?

bandwhich is released under the MIT licence and displays current network utilization by process, connection and remote IP or hostname from the terminal. It is free to install from prebuilt release binaries or by building from source with cargo.

### What is bandwidth utilization, in the sense bandwhich measures it?

bandwhich records IP packet sizes on a chosen network interface and joins them to the local process that owns the socket, so the utilization it shows is per process, per connection and per remote address rather than one interface total.

### How do I check network bandwidth with bandwhich?

Run bandwhich with the interface you want to watch, for example bandwhich --interface eth0, and it will sniff that interface and cross-reference the traffic against the process table. On Linux it needs elevated privileges, either granted once with setcap or supplied per run with sudo.

## Sources

- [imsnif/bandwhich on GitHub](https://github.com/imsnif/bandwhich)
- [Issues](https://github.com/imsnif/bandwhich/issues)
- [License: MIT](https://github.com/imsnif/bandwhich/blob/main/LICENSE)
- [README](https://github.com/imsnif/bandwhich/blob/main/README.md)
- [Releases](https://github.com/imsnif/bandwhich/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imsnif-bandwhich