[PR #767] Add rustnet to Troubleshooting #5878

New Issue

GiteaMirror · 2026-05-02T17:16:46-05:00

GiteaMirror commented

2026-05-02 17:16:46 -05:00

📋 Pull Request Information

Original PR: https://github.com/awesome-foss/awesome-sysadmin/pull/767
Author: @domcyrus
Created: 4/22/2026
Status: 🔄 Open

Base: master ← Head: add-rustnet

📝 Commits (1)

fe565d2 Add rustnet to Troubleshooting

📊 Changes

1 file changed (+1 additions, -0 deletions)

View changed files

📝 README.md (+1 -0)

📄 Description

Thank you for taking the time to work on a PR for Awesome-Sysadmin!

To ensure your PR is dealt with swiftly please check the following:

Your additions are Free software
Software you are submitting is not your own, unless you have a healthy ecosystem with a few contributors (which aren't your sock puppet accounts).
Submit one item per pull request. This eases reviewing and speeds up inclusion.
Format your submission as follows, where Demo and Clients are optional.
Do not add a duplicate Source code link if it is the same as the main link.
Keep the short description under 80 characters and use sentence case
for it, even if the project's webpage or readme uses another capitalisation.
Demo links should only be used for interactive demos, i.e. not video demonstrations.
- [Name](http://homepage/) - Short description, under 250 characters, sentence case. ([Demo](http://url.to/demo), [Source Code](http://url.of/source/code), [Clients](https://url.to/list/of/related/clients-or-apps)) `License` `Language`
Additions are inserted preserving alphabetical order.
Additions are not already listed at awesome-selfhosted
The Language tag is the main server-side requirement for the software. Don't include frameworks or specific dialects.
You have searched the repository for any relevant issues or PRs, including closed ones.
Any category you are creating has the minimum requirement of 3 items.
Any software project you are adding to the list is actively maintained.
The pull request title is informative, unlike "Update README.md".
Suggested titles: "Add aaa to bbb" for adding software aaa to section bbb,
"Remove aaa from bbb" for removing, "Fix license for aaa", etc.

Please take some time to answer the following questions as best you can:

Why is it awesome?

It fills a real gap between netstat/ss (which show sockets but no live traffic) and Wireshark/tcpdump (which show packets but not which process owns them). rustnet combines packet capture with OS-level socket introspection which e.g. is using eBPF on Linux, /proc fallback, and platform APIs on macOS(PKTAP)/Windows/FreeBSD. This ensures that every connection is attributed to its owning process, with built-in deep packet inspection (HTTPS/TLS with SNI extraction, DNS, SSH, QUIC, DHCP, mDNS, SNMP). It's a TUI and therefore it also runs cleanly over SSH on headless servers.

Have you used it? For how long?

Yes, I've been building and using it since April 2025, about a year. Daily use as my default tool for "what is this machine actually talking to right now."

Is this in a personal or professional setup?

Both. Personally: debugging home network issues, investigating device traffic, identifying noisy processes. Professionally: diagnosing connection problems on servers and containers, auditing what a given service is opening connections to.

How many devices/users/services/... do you manage with it?

As the author I'll answer this in terms of adoption signals rather than personal deployments, since the question is really aimed at users:

~2,000 GitHub stars, 63 forks
Independent write-ups: NetBeez, OSTechNix
Third-party Nix derivation (isomarcte/rustnet-nix) packaged by someone outside the project
Arch linux (https://archlinux.org/packages/extra/x86_64/rustnet/) packaged by someone outside the project
21 releases, last v1.2.0 on 2026-04-09
Companion projects: kubectl-rustnet for running it as a debug pod on Kubernetes nodes
Biggest pros/cons compared to other solutions?

Pros:

Per-process attribution + DPI in one tool. iftop/nethogs do bandwidth-per-process but no protocol detail; Wireshark does protocol detail but no process attribution; bandwhich is closest in spirit but narrower in scope and Linux/macOS only
Cross-platform (Linux, macOS, Windows, FreeBSD)
Runs over SSH (no GUI required)
Sandboxing: macOS Seatbelt, Linux build uses Landlock sandboxing to restrict the process's filesystem access

Cons:

Younger than decades-old alternatives
Parses fewer protocols than Wireshark, it's a live-monitoring tool, not a full protocol analyzer
Not a replacement for deep post-capture analysis workflows but can be used together with wireshark and rustnet pcap output with additional process information
Any other comments about your use case, things you've found excellent, limitations you've encountered... ?

Things I've found really useful in day-to-day use:

Process attribution has surfaced surprises more than once. A daemon beaconing somewhere I didn't expect, an app making TLS connections to a CDN I hadn't authorized. Much faster than correlating ss -tnp output with packet captures by hand.
SNI extraction from TLS handshakes answers "which host is this encrypted connection actually going to" without needing a full protocol analyzer. Useful on endpoints where installing Wireshark isn't practical.
On macOS there are two paths. Running with sudo uses PKTAP, which is faster and gives accurate process identification. If you don't want to run as root, joining the access_bpf group (via Wireshark's ChmodBPF helper or dseditgroup) lets it run unprivileged, falling back to lsof for process attribution. Both work; PKTAP is the better one when you have the permission for it.
The vim/fzf-style filter syntax scales well. Narrowing to a specific process, port, or remote host takes a few keystrokes.
Same binary works on a Mac laptop and on Linux servers, so muscle memory carries over.

Limitations I've hit:

Linux eBPF path gives the best process attribution. Older kernels fall back to /proc scraping, which can miss very short-lived connections.
It's a live-monitoring tool, not a long-term recorder. Limited built-in historical retention (5000 connections), though the pcap output pairs well with Wireshark for post-capture analysis (with the bonus of process information that plain pcap doesn't carry).
GeoIP lookups need a MaxMind DB path configured. Off by default.
QUIC state tracking is best-effort. Connection migration across network paths isn't perfectly followed.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/awesome-foss/awesome-sysadmin/pull/767 **Author:** [@domcyrus](https://github.com/domcyrus) **Created:** 4/22/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `add-rustnet` --- ### 📝 Commits (1) - [`fe565d2`](https://github.com/awesome-foss/awesome-sysadmin/commit/fe565d24b3db7ea6a92c04e45a1169724f3ea0e4) Add rustnet to Troubleshooting ### 📊 Changes **1 file changed** (+1 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+1 -0) </details> ### 📄 Description Thank you for taking the time to work on a PR for Awesome-Sysadmin! To ensure your PR is dealt with swiftly please check the following: - [x] Your additions are [Free software](https://en.wikipedia.org/wiki/Free_software) - [x] Software you are submitting is not your own, unless you have a healthy ecosystem with a few contributors (which aren't your sock puppet accounts). - [x] Submit one item per pull request. This eases reviewing and speeds up inclusion. - [x] Format your submission as follows, where `Demo` and `Clients` are optional. Do not add a duplicate `Source code` link if it is the same as the main link. Keep the short description under 80 characters and use [sentence case](https://en.wikipedia.org/wiki/Letter_case#Sentence_case) for it, even if the project's webpage or readme uses another capitalisation. `Demo` links should only be used for interactive demos, i.e. not video demonstrations. ``- [Name](http://homepage/) - Short description, under 250 characters, sentence case. ([Demo](http://url.to/demo), [Source Code](http://url.of/source/code), [Clients](https://url.to/list/of/related/clients-or-apps)) `License` `Language` `` - [x] Additions are inserted preserving alphabetical order. - [x] Additions are not already listed at [awesome-selfhosted](https://awesome-selfhosted.net) - [x] The `Language` tag is the main **server-side** requirement for the software. Don't include frameworks or specific dialects. - [x] You have searched the repository for any relevant [issues](https://github.com/awesome-foss/awesome-sysadmin/issues) or [PRs](https://github.com/awesome-foss/awesome-sysadmin/pulls), including closed ones. - [x] Any category you are creating has the minimum requirement of 3 items. - [x] Any software project you are adding to the list is actively maintained. - [x] The pull request title is informative, unlike "Update README.md". Suggested titles: "Add aaa to bbb" for adding software aaa to section bbb, "Remove aaa from bbb" for removing, "Fix license for aaa", etc. -------------- Please take some time to answer the following questions as best you can: - **Why is it awesome?** It fills a real gap between `netstat`/`ss` (which show sockets but no live traffic) and Wireshark/`tcpdump` (which show packets but not which process owns them). rustnet combines packet capture with OS-level socket introspection which e.g. is using eBPF on Linux, `/proc` fallback, and platform APIs on macOS(PKTAP)/Windows/FreeBSD. This ensures that every connection is attributed to its owning process, with built-in deep packet inspection (HTTPS/TLS with SNI extraction, DNS, SSH, QUIC, DHCP, mDNS, SNMP). It's a TUI and therefore it also runs cleanly over SSH on headless servers. - **Have you used it? For how long?** Yes, I've been building and using it since April 2025, about a year. Daily use as my default tool for "what is this machine actually talking to right now." - **Is this in a personal or professional setup?** Both. Personally: debugging home network issues, investigating device traffic, identifying noisy processes. Professionally: diagnosing connection problems on servers and containers, auditing what a given service is opening connections to. - **How many devices/users/services/... do you manage with it?** As the author I'll answer this in terms of adoption signals rather than personal deployments, since the question is really aimed at users: - ~2,000 GitHub stars, 63 forks - Independent write-ups: [NetBeez](https://netbeez.net/blog/rustnet/), [OSTechNix](https://ostechnix.com/rustnet-real-time-network-monitoring-tui/) - Third-party Nix derivation ([isomarcte/rustnet-nix](https://github.com/isomarcte/rustnet-nix)) packaged by someone outside the project - Arch linux (https://archlinux.org/packages/extra/x86_64/rustnet/) packaged by someone outside the project - 21 releases, last v1.2.0 on 2026-04-09 - Companion projects: `kubectl-rustnet` for running it as a debug pod on Kubernetes nodes - **Biggest pros/cons compared to other solutions?** Pros: - Per-process attribution + DPI in one tool. `iftop`/`nethogs` do bandwidth-per-process but no protocol detail; Wireshark does protocol detail but no process attribution; `bandwhich` is closest in spirit but narrower in scope and Linux/macOS only - Cross-platform (Linux, macOS, Windows, FreeBSD) - Runs over SSH (no GUI required) - Sandboxing: macOS Seatbelt, Linux build uses Landlock sandboxing to restrict the process's filesystem access Cons: - Younger than decades-old alternatives - Parses fewer protocols than Wireshark, it's a live-monitoring tool, not a full protocol analyzer - Not a replacement for deep post-capture analysis workflows but can be used together with wireshark and rustnet pcap output with additional process information - **Any other comments about your use case, things you've found excellent, limitations you've encountered... ?** Things I've found really useful in day-to-day use: - Process attribution has surfaced surprises more than once. A daemon beaconing somewhere I didn't expect, an app making TLS connections to a CDN I hadn't authorized. Much faster than correlating `ss -tnp` output with packet captures by hand. - SNI extraction from TLS handshakes answers "which host is this encrypted connection actually going to" without needing a full protocol analyzer. Useful on endpoints where installing Wireshark isn't practical. - On macOS there are two paths. Running with sudo uses PKTAP, which is faster and gives accurate process identification. If you don't want to run as root, joining the `access_bpf` group (via Wireshark's ChmodBPF helper or `dseditgroup`) lets it run unprivileged, falling back to `lsof` for process attribution. Both work; PKTAP is the better one when you have the permission for it. - The vim/fzf-style filter syntax scales well. Narrowing to a specific process, port, or remote host takes a few keystrokes. - Same binary works on a Mac laptop and on Linux servers, so muscle memory carries over. Limitations I've hit: - Linux eBPF path gives the best process attribution. Older kernels fall back to `/proc` scraping, which can miss very short-lived connections. - It's a live-monitoring tool, not a long-term recorder. Limited built-in historical retention (5000 connections), though the pcap output pairs well with Wireshark for post-capture analysis (with the bonus of process information that plain pcap doesn't carry). - GeoIP lookups need a MaxMind DB path configured. Off by default. - QUIC state tracking is best-effort. Connection migration across network paths isn't perfectly followed. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-02 17:16:46 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-sysadmin#5878