Case study · Network tools
Network tools: three of them, because the existing ones quit early
The problem
Two things at work needed seeing. A vendor changed network configs and crashes started around the same time; proving the link meant watching the actual traffic. Separately, a bankrupt vendor left behind hardware and software with no license, no support, no docs, and questions basic enough that they deserved answers anyway. The honest plan was to sniff the wire, reverse the protocol, and write a partial open implementation.
The framing
The off-the-shelf tools each quit one step early. ngrep is grep for the network, but it can't read TLS, so today it shows you ciphertext. Wireshark wants a display server you don't have over an SSH session. tshark hands you everything and buries the signal in it.
The gap wasn't a single missing tool but a missing workflow: capture and search the plaintext, see the shape of the traffic, then drill into a single stream. Three jobs, three tools.
The fix
capture → visualize → analyze
-
netgrep · capture & search Rust · original
Bidirectional TCP reassembly, so matches run against complete application payloads, not raw packets. TLS 1.2/1.3 decryption via
SSLKEYLOGFILE(AES-128/256-GCM, ChaCha20-Poly1305). HTTP/2 and DNS modes, a ratatui TUI, ngrep-compatible flags. Integration, stress, and fuzz suites under CI. -
wiregraph · visualize Rust · original
A real-time dashboard: topology map, per-protocol timeline, click-to-filter across every pane, a rolling window that runs forever. Live capture or pcap replay.
-
termshark · analyze modernized fork
Wireshark's depth in a three-pane terminal UI, no GUI required. A modernized fork of the unmaintained termshark: 171 commits on top of a tool that had stopped getting them.
The outcome
A working pipeline that exists because the standard tools stopped at the hard part. All public. netgrep and wiregraph are original builds; termshark is a modernized fork of an unmaintained predecessor.