# Sniffnet reads packets with pcap and draws with iced, and those break separately

> Sniffnet is a Rust desktop monitor for the traffic crossing one network adapter, built on libpcap with an iced interface. Its dependency manifest is unusually honest about what breaks where: capture, rendering, system libraries and package architecture are four separate failure points, and the README names each one.

**GyulyVGC/sniffnet** — GitHub describes it as Comfortably monitor your network traffic 🕵️‍♂️. The repository metadata lists Rust as its primary language. The metadata lists the Apache-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/GyulyVGC/sniffnet
- Website: https://sniffnet.app
- Stars: 41,310 · Forks: 1,965
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/gyulyvgc-sniffnet

## pcap captures, iced draws, and the two fail for different reasons

The dependency list in Cargo.toml separates the parts of this application cleanly. pcap does the capture, listeners 0.6.1 enumerates the network interfaces you can choose from, and iced 0.14.0 with the tokio, svg, advanced, lazy and image features is the interface. On top of that sit dns-lookup 4.0.1 for host names, maxminddb 0.32.0 for geographical location, nom 8.0.0 and phf 0.14.0 alongside services.txt for identifying upper layer services, confy 2.0.0 for stored settings, clap 4.6.6 for arguments, ctrlc for a clean exit and async-channel for the plumbing between capture and draw.

That split is the design. Where Wireshark dissects individual packets field by field, Sniffnet aggregates: connections in your local network, the domain and ASN of remote hosts, which programs are generating bandwidth, and a service list the README puts at more than 6000 entries covering protocols, trojans and worms. The two tools meet at one point, because capture reports can be imported and exported as PCAP files.

The cost of the split is that a bug report has to name which half failed.

## The wgpu renderer is the part that fails on old graphics drivers

The rendering section of the troubleshooting notes is specific about a failure that has nothing to do with packets. In some circumstances, especially on an old architecture or with graphical drivers that are not updated, the wgpu default renderer used by iced may misbehave. The symptoms it names are an interface that glitches and colour gradients that are not supported.

Read that as a boundary on where this application can run. The capture side needs libpcap and a network adapter. The draw side needs a graphics stack that wgpu can talk to. A headless server, a virtual machine without a passed-through GPU, or a workstation running an old card can satisfy the first requirement and fail the second, and the failure will look like a rendering bug rather than a capture bug.

The application keeps working while minimised, so the window is not torn down, but it is still a window. There is no text mode, no report-only mode and no daemon described anywhere in the repository.

## Prebuilt binaries still need libpcap, libasound2 and libfontconfig1

A download from the releases page is not a self-contained program. The note under the download table says to also install the required dependencies for your operating system, and the troubleshooting section says most errors that may arise are likely due to a system missing the dependencies required to correctly analyze a network adapter.

The Dockerfile is where the actual list is visible, because the runtime stage installs libpcap0.8, libasound2 and libfontconfig1, and the builder stage installs the matching development packages libpcap-dev, libasound2-dev and libfontconfig1-dev along with pkg-config. Those are the three libraries, and the wiki page named Required dependencies is where the per operating system instructions live.

Two details explain why the font library is there at all. The crate's include list ships resources/fonts/subset/*.ttf, a subset of fonts baked into the binary, and resources/sounds/*.mp3, so a machine without libfontconfig1 installed has binary data it cannot use. That is the class of error the note is warning about, and it is why a flat package or an AppImage can still refuse to start.

## RPM covers two architectures while DEB and AppImage cover four

The download table is worth reading as a matrix, because the coverage is not uniform. Windows has three MSI files: x64, arm64 and x86. macOS has two DMG files, one for Intel and one for Apple silicon. Linux DEB has four, for amd64, arm64, i386 and armhf. AppImage also has four, for the same set.

RPM is the outlier with two, for x86_64 and aarch64. So an i386 or armhf machine, which has a DEB and an AppImage waiting for it, has no RPM, and an aarch64 machine has every format while an x86 machine has no 32-bit RPM.

For anyone packaging this internally that is the decision point, because a build pipeline that assumes the RPM covers what the AppImage covers will fail on the two architectures RPM omits. The README also points to a wiki page for alternative installation methods, which is where a source build or a different distribution format would be described, and the presence of Cross.toml at the repository root is the reason so many targets exist in the first place.

## ENTRYPOINT is the GUI binary, so a container has to be given a display

There is a Dockerfile, and the runtime stage is short enough to read in full.

```dockerfile
FROM debian:bookworm-slim

# Install runtime dependencies for both X11 and Wayland
RUN apt-get update && apt-get install -y \
    libpcap0.8 \
    libasound2 \
    libfontconfig1 \
    && rm -rf /var/lib/apt/lists/*

COPY --from=builder /usr/src/sniffnet/target/release/sniffnet /usr/local/bin/sniffnet

ENTRYPOINT ["sniffnet"]
```

The binary that ENTRYPOINT names is the graphical application, not a command line capture tool. The image installs the libraries for both X11 and Wayland and then sets no DISPLAY variable, mounts no socket and forwards no device, so running it needs those supplied from outside, and the wgpu renderer described earlier has to find a working graphics stack through whatever you forward.

The builder is pinned separately, from rust:1.88-slim, and compiles with cargo build --release. The container is a faithful packaging of the desktop application, which means it inherits the desktop application's constraints rather than escaping them.

## The include list ships data files and does not mention lib/

Cargo.toml carries an include list, and it is not a list of source files. Alongside /src/**/*.rs and /build.rs it names /resources/DB/*.mmdb, /resources/fonts/subset/*.ttf, /resources/sounds/*.mp3, /services.txt, an icon.png, a Windows .ico, both licence files, the README and the changelog. Those are the data the application reads at runtime, and shipping them is what lets the maxminddb lookup and the service identification work without a separate install step.

What the list does not name is lib/, even though a dependency is declared as sniffnet-packet-parser with a path into lib/sniffnet-packet-parser and a version of 0.2.1. The packet parser is therefore resolved from a registry rather than from the directory beside it, which is a detail worth knowing if you plan to patch the parser and rebuild from source.

The release profile explains the other half of the artifact.

```toml
[profile.release]
opt-level = 3
lto = true
strip = true
codegen-units = 1
```

Link time optimisation and a single codegen unit buy a smaller, faster binary at the cost of a long build, and strip removes symbols you would want in a crash report.

## Two licences, a threat model file, and releases a few months apart

The repository root carries LICENSE-APACHE and LICENSE-MIT, so the choice of licence is yours, and it also carries SECURITY.md, THREAT_MODEL.md, INCIDENT_RESPONSE.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, CONTRIBUTORS.md and a CHANGELOG.md. For an application that reads every connection leaving a machine, having a threat model and an incident response file next to the code is the part of the layout that says what the maintainer thinks the project owes its users.

The release cadence is the practical constraint. The three most recent releases are v1.4.2 on 2025-11-04, v1.5.0 on 2026-04-14 and v1.5.1 on 2026-07-22, and the last push to main was on 2026-09-26. That is two feature releases and a patch across a year, so a new protocol or a new service entry is more likely to arrive in a minor bump than in a patch, and a patch is not the place to expect a behaviour change.

Money comes from GitHub sponsors, from organisations including NLnet, IPinfo, the ADS Fund and CodeRabbit, and from a sponsor@sniffnet.app address for inquiries. Support is therefore shaped by a small group of maintainers rather than by a company, which is worth weighing against the fact that you are pointing a packet capture interface at your own network.

## Conclusion

Sniffnet fits someone who wants to see which programs and hosts are using bandwidth on a single machine, and it does not fit a headless server where nothing can draw a window, or an investigation that needs packet level dissection. Verify first that the required system libraries are present on the target machine, because the troubleshooting section attributes most startup errors to missing dependencies, then check the architecture list for your package format, where RPM covers only x86_64 and aarch64 while DEB and AppImage cover four.

## FAQ

### What is sniffnet?

Sniffnet is a cross-platform application to comfortably monitor your network traffic, written in Rust. You choose one network adapter to inspect, apply filters to the observed traffic, and view statistics, real-time charts, connections in your local network, and the domain name and ASN of the hosts you exchange traffic with.

### how to install sniffnet

The README links prebuilt assets on the GitHub releases page: MSI installers for Windows on x64, arm64 and x86, DMG files for macOS on Intel and Apple silicon, and DEB, RPM and AppImage builds for Linux. It also points to a wiki page for alternative installation methods, and reminds you to install the required dependencies for your operating system.

### how to install sniffnet on ubuntu

Linux users choose a DEB, RPM or AppImage build, and the download table lists DEB and AppImage for amd64, arm64, i386 and armhf, with RPM for x86_64 and aarch64. The README points to a required dependencies page, since it says most errors that may arise are likely due to a system missing what is needed to analyze a network adapter.

### is sniffnet safe

Sniffnet is a traffic monitor rather than a scanner: you select a network adapter to inspect and a set of filters to apply to the observed traffic. The repository root carries LICENSE-APACHE and LICENSE-MIT, and also SECURITY.md, THREAT_MODEL.md and INCIDENT_RESPONSE.md, and you can import custom IP blacklists to highlight potentially dangerous connections.

### sniffnet vs wireshark reddit

Sniffnet identifies more than 6000 upper layer services, protocols, trojans and worms, and it imports and exports capture reports as PCAP files. Wireshark dissects packets field by field, so the practical difference is aggregation against dissection, with the PCAP export being the handoff between them.

## Sources

- [Official documentation](https://sniffnet.app)
- [Official README](https://github.com/GyulyVGC/sniffnet#readme)
- [Project repository](https://github.com/GyulyVGC/sniffnet)
- [Release notes](https://github.com/GyulyVGC/sniffnet/releases)

---

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