← TNYCL — Tuna Yucel

netKit: a network analysis engine in Rust

I built netKit, an open-source network capture and protocol analysis framework in Rust. It turns captured traffic into structured events that other software can use.

The same analysis engine runs as a Rust library, a command-line tool, and behind a C interface.

From packets to something useful

There is a fair amount of work between receiving a packet and understanding an application message. A message can span several packets. Packets can arrive out of order, be retransmitted, or be missing from a capture. A recording can begin halfway through a connection.

Software consuming that traffic needs to keep track of what belongs together, what can be decoded, and what information is missing.

netKit handles packet parsing, IP fragment reconstruction, TCP stream reconstruction, and protocol decoding. Its output includes connection events, device observations, decoded messages, and diagnostics. Applications can use those events to build their own views and integrations.

The engine accepts PCAP and PCAPNG files as well as packets supplied by an application. The Rust API and CLI also expose a live capture backend. C and C++ applications can feed packets or application messages through the C interface. Custom decoders can extend the engine with additional protocols.

Keeping uncertainty visible

One important part of the design is how it represents incomplete information.

When a TCP stream has a missing range, the engine reports a gap and resets the affected decoder session. Decoded units carry a completeness status, with values such as complete, partial, encrypted, opaque, and unknown. A complete unit describes what was decoded; the coverage of the overall connection is a separate concern.

Device observations also carry evidence. An IP address appearing only as a packet’s destination has a different meaning from seeing traffic sent by that address.

These distinctions help the software using netKit decide how much it can conclude from a capture. Preserving them in the output makes them available to every integration built on the engine.

A small example

The repository includes a synthetic capture that can be analyzed offline, without installing a capture driver. After building the CLI, run this from the repository root on Windows:

.\target\release\netkit.exe analyze tests\fixtures\clinical-network.pcapng --format jsonl

For this post, I ran that command against the included fixture. It processed 25 packets and decoded 12 messages. Here are selected fields from one emitted event; other fields are omitted:

{
  "schema_version": 1,
  "type": "message_decoded",
  "message": {
    "protocol": "hl7",
    "completeness": "complete",
    "fields": {
      "message_type": "ORU^R01",
      "segments": "[redacted]"
    }
  }
}

In this example, the HL7 segment content is masked by default. The protocol and message type remain available as structured fields. A consuming application can work with those fields directly.

Alongside common network protocols, netKit includes structural parsers for clinical formats such as HL7, ASTM, and DICOM. Their individual capabilities are documented in the support matrix.

Current state

netKit is early software. The validation record covers local Windows builds, synthetic captures, Rust tests, and C/C++ integration checks. Real capture-driver testing, Linux and macOS runtime verification, and clinical-device interoperability remain work to complete.

The source is available under MIT or Apache-2.0. The repository includes build instructions, integration examples, and the architecture notes. If you build something with it, I’d like to hear about it.

← All writing