LuCI Bandix: per-device traffic monitoring inside OpenWrt

The problem: knowing which device on the LAN is eating bandwidth

A home router knows the total traffic crossing it. It rarely tells you which laptop, television, or camera is responsible. That gap matters on a connection with a data cap, on a shared home network with several people, and on any router where someone keeps complaining that the internet feels slow. LuCI Bandix answers it from inside the router, through the LuCI web interface you already use to configure OpenWrt. The application is described as a network traffic monitoring application for OpenWrt, providing traffic data visualisation and analysis through LuCI, and the intended users are stated plainly: it is primarily designed for home users and simple network environments. The project also ships a Simplified Chinese README and an architecture document, and the code is JavaScript for the frontend with the heavy lifting in a separate backend service.

Two packages: the LuCI frontend and the openwrt-bandix backend

This is not a single application, and that is the first thing to understand. LuCI Bandix is developed based on the LuCI framework and depends on the openwrt-bandix backend service, which is what actually collects and stores the traffic data. The frontend you install from this repository is only the web interface that visualises it. The collection engine is described as a high-performance implementation based on Rust eBPF, which is why the system requirements list a Linux kernel of 6.x and above: eBPF based traffic accounting needs a recent kernel. The repository root contains the frontend package directory luci-app-bandix along with the ARCHITECTURE.md document and a docs folder with screenshots, while the backend lives in its own repository with its own releases. The two are versioned together, and that coupling is the source of the main installation gotcha discussed later.

Installing the backend and the frontend as separate packages

Installation is a two step download and install. The backend comes first, from the openwrt-bandix releases page, where you pick the package for your device architecture:

opkg install bandix_latest_architecture.ipk  # (or apk add --allow-untrusted bandix_latest_architecture.apk)

Then the frontend, from the luci-app-bandix releases page:

opkg install luci-app-bandix_latest_all.ipk  # (or apk add --allow-untrusted luci-app-bandix_latest_all.apk)

The apk alternative is noted inline for the newer package format used by recent OpenWrt builds. The frontend package name ends in all because it is architecture independent, while the backend package carries your device architecture in the file name. Both installs may pull in dependencies. The frontend requires curl as an HTTP client library for network requests, luci-lib-jsonc as a JSON parsing library for data processing, jsonfilter as a JSON query tool for filtering and extracting data, and jshn as a JSON shell library for shell script JSON operations. The documentation notes these are installed automatically, but that some firmware may require installing them by hand.

Turning off flow offloading and enabling the LAN interface

Two configuration steps decide whether you see anything at all. The first is a prerequisite stated as important in the project documentation: you must disable hardware flow offloading and Turbo ACC in OpenWrt before using this application. That is not a performance tweak, it is a requirement, because flow offloading bypasses the path where per-flow accounting happens, and hardware offloading in particular hands packets to a dedicated chip that the eBPF collector never sees. The second step happens after installation. You reach the Bandix application through the LuCI web interface under the Network menu, then go to the Bandix settings page and select your LAN interface to enable proper monitoring, and you must make sure the Enable option is checked so the service actually starts. If the graphs stay empty, those two items are the first things to check, in that order.

Per-device quotas with automatic blocking

The feature list is where the project differs from a simple traffic graph. Beyond real-time monitoring and an intuitive visualisation interface, it supports per-device minute, hourly, daily, weekly, monthly, and lifetime WAN traffic quotas with automatic blocking. That is the headline capability: a quota is not just a report, it cuts the device off when the allowance is used. Around that sit several features that make the data usable rather than merely visible. Host names are obtained automatically from DHCP and DNS, specifically from static leases, so the device list shows names instead of a wall of IP addresses. The app can monitor LAN and WAN speed separately, count the TCP and UDP connections of a device, and apply WAN speed limitation. IPv4 and IPv6 are both supported, data is stored persistently, and monitoring is available in real time, daily, weekly, and monthly views, with historical traffic trends and charts. DNS query monitoring and statistical analysis are included, which answers questions about which host is being looked up rather than which host is downloading.

The boundary: single interface, home networks, no VLAN

The project states its own limits, which is unusual and useful. A banner at the top of the documentation recommends LuCI Bandix for single-interface setups and points to a separate project, LuCI Bandix Plus, for multi-interface support. The introduction adds that the application is primarily designed for home users and simple network environments, and that it is not recommended for complex network architectures such as VLAN or for enterprise-level deployments. That is a meaningful constraint, because per-device accounting with eBPF and a single monitored LAN interface assumes a flat home network with a clear WAN edge. If you run tagged VLANs, multiple uplinks, or a routed enterprise topology, the accounting model and the interface selection in the settings page will not match how traffic actually flows, and you will be reading numbers that describe only part of your network. The system requirements also set a floor: Linux kernel 6.x and above, with OpenWrt 24.10 and above recommended.

Version pairing, release cadence, and the licence

Because the frontend and the backend are separate packages, their versions have to match, and the documentation publishes a table for exactly that. The 0.10.x frontend requires the 0.10.x backend, 0.11.x requires 0.11.x, and 0.12.x requires 0.12.x, with the instruction to install matching versions to ensure compatibility and proper functionality. Mixing a newer frontend with an older backend is the most likely cause of an install that appears to succeed and then shows nothing. The release cadence is quick, with v0.12.12 released on 2026-09-28, v0.12.11 on 2026-09-06, and v0.12.10 on 2026-08-18, and the last push was on 2026-09-28, so the project is actively worked on and the pairing table is likely to keep growing new rows. Licensing is Apache 2.0 with the LICENSE file in the repository root, which is permissive for both personal and commercial use provided the notice is retained. The project is maintained by timsaya and smallprogram, and issues and discussions happen in the GitHub repository.

Editorial conclusion

LuCI Bandix fits home users on a single-interface OpenWrt router who want to see which device is using bandwidth and to cap monthly traffic per device. It is the wrong tool for VLAN based or enterprise networks, which the project itself says it is not recommended for, and the wrong tool if your router relies on hardware flow offloading, since the documentation requires disabling it. Before installing, check that your kernel is 6.x or newer and that OpenWrt is 24.10 or above, install matching openwrt-bandix and luci-app-bandix versions from the version dependency table, and confirm your firmware can pull in curl, luci-lib-jsonc, jsonfilter, and jshn.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. timsaya/luci-app-bandix on GitHub