I've been doing packet analysis for a while now. Wireshark is almost always my first port of call when something's wrong on the wire. (Pun intended.) At some point, though, you'll want to go beyond a GUI. You want to write your own tooling, create your own dissection logic, and own the entire pipeline. And that's where Rust comes in.

This post covers how I approached building a packet parser using both the pcap and pnet crates, what each one does, why you need both, and what Rust's ownership model actually means in this context.

Why Rust for Packet Parsing?

The obvious answer is performance. Rust gives you zero-cost abstractions and no garbage collector, which matters when you're parsing high-volume traffic and every microsecond counts.

But honestly, what hooked me was something different: Rust forces you to be explicit about memory, and packet parsing is a domain where sloppiness gets you immediately. A misread offset, a buffer overrun, an assumption about packet length that ends up being wrong, these aren't just bugs alone; they're also common issues that can silently corrupt your analysis or, in a security tool, become vulnerabilities.

Rust’s type system and ownership model don’t let you be anything but constructed and organized. That’s maybe frustrating at first, but it quickly becomes an asset once you learn to work with it.

The Two Crates and Why You Need Both

PCAP: Capturing Packets

The pcap crate is your interface to libpcap. It handles the low-level capture side: opening a device or reading a .pcap file, applying BPF filters, and handing you raw packet data.

use pcap::Capture;

fn main() {
    // Open a live capture on a network interface
    let mut cap = Capture::from_device("eth0")
        .unwrap()
        .promisc(true)
        .snaplen(65535)
        .open()
        .unwrap();

    while let Ok(packet) = cap.next_packet() {
        println!("Captured {} bytes", packet.data.len());
    }
}

What pcap gives you is raw bytes. It doesn't give context on what they mean, because that's not its job. You get a timestamp, length, and a &[u8] slice, then everything else is up to you.

PNET: Dissecting Packets

That's where pnet comes in. The pnet crate provides structured packet dissection across multiple layers: Ethernet, IPv4/IPv6, TCP, UDP, ICMP, and more. It maps your raw byte slice onto typed structs with named fields.

use pnet::packet::ethernet::{EthernetPacket, EtherTypes};
use pnet::packet::ipv4::Ipv4Packet;
use pnet::packet::tcp::TcpPacket;
use pnet::packet::Packet;

fn dissect(raw: &[u8]) {
    if let Some(eth) = EthernetPacket::new(raw) {
        println!("Src MAC: {}", eth.get_source());
        println!("Dst MAC: {}", eth.get_destination());

        if eth.get_ethertype() == EtherTypes::Ipv4 {
            if let Some(ipv4) = Ipv4Packet::new(eth.payload()) {
                println!("Src IP: {}", ipv4.get_source());
                println!("Dst IP: {}", ipv4.get_destination());
                println!("Protocol: {:?}", ipv4.get_next_level_protocol());
            }
        }
    }
}

Notice the "if let Some(...)" pattern throughout. pnet returns Option<T> everywhere; if the byte slice is too short or malformed, you get None. That's basically the API telling you: don't assume the packet is valid just because you received it.

In the field, I've seen plenty of malformed frames. This pattern handles them correctly by design.

Connecting the Two

The typical workflow is: capture with pcap, dissect with pnet. Here's a simple integration:

use pcap::Capture;
use pnet::packet::ethernet::EthernetPacket;
use pnet::packet::Packet;

fn main() {
    let mut cap = Capture::from_device("eth0")
        .unwrap()
        .promisc(true)
        .snaplen(65535)
        .open()
        .unwrap();

    while let Ok(packet) = cap.next_packet() {
        if let Some(eth) = EthernetPacket::new(packet.data) {
            println!(
                "[+] {} -> {} | EtherType: {:?}",
                eth.get_source(),
                eth.get_destination(),
                eth.get_ethertype()
            );
        }
    }
}

packet.data is a &[u8]. We pass it directly into EthernetPacket::new(), which borrows it. No copying or allocation required here, only a view into the capture buffer. That's the zero-cost part.

Where Ownership Gets Interesting

Here's something that catches people off guard: pcap's next_packet() returns a packet that borrows from the capture's internal buffer. That means you can't hold onto it past the next loop iteration.

// This won't compile
let mut saved: Option<pcap::Packet> = None;

while let Ok(packet) = cap.next_packet() {
    saved = Some(packet); // Error: lifetime issue
}

Rust is telling you something here: the underlying buffer gets reused. If you want to store packet data, you need to own a copy:

while let Ok(packet) = cap.next_packet() {
    let owned: Vec<u8> = packet.data.to_vec(); // Now you own it
    process(owned);
}

This is a Rust quirk, but it's also a faithful model of how libpcap actually manages its capture buffer. The borrow checker is surfacing behavior that C code would let you get wrong and not bring to your attention.

Reading from a .pcap File

Live capture isn't always what you want. For offline analysis or replay, you can open a saved capture file instead:

let mut cap = Capture::from_file("capture.pcap").unwrap();

while let Ok(packet) = cap.next_packet() {
    // Same dissection logic as live capture
}

The API is identical. All you have to do is swap the source, keep the rest. This is useful for testing your parser on known traffic without needing a live interface, something I do regularly when developing new dissection logic.

Going Deeper: TCP Layer

Once you're past Ethernet and IPv4, getting to TCP is another layer of the same pattern:

use pnet::packet::ip::IpNextHeaderProtocols;
use pnet::packet::ipv4::Ipv4Packet;
use pnet::packet::tcp::TcpPacket;
use pnet::packet::Packet;

fn parse_tcp(ipv4: &Ipv4Packet) {
    if ipv4.get_next_level_protocol() == IpNextHeaderProtocols::Tcp {
        if let Some(tcp) = TcpPacket::new(ipv4.payload()) {
            println!(
                "TCP {}:{} -> {}:{}  flags: {:08b}",
                ipv4.get_source(),
                tcp.get_source(),
                ipv4.get_destination(),
                tcp.get_destination(),
                tcp.get_flags()
            );
        }
    }
}

The flags field is a bitmask. You can check individual flags like SYN, ACK, FIN against pnet::packet::tcp::TcpFlags constants, which is where things start getting useful for detecting specific traffic patterns or anomalies.

What This Is Good For

This combination gives you a nice foundation for concepts like:

• Custom traffic analysis: filter and inspect exactly what you care about, without Wireshark's GUI in your way
• Telemetry pipelines: feed parsed fields into your own metrics or alerting system
• Protocol-level diagnostics: spot things like SYN floods, retransmissions, or unusual flag combinations programmatically
• Field tooling: a single compiled binary you can drop onto any Linux box and run instantly

What's Next

This is the foundation. From here, you can layer in:

• UDP and ICMP dissection (same pattern, different protocol structs)
• BPF filters on capture to reduce noise (cap.filter("tcp port 443", true))
• Writing parsed output to a structured format for further analysis
• Async capture with tokio for high-throughput environments

I'm building all of this into a simple Rust PCAP tool I've made, and I'll be sharing more of that work in future posts and tutorials.

If you're already working with pcap or pnet, I'd love to hear what you're building! And if you've hit a wall with the borrow checker in this context, ask away. Rust's ownership model looks entirely different once you see it in the context of packet data.