DEV Community: MournfulCord

Building a Packet Parser in Rust: When PCAP Meets Ownership

MournfulCord — Wed, 13 May 2026 12:38:55 +0000

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.

Porting a Config Validator to Java for Minimal Environments

MournfulCord — Sun, 03 May 2026 03:20:35 +0000

My previous Python config validator was great for local development, but it hit a wall in minimal "distroless" containers and hardened environments where Python isn't much of an option.

MournfulCord

Apr 28

How a Simple Python Validator Prevents Config Outages

#python #tutorial #devops #sre

Comments 2

3 min read

Sometimes you can't control the environment; you can only control the tool. To ensure our validation logic could run anywhere from a CI runner to a bare-bones production box, I rewrote the tool in Java. This version focuses on portability, zero external dependencies, and "fail-fast" logic.

Why a Java version?

A few reasons kept coming up:

Zero external dependencies: no pip, no venv, no system packages
Easy to bundle: one JAR or native image
Runs anywhere: CI, containers, internal tooling

Teams already familiar with JVM tooling

The logic is the same as the Python version:
load config, check structure, fail fast.

The difference is the runtime assumptions.

The CLI structure

The tool is intentionally small:

ConfigLoader: loads YAML/JSON.

Validator: checks required keys and types

HostValidator: regex validation for hostnames

DatabaseValidator: nested key checks

Main: CLI entrypoint

Nothing fancy. No frameworks, just enough structure to keep it readable.

Loading YAML or JSON in Java

I kept the loader simple. I'm using Jackson (jackson-databind and jackson-dataformat-yaml) to handle the parsing logic:

ObjectMapper yamlMapper = new ObjectMapper(new YAMLFactory());
ObjectMapper jsonMapper = new ObjectMapper();

public Map<String, Object> loadConfig(Path path) throws IOException {
    if (!Files.exists(path)) {
        throw new FileNotFoundException("Config file not found: " + path);
    }

    String text = Files.readString(path);

    if (path.toString().endsWith(".yaml") || path.toString().endsWith(".yml")) {
        return yamlMapper.readValue(text, Map.class);
    } else if (path.toString().endsWith(".json")) {
        return jsonMapper.readValue(text, Map.class);
    }

    throw new IllegalArgumentException("Unsupported file type: " + path);
}

Same behavior as the Python version, just typed differently.

Required keys and type checking

Java doesn’t have Python’s dynamic feel, so I defined expected types like this instead:

Map<String, Class<?>> REQUIRED_KEYS = Map.of(
    "service_name", String.class,
    "port", Integer.class,
    "debug", Boolean.class,
    "allowed_hosts", List.class
);

And the validator walks through them:

List<String> validate(Map<String, Object> cfg) {
    List<String> errors = new ArrayList<>();

    for (var entry : REQUIRED_KEYS.entrySet()) {
        String key = entry.getKey();
        Class<?> expected = entry.getValue();

        if (!cfg.containsKey(key)) {
            errors.add("Missing required key: '" + key + "'");
            continue;
        }

        Object value = cfg.get(key);
        if (!expected.isInstance(value)) {
            errors.add("Invalid type for '" + key + "': expected "
                + expected.getSimpleName() + ", got "
                + value.getClass().getSimpleName());
        }
    }

    return errors;
}

Hostname validation

Same regex, same idea:

Pattern HOST_REGEX = Pattern.compile("^[a-zA-Z0-9.-]+$");

void validateHosts(Map<String, Object> cfg, List<String> errors) {
    Object hosts = cfg.get("allowed_hosts");
    if (!(hosts instanceof List<?> list)) return;

    for (Object h : list) {
        if (!(h instanceof String s) || !HOST_REGEX.matcher(s).matches()) {
            errors.add("Invalid host value: '" + h + "'");
        }
    }
}

Nested database validation

void validateDatabase(Map<String, Object> cfg, List<String> errors) {
    Object dbObj = cfg.get("database");
    if (dbObj == null) return;

    if (!(dbObj instanceof Map<?, ?> db)) {
        errors.add("Invalid type for 'database': expected Map");
        return;
    }

    if (!db.containsKey("host")) {
        errors.add("Missing 'database.host'");
    }

    if (!db.containsKey("port")) {
        errors.add("Missing 'database.port'");
    } else if (!(db.get("port") instanceof Integer)) {
        errors.add("Invalid type for 'database.port'");
    }
}

Same checks, different language.

Running it

The CLI is uncomplicated:

java -jar validator.jar config.yaml

If something’s wrong, it prints errors and exits with a non‑zero code.
If everything’s fine, it keeps quiet.

That’s all there is to it.

Why this matters

A validator doesn’t need to be complex to be useful.
It simply needs to run reliably in the environments you care about.

Python works great until you’re on a host that doesn’t have Python.
Java works great until you’re on a host that doesn’t have Java available.
But the language isn’t the point; The point is catching failures before they turn into outages. This Java CLI is just another way to do that.

What’s your 'go-to' language when you need a tool to run absolutely anywhere? Do you stick with the JVM, or have you moved toward Go/Rust for these types of CLI tools? I'd love to hear about the constraints you're working with.

What I Learned About Networking as a 14-Year-Old Intern

MournfulCord — Tue, 28 Apr 2026 20:25:45 +0000

When I was fourteen, I got my first real taste of networking, not from a classroom or from a cert, but from an internship my uncle offered me at a local tech business (not the same one I work at now). I wasn’t paid or experienced. I was just a kid who loved puzzles and patterns.

But what I saw changed the way I thought about this field forever.

Quality over shortcuts

I watched techs who were getting paid to care… not care. I saw people take shortcuts, tape things together, shrug at problems, and treat the schools and clinics they served like just another ticket in the queue. Meanwhile, the people who depended on them: teachers, front‑desk staff, and principals, were stressed, confused, and occasionally left waiting.

I couldn’t stand that.

So, I did the opposite. I took every issue seriously. I asked questions. I made phone calls when others didn’t bother. I traced cables properly instead of taping them to the wall. I treated every outage like it mattered, because to the people on the other end, it did.

The Moment It All Clicked

The moment that sealed it for me was when a switch went down at a school. My uncle was stressed. The staff was stressed. Kids were stuck in limbo. While everyone else ate lunch, I helped reconfigure the switch and brought the network back online. The teacher’s relief, that look of “thank you, I can breathe again”, hit me harder than any technical achievement ever had.

That’s when I realized networking isn’t just about packets and protocols. It’s about people. It’s about restoring calm amid chaos. It’s about being the person others can rely on.

Today, I’m still in love with the field, the complexity, the constant learning, the deep corners of the stack. But more than anything, I’m in love with the responsibility. People deserve techs who care. People deserve quality. People deserve someone who shows up with pride in their work.

My Advice...

If you’re a young tech reading this: your age doesn’t define your impact. Your title doesn’t define your value. What defines you is how much you care, how much you’re willing to learn, and how seriously you take the people who depend on you.

Be the tech who gives a damn. It matters more than you think.

What was the 'aha' moment in your career when you realized your work was about more than just the technical specs? I'd love to hear your stories in the comments!

How a Simple Python Validator Prevents Config Outages

MournfulCord — Tue, 28 Apr 2026 12:10:00 +0000

Not all outages I’ve seen were caused by exotic bugs or failing hardware. A majority were caused by simple mistakes: broken configs, malformed YAML, wrong types, or a missing field that nobody noticed before pushing.

I built this tool after hearing how a config push took down a service because someone missed a single field. It wasn’t a devastating failure, just a small oversight that slipped through, but it still cost hours to unwind. That stuck with me. A lightweight validator could prevent the kind of mistakes that quietly pile up and turn into outages. You don't always get that second chance, so catching mistakes early matters.

And the thing is, you don’t always need a full schema system to avoid that, either. Sometimes a small, focused validator is enough to catch obvious problems before they become real ones.

This post walks through a Python tool that: loads YAML or JSON configs, checks for required keys and types, and prints clear, actionable errors.

If you work with configs at all, this is one more tool you can keep in your belt.

Why a config validator matters

Configs break more often than hardware. A single wrong indent, a missing key, or a string where an integer should be is all that it takes.

A lightweight validator gives you:

Fast feedback: Catch errors before they hit CI.
Consistent checks: Ensure every config follows the same rules.
Fewer surprises: Reduce the chance of deployment-day outages.

It’s not meant to replace full schema validation, but to prevent the obvious stuff from becoming outages. The idea behind the tool is simple: load the config, check the structure, and fail fast if something looks wrong.

Loading YAML or JSON in Python

Here’s the loader function:

import json
from pathlib import Path
import yaml  # pip install pyyaml

def load_config(path: str) -> dict:
    file = Path(path)

    if not file.exists():
        raise FileNotFoundError(f"Config file not found: {path}")

    text = file.read_text(encoding="utf-8")

    if file.suffix in (".yaml", ".yml"):
        return yaml.safe_load(text)
    elif file.suffix == ".json":
        return json.loads(text)
    else:
        raise ValueError(f"Unsupported file type: {file.suffix} (use YAML or JSON)")

Defining required keys and expected types

This is the simplest form of validation: “Does this key exist, and is it the right type?”

REQUIRED_KEYS = {
"service_name": str,
"port": int,
"debug": bool,
"allowed_hosts": list,
}

Validating the config

This checks for missing keys and wrong types:

from typing import List

def validate_config(cfg: dict) -> List[str]:
    errors: List[str] = []

    for key, expected_type in REQUIRED_KEYS.items():
        if key not in cfg:
            errors.append(f"Missing required key: '{key}'")
            continue

        value = cfg[key]
        if not isinstance(value, expected_type):
            errors.append(
                f"Invalid type for '{key}': expected {expected_type.__name__}, "
                f"got {type(value).__name__}"
            )

    return errors

Example: good vs. bad config

Good YAML:

service_name: api-gateway
port: 8080
debug: false
allowed_hosts:
- "example.com"
- "api.example.com"

Bad YAML:

service_name: api-gateway
port: "8080"   # wrong type
debug: "false" # wrong type
# allowed_hosts missing entirely

Output

Invalid type for 'port': expected int, got str
Invalid type for 'debug': expected bool, got str
Missing required key: 'allowed_hosts'

Hostname regex validation

import re

HOST_REGEX = re.compile(r"^[a-zA-Z0-9.-]+$")

def validate_hosts(cfg: dict, errors: List[str]) -> None:
    hosts = cfg.get("allowed_hosts")
    if not isinstance(hosts, list):
        return

    invalid = [
        h for h in hosts
        if not isinstance(h, str) or not HOST_REGEX.match(h)
    ]

    for host in invalid:
        errors.append(f"Invalid host value: '{host}'")

Nested key validation (for example: database config)

def validate_database(cfg: dict, errors: List[str]) -> None:
    db = cfg.get("database")
    if db is None:
        return

    if not isinstance(db, dict):
        errors.append("Invalid type for 'database': expected dict")
        return

    if "host" not in db:
        errors.append("Missing 'database.host'")

    if "port" not in db:
        errors.append("Missing 'database.port'")
    elif not isinstance(db["port"], int):
        errors.append(
            f"Invalid type for 'database.port': expected int, got {type(db['port']).__name__}"
        )

Run it with:

python validator.py config.yaml

Why this helps in real environments

In the field, the smallest mistakes cause the biggest (and unnecessary) headaches. A missing key, a wrong type, a bad indent, none of it looks serious until it takes down something that people rely on.

Tools like this don’t replace experience, but they make your experience count. They catch the boring failures before they turn into outages that take up your entire day.

What’s next

In a follow‑up post, I’ll show how I turned the same idea into a small Java CLI for environments where Python isn’t available or where teams prefer a single binary.

If you’ve got ideas for other checks you’d want to see in a validator, I’d love to hear them. The best tools come from real problems.

What Being a Field Tech Taught Me About Real-World Networking

MournfulCord — Fri, 24 Apr 2026 00:21:33 +0000

I started seriously working in IT at 15, but it wasn’t until I turned 16 that I really came to understand what “networking” meant beyond diagrams and certification books. Working for a local tech business that handles everything from managed IT services and cybersecurity to structured cabling and network infrastructure, I got thrown into situations where the network isn’t theoretical; it’s the backbone of a school, a clinic, a government office, or a small business trying to stay afloat.

Nothing accelerates learning like walking into a site where the WiFi is down, switches are unlabeled, and the only documentation is a sticky note that reads, "DO NOT TOUCH."

At 17, I went from learning to truly studying. I wanted to know why things worked as they did. Why does a link flap? Why does a device negotiate at 100 Mbps instead of a gigabit? Why does a packet capture reveal patterns unlike user-reported symptoms? That curiosity pushed me deeper into overlooked network layers.

I learned to read the physical layer like a language: signal integrity, duplex mismatches, impedance issues, and the subtle clues NICs give long before a device "officially fails." I began troubleshooting at Layer 2 with intention, not guesswork: spanning-tree behavior, ARP anomalies, VLAN misconfigurations, broadcast storms, and the fun surprises you find when someone connects a switch to itself because "it fit."

Packet analysis became one of my favorite tools, not because it’s glamorous, but because it’s honest. I reach for Wireshark almost every time, since it’s simple and lets me see all the traffic down to each frame and protocol exchange. Logs can lie. Users can misremember. But packets don’t. They tell you precisely what happened, down to the microsecond, if you know how to listen.

And cabling, the part of networking everyone claims is “simple”, became something I genuinely enjoy. There’s an art to building infrastructure that’s clean, reliable, and future‑proof. Good cabling makes networks predictable. Bad cabling makes networks unstable and alive in all the wrong ways.

Over the past few years, I’ve helped design, repair, and optimize networks across schools, healthcare clinics, government offices, small businesses, and residential environments. I’ve learned how to build infrastructure from the ground up and keep systems running for people who depend on them.

But the part that keeps me in this field is the service aspect. Networking isn’t abstract when you’re the one restoring connectivity for a clinic that needs access to patient records or fixing a school’s Wi-Fi so students can actually learn. It’s hands‑on, unpredictable, and it matters because it's meaningful.

I’m still learning, constantly, just like all techs, and that’s the best part. Networking is deep, layered, and endlessly evolving. Whenever I believe I’ve mastered something, I find another corner of the stack worth exploring.

In future posts, I’ll be sharing more about the technical side of what I’ve learned: packet analysis workflows, telemetry insights, L1/L2 troubleshooting strategies, and the occasional field story that every technician can relate to. If you’re into the practical side of networking, you’ll probably feel right at home.

DEV Community: MournfulCord

Building a Packet Parser in Rust: When PCAP Meets Ownership

Why Rust for Packet Parsing?

The Two Crates and Why You Need Both

PCAP: Capturing Packets

PNET: Dissecting Packets

Connecting the Two

Where Ownership Gets Interesting

Reading from a .pcap File

Going Deeper: TCP Layer

What This Is Good For

What's Next

Porting a Config Validator to Java for Minimal Environments

How a Simple Python Validator Prevents Config Outages

Why a Java version?

Teams already familiar with JVM tooling

The CLI structure

Loading YAML or JSON in Java

Required keys and type checking

Hostname validation

Nested database validation

Running it

Why this matters

What I Learned About Networking as a 14-Year-Old Intern

Quality over shortcuts

The Moment It All Clicked

My Advice...

How a Simple Python Validator Prevents Config Outages

Why a config validator matters

Loading YAML or JSON in Python

Defining required keys and expected types

Validating the config

Example: good vs. bad config

Output

Hostname regex validation

Nested key validation (for example: database config)

Why this helps in real environments

What’s next

What Being a Field Tech Taught Me About Real-World Networking

Reading from a `.pcap` File