Skip to content
moaz
Case study 03 · 2026

WireTrace

A single HTML file that decodes PCAPs and router logs in the browser, so support staff without Wireshark can triage. Nothing leaves the machine.

The problem

I built WireTrace for a large ISP's support team. The team needed to triage home-broadband captures and router logs, but not every support person had Wireshark available or wanted to learn a separate packet-analysis workflow for the first diagnosis. I wanted the first useful answer to come from opening one file in a browser: identify the likely failure, inspect the relevant packets, and give the next person a compact event log.

The constraint was as important as the feature list. A customer capture can contain more information than the immediate support question requires. The tool therefore had to keep the capture on the machine while still making common broadband failures legible.

Architecture

WireTrace is one HTML file: 175 KB and 1,958 lines of vanilla JavaScript. It has no dependencies. I hand-wrote the PCAP parser for Ethernet, Linux SLL, 802.1Q, IPv4 and IPv6, TCP, UDP, DNS, DHCP, ICMP, ARP, and PPPoE. The interface includes a hex dump, follow-TCP-stream view, endpoint and statistics views, and heuristics for Wi-Fi flapping, roaming, link flaps, PPPoE instability, ARP spoofing, and rogue DHCP.

Router-log handling follows the same narrow approach. The event log exports CSV with Date, Time, Details, Category, and Severity columns. The parser recognizes the stock hostapd, dnsmasq, and kernel line shapes that support staff are likely to receive with a home-broadband case. The result is deliberately small enough to hand to the next support step without turning the tool into a full replacement for a packet-analysis suite.

Try it

This is the real tool, hosted as a static page. Drop in the sample capture from the repo, or any .pcap you have; nothing leaves your browser.

WireTrace

Loads the live tool from GitHub Pages

Decisions

Keep the deliverable to one HTML file

I chose a single file because the support workflow benefits from something that can be opened directly and carried into a controlled environment. The fact that it has no dependencies is part of that choice. Alternative considered: a conventional application with a framework and install step, which would add setup to the triage path.

Rejected
Add a framework or dependency-managed application.

Write the protocol parser for the support path

I implemented the packet formats that matter to this workflow, then exposed the bytes, streams, endpoints, and summaries that help explain a broadband fault. Alternative considered: make Wireshark the required front door and build only a report around it. That would preserve a powerful tool, but would not meet the need for staff without Wireshark.

Rejected
Require Wireshark for the first diagnosis.

Use heuristics alongside raw packet views

The raw views are necessary when a case needs inspection, but support triage also needs a short description of a likely flapping, roaming, PPPoE, ARP, or DHCP problem. Alternative considered: leave interpretation entirely to the reader. The event log and severity fields give the reader a starting point without hiding the underlying packet evidence.

Rejected
Show decoded packets without an opinionated event log.

Security / reliability

WireTrace runs fully client-side. There is no upload path and no network call for parsing or analysis; captures stay on the machine. The output is a local view of the PCAP or router log, with an optional CSV event log for the support record. That boundary is why the implementation stays in a single HTML file and why the tool does not depend on a backend.

Numbers

175 KB
single HTML file
source: facts.md
1,958
lines
source: facts.md
0
dependencies
source: facts.md

What went wrong

What went wrong

The small file still has a real ceiling

The current tradeoff is useful but not free. [PLACEHOLDER: one honest limitation, e.g. large captures and memory] I would keep that limitation visible rather than imply that a browser tab can replace every workflow built around a dedicated packet-analysis tool.

What I'd change

I would spend the next pass on the edges of triage: make the parser's unsupported cases clearer, keep the raw evidence close to each heuristic, and document the conditions under which a result should be escalated. The single-file shape is valuable, so I would preserve it while making its limits easier to see.

The public copy is live at the link above. The original implementation is under another account, so this repository is the public version rather than the original history.