bmon bandwidth monitoring with curses, JSON, and rate estimation

bmon's scope for live bandwidth diagnostics

bmon addresses a narrow but common operational task: observing network interface activity while it happens. It is aimed at administrators, developers, and engineers who need to inspect incoming and outgoing rates from a terminal, investigate traffic behavior, or feed measurements into a script. The README describes it as a "monitoring and debugging tool" that captures networking statistics and presents them in a human-friendly form.

The project is not positioned as a complete network observability platform. Its documented outputs focus on an interactive curses interface and programmable text output. The 5.0 release notes also identify JSON output, but the README does not provide a JSON configuration example or a complete schema. That distinction matters. bmon can help answer what an interface is doing now, while the README does not establish that it retains history, defines alerts, correlates traffic across hosts, or provides long-term reporting.

The strongest fit is therefore an engineer at a shell prompt who wants a compact network diagnostic. Its native C implementation also fits systems where installing a graphical monitoring client would be unnecessary. For automated collection, the programmable output is the relevant feature, but users should first confirm which output configuration and field format they require.

bmon collection modules and presentation outputs

Based on the repository layout and release notes, bmon separates network statistics collection from presentation. Source code is organized under `src/`, public headers under `include/`, manual documentation under `man/`, and example configuration files under `examples/`. The `examples/bmon.conf` file is the documented place to investigate configuration, although its contents are not reproduced in the README.

The release notes explicitly name a Netlink module. They also mention IPv4 and IPv6 addresses in additional information and a configure option for disabling IPv6 in that module. This indicates that bmon can obtain more than an undifferentiated byte count when its collection and output configuration expose the relevant fields. The README does not describe every collection backend, polling interval, counter normalization rule, or rate-estimation formula, so those details should not be inferred from the repository categories alone.

Presentation is more clearly documented. The curses interface provides live graphs and interactive controls. Version 5.0 added `CTRL-N` and `CTRL-P` for moving to the next or previous element, ingress and egress traffic control filters, and graph rendering with Braille cells. Text output is intended for scripting, and JSON output is explicitly supported in 5.0. This makes output choice a practical design boundary: curses suits direct inspection, while text or JSON can feed another program. The README does not state whether output modules can run concurrently or how output buffering behaves.

Installing bmon from source on Debian or Ubuntu

The README documents a source build for Debian and Ubuntu. It requires a C build toolchain plus libraries for configuration, Netlink, ncurses, package metadata, and Debian's autotools helper. Clone the repository, install those dependencies, generate the configure script, build, install, and start the default curses interface with the following commands:

git clone https://github.com/Jafaral/bmon.git
cd bmon
apt-get install build-essential make libconfuse-dev libnl-3-dev libnl-route-3-dev libncurses-dev pkg-config dh-autoreconf
./autogen.sh
./configure
make
make install
bmon

The final command starts bmon in its default curses mode. If the program opens to its live terminal interface, that matches the README's basic usage instruction. The documented commands do not show the expected compiler output or terminal screenshots in text, so successful installation should be judged by reaching `bmon` without a build or startup error.

The README also provides shorter package-manager routes where supported. CentOS 7 uses `yum install bmon`, while Fedora uses `dnf install bmon`. On macOS, Homebrew provides `brew install bmon`. Those paths may be preferable when an organization already manages operating-system packages. The source route is more relevant when the exact 5.0 release or a configure choice is needed.

Starting bmon and checking available options

A first interactive session requires only `bmon`. Before relying on it in a script, use the documented help entry point to inspect options available in the installed build:

bmon --help

The README states that full help is available through this command but does not reproduce its output. It would be misleading to invent flags for selecting interfaces, changing output modules, or writing files. The repository includes an example configuration at `examples/bmon.conf`, but the README does not explain its keys. Users needing nondefault collection or output should inspect `bmon --help` and that example file in the installed source tree rather than assume a generic network-monitor interface.

The curses interface is the default and is intended for live observation. Version 5.0 notes identify `CTRL-N` and `CTRL-P` for element navigation and describe filters for traffic control ingress and egress. These additions matter on Linux systems where traffic is classified into traffic control elements, because they provide a more focused view than a single aggregate line. The README does not state whether the same controls are available on every platform or every curses terminal.

JSON output limits and script integration

JSON support is the most relevant automation change in bmon 5.0. It gives scripts a structured alternative to the documented programmable text output. The release notes confirm the feature, but they do not supply field names, event types, serialization settings, buffering behavior, or an example command. Consequently, the release notes establish that JSON output exists, not that it covers every statistic shown by the curses interface.

This limitation affects adoption. A script author should not treat JSON availability as proof of a stable public schema. Before depending on the output, inspect the 5.0 configuration documentation and determine whether timestamps, interface names, IPv4 and IPv6 addresses, traffic control elements, rates, and counters are present as expected. It is also necessary to confirm how repeated measurements are represented, whether partial writes are possible, and whether the process flushes output promptly for a consumer.

bmon is better suited to a live command pipeline than to retrospective analysis unless another tool records its output. The README says programmable text output supports scripting, and version 5.0 adds JSON, but it does not describe retention, database storage, aggregation, alert rules, remote collection, or query APIs.

Platform constraints, licensing, and upgrade work

bmon depends on native networking and terminal libraries. The Debian and Ubuntu build requires libconfuse, libnl, ncurses, `pkg-config`, and related build tools. The macOS source instructions first require building libconfuse 2.8 from its release archive. This makes installation more involved on platforms without a package-managed bmon release. The 5.0 notes also document fixes for FreeBSD, DragonFlyBSD, and OpenBSD builds, while GitHub Actions builds cover Linux, macOS, and FreeBSD.

The repository metadata classifies the license as a custom type, but the README directs readers to two named files, `LICENSE.BSD` and `LICENSE.MIT`. That is enough to identify the files requiring review, but not enough to provide legal interpretation or guarantee how a particular distribution combines them. Organizations should read both files and the repository's copyright notices before redistribution. Copyright notices include Thomas Graf from 2001 to 2016, Red Hat in 2013, and Architecture Technology Corporation in 2026.

The last push was on 2026-09-19, and version 5.0 was released on 2026-09-15. That indicates recent project activity and a substantial gap from version 4.0 on 2016-12-13, so an upgrade from an older deployment should be treated as a version jump rather than a routine patch. The release notes show a wide range of build fixes, interface changes, memory fixes, and output additions, which means configuration and script compatibility should be checked directly.

Editorial conclusion

Adopt bmon for interactive terminal bandwidth inspection and script-friendly rate reporting, especially on hosts where a C utility is preferable to a larger monitoring stack. Do not choose it solely as a long-term metrics database or alert platform because the README does not describe either function. Before deployment, verify the exact JSON configuration, permitted modules and interfaces, licensing obligations in `LICENSE.BSD` and `LICENSE.MIT`, and compatibility with the operating system version being managed.

Frequently asked questions

Official sources

1. Issues
2. Jafaral/bmon on GitHub
3. Project website
4. README
5. Releases