For years I built satellite networks with an LTE air interface. Every time I opened a capture in Wireshark, I did the same thing: scroll thousands of packets across MAC, RLC, PDCP, RRC, and S1AP — then redraw the call flow on a whiteboard so the rest of the team could follow it.
Wireshark is unbeatable at showing you every packet. But it shows you a flat list, not the conversation — who said what to whom, in what order. That sequence diagram lives in your head, and you rebuild it by hand every time.
So I built VisualEther to draw the conversation straight from the capture.
What it does
VisualEther reads a PCAP/PCAPNG and renders it as a readable sequence diagram. It's built on tshark, so anything Wireshark can dissect, it can diagram — 5G, LTE, IMS, SIP, BGP, and dozens of other protocols out of the box. Extraction is driven by an XML "field extraction template" (FXT) that maps protocol fields to messages and sessions.
The AI part: the context-budget problem
Here's the wall I hit when I tried feeding captures to an LLM directly: a PCAP blows the context window before you finish pasting. Thousands of packets, dozens of fields per layer — megabytes of noise, and the model drowns.
So VisualEther ships an MCP server. Instead of raw packets, it extracts only the messages and fields that matter, so the agent reads kilobytes of structured data, not megabytes of logs. It then runs an author → debug → verify loop and cites frame numbers as evidence.
A concrete example
One worked case: an R16 gNB capture with the 5G user plane encrypted. With Claude Code driving the MCP server, VisualEther decrypted the PDCP (NEA2) down to the SIP REGISTER, then rebuilt the uplink BSR→grant→SDAP scheduling loop from PUSCH occupancy alone — because the grants were never in the capture. Every claim is anchored to a specific frame number. Full walk-through.
Triage and CI
Beyond a single diagram, the browser-based Session Navigator groups every session in a capture by outcome — pass, fail, late, timeout — so broken flows surface first. And because it emits machine-readable output (NDJSON / Markdown / HTML), you can wire it into CI to generate a diagram for every capture, unattended.
Try it
VisualEther is a commercial tool with a free tier:
- Community (free, no license): PDF sequence diagrams, up to 10 pages / 10 entities.
- Professional / Server (45-day trial): MCP/AI analysis, session triage, larger diagrams.
Runs on Windows, Linux, and macOS (Apple Silicon), installable via winget / Homebrew / apt / dnf. Needs tshark 4.6+.
- Free download: https://www.eventhelix.com/visualether/download
- Live, interactive output (no install): https://diagrams.eventhelix.com/visualether/5g-nr-radio/
I'd love feedback from anyone who lives in Wireshark — especially on the FXT format and the MCP tool design. Ask me anything.
Top comments (6)
I was particularly intrigued by the concept of the "context-budget problem" when trying to feed captures to a large language model (LLM) directly, and how VisualEther's MCP server helps alleviate this issue by extracting only the most relevant messages and fields. The example of decrypting the PDCP (NEA2) down to the SIP REGISTER in the R16 gNB capture is a great demonstration of the tool's capabilities. I'm curious to know more about the trade-offs involved in designing the FXT format and how it balances protocol complexity with the need for concise, actionable output. Have you encountered any notable challenges in mapping protocol fields to messages and sessions, and how do you see the FXT format evolving to support emerging protocols?
Thanks — the context-budget framing is really the whole reason FXT exists, so I'm glad it landed.
On the trade-offs: the core tension is expressiveness vs. authorability. A full protocol state machine would be the "correct" way to model a flow, but nobody would write one; a flat field dump is trivial to write but useless to an agent. So FXT sits in the middle — a declarative XML template that (a) matches messages, (b) folds a chosen set of fields into a session key, and (c) declares an explicit session lifecycle (start/stop/result). The extraction is deliberately aggressive: for the LLM summary, it keeps the label/opcode field, the session-key fields, and any params you explicitly reference — and leaves the full Wireshark packet tree one drill-down away rather than in the summary. That's what turns megabytes into kilobytes without throwing away the evidence; frame numbers stay attached.
The hardest part in practice is session identity, because it's rarely a single field and rarely on the layer you'd expect. A per-UE 5G RRC session, for example, keys on the MAC C-RNTI, not on any RRC field — the identity lives a couple of layers down. And you have to be careful which "id" you trust: mac-nr.ueid is a per-connection context index, not a device identity; the device identity is the NAS 5G-S-TMSI / GUTI. Two other recurring challenges: (1) session types that share an opcode but differ by transport/port — you can't separate those on opcode alone, so you gate each template with a required param on a discriminating field, and non-matches fall through to the next template; and (2) cross-layer correlation — one frame legitimately belongs to several sessions at once (a MAC PDU carrying an RLC AM PDU carrying a PDCP SDU carrying an RRC message). Multi-match lets a single frame feed the MAC, RLC, PDCP, and RRC sessions simultaneously — which is exactly what makes root-causing something like an RRC Release storm across layers possible.
On emerging protocols: because it's all built on tshark, new-protocol support mostly rides on Wireshark's dissectors — when Wireshark can decode it, FXT can diagram it, usually with just a new template rather than engine changes. So the direction I'm pushing isn't a bigger format; it's a smaller authoring cost. The MCP server already lets an agent author an FXT, validate it against the actual capture, and fix it in a loop — so for a protocol with no bundled template, the realistic workflow is "let Claude draft the FXT from the capture, then refine by hand." Keep the format declarative and minimal; push the complexity into the agent that writes it.
Happy to go deeper on any of these — the session-key design especially is where most of the interesting decisions live.
Great explanation, Sandeep. The point about session identity being the hardest part really stands out. In complex protocol stacks, the meaningful “conversation boundary” often does not exist in one obvious field, so the correlation layer becomes just as important as the visualization itself.
I also like the design decision of keeping the raw packet tree available while giving the AI a compressed, evidence-linked representation. This feels like the right pattern for AI-assisted debugging: reduce noise for reasoning, but never remove the ability to trace conclusions back to the original source.
The MCP workflow for letting an agent generate and refine FXT templates is especially interesting. It turns protocol support from a purely manual engineering effort into a collaborative process between the capture, the tooling, and the AI assistant.
A future direction I’d be curious about is automated anomaly detection on top of these sequence diagrams — for example, learning expected call flows and highlighting unexpected state transitions, timing gaps, or missing messages.
Luis — you've put your finger on exactly where I want to take triage next.
Right now the split is: an FXT decides a session's outcome (pass/fail/late/timeout/incomplete) from rules the template author writes, and then a human points Claude at the failures to reason about why. That's already useful, but it has two limits — it only catches what someone thought to write a rule for, and it still needs a person to decide which sessions are worth a closer look.
Automated anomaly detection is the way past both, and the raw material is already there: every session is a timed, ordered sequence of messages with frame numbers. So you can build an "expected flow" two ways — a reference/golden sequence (spec- or known-good-derived) for a deterministic diff, or a learned baseline over a corpus of good sessions (message-presence frequencies, a transition graph, inter-message timing distributions). Then each session gets scored on exactly the three things you named — missing messages, unexpected transitions, timing gaps — with the specific deviation and frame numbers attached.
What I'm most excited about is what it does to the workflow: instead of a human asking "which failed?", the tool surfaces "which are anomalous, and exactly how" — and hands those specific deviations to Claude for the cross-layer root cause. It flips triage from reactive to proactive, and catches the subtle stuff that never trips an explicit fail rule (the session that "passed" but took 4x too long, or quietly dropped a message).
This is genuinely the direction, not a nice-to-have — I've written it up as a concrete feature to build. Your decomposition ("learn expected call flows, then highlight unexpected transitions/timing gaps/missing messages") is exactly the right framing. Thanks for pushing on it.
Luis — the two-category framing is spot on, and it's exactly why I want both halves. Explicit protocol violations are what deterministic FXT rules are for; the "everything technically succeeded but something feels wrong" cases — the extra retries, the latency creep, the subtly-reordered messages — are where a learned baseline earns its keep. Neither alone is enough.
Your reusable-knowledge idea is the part I hadn't fully thought through, and I think it's the compounding piece. If a verified anomaly + its explanation is stored keyed by its signature — protocol, session type, the specific deviation ("RRC setup succeeds but registration latency climbs after message X") — then a future capture that matches the signature can surface the prior root cause as a first hypothesis instead of starting cold. The tool gets faster the more it sees, but stays explainable rather than turning into a black box.
And you've hit the reason that's even possible: because every explanation is anchored to frame numbers, the knowledge base is auditable — a stored root cause isn't "the model said so," it's "here's the pattern, and here are the frames." That's what makes accumulated AI knowledge trustworthy instead of opaque.
I'd genuinely enjoy trading notes on AI-assisted observability and debugging workflows — let's connect on LinkedIn (Sandeep Ahluwalia, EventHelix) and take it from there. Really appreciate you pushing the thinking on this today.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.