pythops/oryx: an eBPF traffic sniffer that lives in your terminal

What oryx does that tcpdump on its own does not

tcpdump gives you a stream of packets and leaves the aggregation to you. Oryx sits in the same niche but presents the result as a terminal interface with panes for live traffic, traffic statistics, a metrics explorer and a firewall view. The README lists those four as features, plus fuzzy search over what is on screen. The target user is someone who already has a shell open on a Linux box and wants to see which flows are active, how much each is moving, and which addresses are talking, without piping output into awk. The supported protocol list is broad for a tool this size: TCP, UDP and SCTP at the transport layer, IPv4 and IPv6, ICMPv4 and ICMPv6, IGMP v1 through v3, and ARP at the link layer. That is a deliberate scope choice. It covers the protocols an operator is likely to see on a normal host, and it leaves out application-layer dissection entirely. If you need to read HTTP headers or reassemble a TLS session, oryx is not that tool and the README does not claim otherwise.

How the eBPF side is wired into the Rust workspace

The repository is a Cargo workspace. Cargo.toml lists three members: xtask, oryx-tui and oryx-common. A fourth directory, oryx-ebpf, is present at the top level but is not a workspace member, which fits the usual Aya layout where the eBPF crate is compiled for the BPF target by a separate build step rather than by the host workspace. The build command in the README, cargo xtask build --release, is what drives that step. So the data flow is: eBPF programs loaded into the kernel collect events, the userspace side in oryx-tui consumes them, and the ratatui interface renders them. The workspace pins network-types at version 0.2 with default-features disabled, which suggests packet header parsing is shared between the kernel-side and userspace code. The release profile is tuned for a small binary: opt-level 3, fat LTO, codegen-units 1, panic set to abort. That combination costs build time and buys a smaller, faster artifact. The README does not say which hooks the eBPF programs attach to, so treat the exact attach points as something to read in oryx-ebpf before you rely on them.

Installing oryx and running a first capture

There are three documented routes. The README points to the GitHub release page for prebuilt binaries, Arch users can install from the extra repository, and anyone else builds from source. On Arch, pacman handles it:

pacman -S oryx

Building from source needs a nightly Rust toolchain with the rust-src component, and bpf-linker. The README gives the toolchain command directly:

rustup toolchain install nightly --component rust-src

bpf-linker is not installed by a command in this README. It links to the installation section of the aya-rs/bpf-linker repository and expects you to follow that. Once both are in place, the build is a single xtask invocation:

cargo xtask build --release

The README states this produces an executable at target/release/oryx, which you copy into a directory on your PATH. To start it, run it as root:

sudo oryx

The README notes that oryx accepts arguments as well and points at oryx --help for the available options. It does not list those options, so the help output is the only place to find them. One practical detail before you start: the README warns that nerdfonts may be needed for the icons to render correctly. On a terminal without a patched font you will see placeholder glyphs rather than the intended layout.

Kernel version is the real gate, not the install method

The README states that a Linux kernel of 6.10 or higher is ideal "to ensure all the features to work properly". That wording matters. It does not say oryx refuses to start on older kernels, and it does not enumerate which features degrade. The documented distribution floors follow the same line: Debian 13 (Trixie) or newer, Ubuntu 24.04 (Noble) or newer. If you are on an older kernel, the honest position is that the README does not tell you what breaks. That is the first thing to verify on your own hardware before rolling it out anywhere. The second constraint is privilege. The documented start command is sudo oryx, which is consistent with loading eBPF programs and reading traffic. There is no documented unprivileged mode, no capability list, and no systemd unit in the README. Running a network sniffer as root on a production host is a decision, not a default, and the README does not help you narrow it. The third constraint is platform: this is Linux only. There is no macOS or Windows path anywhere in the README, and eBPF is a Linux kernel feature, so there will not be one.

Firewall features and where the documentation stops

The feature list includes "Firewall functionalities", and the repository topics include firewall alongside sniffing and observability. That is the most interesting and least documented part of the project. The README does not say whether the firewall view drops packets, blocks addresses, or only reports what it sees. It does not describe persistence, rule syntax, or whether anything survives a restart. Given that this is a TUI rather than a daemon with a config file, the likely reading is that any blocking is session-scoped and lives only as long as the process, but the README does not confirm that, and you should not assume it. If you are evaluating oryx as a firewall, treat that as unverified. If you are evaluating it as a sniffer that happens to expose some blocking controls, the risk is lower. The same gap applies to the metrics explorer: the feature is named, but what metrics are exposed and where they come from is not described.

How oryx differs from bandwhich and from Kyanos

Bandwhich is the closest comparison that people actually search for. It is also a terminal bandwidth monitor that maps traffic to processes, and it is written in Rust as well. The difference in approach is what the README of oryx emphasises: a broader protocol list including SCTP, IGMP and ARP, plus firewall actions and a metrics explorer on top of the traffic view. Bandwhich's focus is per-process bandwidth accounting. If your question is "which process is using the link", bandwhich answers it more directly. If your question is "what is on the wire and what can I do about it from here", oryx is the wider tool. Kyanos is the other name that comes up, and it is also an eBPF-based network observability tool for Linux. The README here does not describe Kyanos in any detail, so the fair statement is that both sit in the eBPF observability space and you should compare their protocol coverage and output formats against your own use case rather than trusting a feature list. One thing oryx has that neither comparison implies: a stated contribution policy of "Strict No LLM", with PRs expected to follow a prior issue or discussion and to stay small. That shapes what the project will accept, not what it does.

Licence and the cost of staying current

Oryx is GPL-3.0, stated in both the README and the workspace Cargo.toml. That is a copyleft licence. If you are embedding oryx in a product, or shipping a modified binary, the GPL-3.0 obligations apply to the combined work, and that is a question for your own legal review rather than something this article can settle. For internal use on your own hosts, the practical effect is that you can run it freely and you must publish source if you redistribute a modified version. On maintenance: the last push to the repository was on 2026-09-01, and the most recent release listed is v0.8.0 from 2026-02-04. The workspace version is 0.8.0, matching that release. There is a Release.md file at the top level, which suggests a documented release process. The upgrade path differs by install method. Arch users get new versions through pacman with the rest of their system. Binary-release users re-download from the release page. Source builders re-run the xtask build, which with fat LTO and codegen-units 1 is not a fast compile, and they carry the nightly toolchain and bpf-linker as ongoing prerequisites rather than one-time setup.

Editorial conclusion

Oryx suits Linux sysadmins and security engineers on kernel 6.10 or newer who want live traffic and per-flow statistics in a terminal and are comfortable running a root-owned binary. It is the wrong tool if you need packet capture files for later analysis, if you are on an older kernel, or if you cannot build the eBPF side yourself on a distribution without a package. Before adopting it, check the release page for a prebuilt binary matching your architecture, confirm uname -r reports 6.10 or higher, and read the firewall section of the TUI to see which actions it exposes on your kernel.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pythops/oryx on GitHub
4. README
5. Releases