Skip to main content
The Dark Art of Postmortem DebuggingRead
pcap analyzer
Network capture analysis

Every conversation on the wire, drawn. The one that never finished, named.

conversations as routes312,440 frames
deauth, not from ap-eastap-eastap-weststa-a1sta-a3sta-a5sta-a6sta-a4sta-a7 · never joined
arc weight = frames · hub = access point · the arc that never closes = handshake not completed
fromtoframesassociation
sta-a3ap-west61,204completed
sta-a5ap-east52,880completed
sta-a7ap-east3never · frame 184,203
the answer, in plain language

sta-a7 asked to join ap-east and was answered. Before association could complete, a deauthentication arrived carrying ap-east's address, sent by a transmitter that was not ap-east. sta-a7 never joined. Nothing was decrypted to say so.

frame 184,203 · deauth, reason 7 · 41 ms after the auth response
A capture is a route map: every endpoint a node, every conversation an arc, and the failure the one arc that never reaches its destination.
illustrative. synthetic data. decoded automatically.
pcap analyzer.pcap / .pcapng802.11 monitor modeillustrative. synthetic data.
conversations, drawn as routes312,440 frames · 397.2 s · 108 MB · decoded automatically
deauth · carries ap-east's addresssent by something that is not ap-eastap-east02:00:00:00:00:01ap-west02:00:00:00:00:02sta-a1sta-a2sta-a3sta-a4sta-a5sta-a6sta-a8sta-a7 · 02:00:00:00:00:a7arc weight = frames in the conversationarc that never closes = handshake not completedhub = access point
fromtoframesbytesassociation
sta-a3ap-west61,20448.1 MBcompleted
sta-a5ap-east52,88040.6 MBcompleted
sta-a1ap-west40,11230.2 MBcompleted
sta-a2ap-east29,94022.7 MBcompleted
sta-a4ap-east24,31818.9 MBcompleted, roamed from ap-west
sta-a6ap-east12,0069.3 MBcompleted
sta-a7ap-east3312 Bnever completed · deauth at frame 184,203
display filter it ran, shown with the answer:wlan.fc.type_subtype == 0x0c && wlan.bssid == 02:00:00:00:00:01 && frame.number >= 184190
Network capture analysis

Every conversation on the wire, drawn. The one that never finished, named.

the answer, in plain language

sta-a7 asked to join ap-east and was answered. Before association could complete, a deauthentication arrived carrying ap-east's address, sent by a transmitter that was not ap-east. sta-a7 never joined. Nothing was decrypted to say so.

frame 184,203 · deauth, reason 7 · 41 ms after the auth response · same pattern 22 times in this capture

Drop a .pcap or .pcapng. It is decoded automatically and profiled whole. Every finding is cited to the frame with the filter that surfaced it, so you can re-run it yourself. No filter fluency required. Payloads are never decrypted.

A capture is a route map: every endpoint is a node, every conversation an arc, and the failure is the one arc that never reaches its destination.
illustrative. synthetic data.
02 · watch it work on a real capture
Real Deep Research · 802.11 monitor capture · device identity substituted
deep research · one capture, one question19 steps · investigation card
Deep Research · one capture, one question

“This capture is full of malformed frames and deauths. Is the network under attack, or is it just RF noise?”

Capture wifi-roaming-lab-2g.pcapngLink 802.11 monitor · RadiotapSpan 783 s · 267,597 framesBad FCS 9,715 · 5,637 malformed
The investigation6 of 19 steps
Fork deauth-intent and malformed-origin threads
22 deauths, 9 disassocs in the rollup
Inventory every teardown frame
spread across the span, no burst
Read their reason codes
mostly invalid 802.11 values
Check FCS on the suspicious frames
all three bad-FCS
Profile the corruption by source
beacons from 30+ APs, weak signal
Find the one well-formed teardown
AP → station, reasons 0x0002 / 0x0008
The answer

No attack: the deauth and malformed-frame volume is RF corruption, not a hostile actor

The evidence shows no attack signature: of 33 deauthentication/disassociation frames in the 783-second capture, only 6 carry a valid 802.11 reason code and all 6 belong to one legitimate AP-to-station teardown cycle, while the suspicious ones fail their frame checksum — the deauth and malformed-frame volume is RF corruption, not a hostile actor. Across 267,597 frames the capture holds 24 deauthentications and 9 disassociations, spread evenly over ~0–783 s rather than in bursts. Only 6 of them carry a standards-valid reason code, and all 6 come from AP 98:da:c4:c5:b8:5d to station ca:16:5c:ff:f1:eb (reason 0x0002 at 546.238–546.240 s, reason 0x0008 at 727.589–727.591 s) — a normal re-association cycle, after which the station rejoins the same BSSID within ~860 ms. The remaining teardowns carry invalid reason codes or unreadable fields and fail FCS, consistent with the 9,715 bad-FCS frames spread over 987 distinct (source, frame-type) pairs and averaging ~10 dB weaker signal than good frames.

The alarming deauthentication frames — near-miss source addresses, all-zero addresses, a broadcast transmitter — are corrupt bytes, not frames emitted by any radio.
The only structurally clean teardown sequence is a legitimate client re-association cycle, and the station rejoins the same AP immediately afterwards.
The malformed-frame volume is RF-layer corruption: it is scattered across nearly a thousand source/type combinations and tracks weak or unrecorded signal.
The 86 association requests with an all-zero source address are not an association flood — every one fails FCS and they are spread evenly across the capture.
Next: re-run the roaming test with the monitor radio nearer the station and pinned to one channel
connectivity · 802.11 WLAN / Management Frames & RF Link Quality
Real Deep Research output · device identity substituted
askedIs the network under attack, or is it just RF noise?one questiondrilledraw packets, across rounds, with the display filters it wroteshown with the answerfoundnot an attack: RF corruption at scale, and one ordinary rejoincited to the frame

Watch it work on a real capture.

One capture, one question. The investigation drills the raw packets, tells a deliberate attack from RF corruption, and shows its verdict with the exact filters you can re-run yourself.

what the route map cannot show alone

The map says an arc never closed. The investigation says why: it pulls the deauth frames, checks who transmitted them, and names the mechanism, with every claim grounded in frames it actually pulled.

in this capture
802.11 monitor · 783 s · 267,597 frames
9,715 bad-FCS · 5,637 malformed
one well-formed teardown
03 · the full investigation, end to end
Real Deep Research · 802.11 monitor capture · device identity substituted

The full investigation, end to end.

Not a highlight. The entire deep-research run, from the malformed-frame profile to the attack-or-noise verdict.

Real Deep Research · 802.11 monitor capture · device identity substituted
profile→rounds→verdict
04 · before it answers, it profiles the capture
from a real capture · existing page data · every number sourced
capture profileevidence
Link layer802.11 · 2.4 GHz · Ch 1radiotap / wlan_radio
Frames267,597frame count
Duration783.3 s (~13 min)capture timespan
Malformed5,637 (2.11%)expert: malformed packet
Expert events11,000expert-info severity rollup
Associations1 in 783 sauth / assoc frame analysis
what it finds · categorized, before any question is askedfilled dot = critical · hollow = warn
Malformed5,637 malformed 802.11 frames (2.11%), dominated by weak-signal beacons from 30+ access points.
IE fieldsImpossible information element values: SSID lengths over 32 B, RSN and AKM suite counts in the tens of thousands.
InjectionNull and locally administered source addresses sending management frames: a coordinated single-actor signature.
Deauth22 deauth and 9 disassoc frames, most with reason codes no standard defines: corrupted, not forged.
SweepsFive sources each contacted 110+ distinct hosts: a horizontal scan or discovery pattern.
BeaconingSix flows with near-perfect periodicity over ~7,500 packets each: beacon-flood candidates.
DNSThree high-entropy domain labels: possible domain-generation algorithm.
AssocOnly one legitimate client association completed across the full 783-second capture.

Before it answers, it profiles the capture.

Every capture is first reduced to a sourced profile and a categorized set of threat and protocol findings: the deterministic floor every investigation builds on, computed without decrypting a byte.

charts from a real capture
Protocol distribution
802.11
261.8k
LLMNR
1.2k
MDNS
1.0k
NBNS
884
ARP
766
VRRP
682
UDP
420
Protocol distribution
Packets over time
peak 11.3kmin 11.0k
023
Packets over capture time

Auto-generated from the packets: the protocol mix, and a packet rate that never drops across the whole capture, the signature of a sustained flood. Every value traced back to a frame.

05 · why packet captures are hard to read
illustrative. synthetic data.

Why packet captures are hard to read.

A capture is hundreds of thousands of frames across three interleaved planes. The signal is in the metadata, the timing, and the malformed structure, rarely in any one packet.

the same map, at the scale a capture actually has1,204 conversations · 312,440 frames
one red chord in there. it is the outage.
Scale

A few minutes on the wire is hundreds of thousands of frames. The packet that explains the outage is somewhere in the middle.

Filter fluency

Display filters and capture statistics are their own language. Knowing what to even type is half the battle.

Cross-frame signal

Management, control, and data planes interleave. A roaming failure or an injection attack lives across frames, never in one.

Encrypted payloads

The bytes are encrypted. The story is in headers, timing, fingerprints, and what is malformed, read without ever decrypting.

the real cost of reading captures by hand
01

Hours scrolling Wireshark to find the handful of frames that matter.

02

Guessing which display filter even surfaces the problem.

03

Spotting an injection, scan, or beaconing pattern by eye across thousands of frames.

04

Telling deliberate frame fuzzing apart from ordinary RF corruption.

05

Writing it up with frame-cited evidence the next team can act on.

06 · what logcat.ai does differently
illustrative. synthetic data.

What logcat.ai does differently.

Every capture is profiled first, then investigated against that profile.

scan · sweep · beaconing · malformed flood, flagged on open01
Threat & protocol findings

Deterministic detectors run on open (port scans, host sweeps, beaconing, DGA-like DNS, malformed-frame floods) merged with a protocol and conversation profile into one scored read.

round 1, round 2, round 3: the filters close on the frame02
Agentic deep research

Ask a plain-language question and the agent translates it into the right display filters and statistics, drilling the raw capture across rounds until it can answer. Every claim grounded in frames it actually pulled.

protocol mix · top talkers · expert severity · packets over time03
Auto-built charts

Protocol mix, top talkers, expert severity, packets over time, TLS versions, fingerprints: the dashboard is chosen for the capture and drawn from the packets, not a template.

good runbad run · the arc that changed04
Compare captures with Delta

Put two captures side by side (a good run and a bad one) and see exactly what changed in protocol mix, errors, and behavior. On the map: the same routes, and the one arc that differs.

07 · what's inside a capture
illustrative. synthetic data.

What's inside a capture.

A .pcap or .pcapng holds every frame on the wire or in the air, across the management, control, and data planes. logcat.ai extracts each layer into queryable structure instead of flattening it to text.

management planecontrol planedata plane, encryptedone endpoint, three planeseach plane extracted into queryable structure, never flattened to text
what logcat.ai extracts
802.11 mgmt

Beacons, probes, auth / assoc / deauth: the roaming and join story.

Flows

Source to destination conversations with ports, packets, and byte volume.

DNS / mDNS

Queries, response codes, and high-entropy names worth a second look.

TLS

Handshake versions, cipher suites, and SNI: the security posture.

HTTP

Requests, hosts, and status codes from cleartext exchanges.

DHCP

Leases, assigned addresses, and client hostnames.

Expert info

Malformed frames, retransmissions, and protocol-violation events.

Fingerprints

JA3 / JA3S / HASSH client and server stack IDs: computed, no decryption.

Carved files

Objects reconstructed from cleartext HTTP, SMB, and TFTP payloads.

Behavior

Periodicity, scans, and sweeps: the patterns no single frame shows.

08 · how a capture reaches you
illustrative. synthetic data.

How a capture reaches you.

A capture is taken when the network is the suspect. Three times it is, and what the packets settle.

hundreds of thousands of frames. one of them explains it.01
A capture too big to read by hand

Hundreds of thousands of frames and the ones that matter are buried. The investigation above sorted 22 deauths and 9 disassociations into corruption versus one real teardown, out of 267,597 packets, cited to the frame.

looks fine at a glance. one arc never closes.02
Connectivity that fails for no clear reason

Clients will not associate, sessions drop, and the capture looks like an attack at a glance. The analysis traced it to weak-signal corruption, not spoofing, and named the frames behind it.

packet rate never drops: a sustained floodthe shape of the traffic, drawn from the packets03
A capture you need to see, not read

You want the shape of the traffic, not a filter language. The dashboard above read this capture's protocol mix and what was breaking, then drew the charts that fit it: protocol distribution, packets over time, expert severity.

09 · frequently asked questions
network capture analysis, answered

Frequently asked questions.

Network capture analysis, answered. Questions on the evidence side, answers on the answer side.

01
What capture formats are supported?

Both .pcap and .pcapng (the modern Wireshark format), captured from wired or wireless interfaces, including 802.11 monitor-mode captures. The capture is decoded automatically for analysis, no export step.

02
How does the analysis actually work?

On upload, the capture is profiled in a single pass (protocol hierarchy, expert info, conversations) and loaded into a queryable store. Deterministic detectors flag scans, sweeps, beaconing, and malformed-frame floods, then the model synthesizes a cited read. Deep Research can drill the raw packets with further filters.

03
What can it detect?

Retransmissions and link stress, DNS failures, TLS posture, 802.11 roaming and auth failures, port scans and host sweeps, periodic beaconing, DGA-like DNS, JA3 / HASSH fingerprints, and frame injection or fuzzing, all without decrypting payloads.

04
Do I need to know Wireshark filters?

No. You ask in plain language and the agent writes the display filters and statistics for you. The filters it ran are shown alongside the answer, so you can reproduce any finding yourself.

05
How large a capture can I analyze?

Captures are spooled and processed by streaming, not loaded whole into memory, so multi-hundred-megabyte files are handled. The example on this page is a 93 MB, 267k-frame capture.

06
Is my capture data secure?

Your capture data is encrypted in transit (TLS 1.3) and at rest (AES-256), processed in your own tenant, and never used to train AI models. Payloads are never decrypted: analysis works on metadata, headers and structure. Files are deleted after 90 days, or immediately from your dashboard. Enterprise plans offer on-premise deployment for regulated or air-gapped environments.

11 · ask the capture
illustrative. synthetic data.

Stop scrolling Wireshark. Ask the capture.

Upload a .pcap and get a cited, frame-grounded read in minutes: protocol profile, threat findings, auto-built charts, and a deep-research agent that drills the raw packets for you.

decoded automatically · payloads never decrypted · every finding cited to the frame
sta-a7 · answeredap-eastthe arc that never closed, explained. that is the whole product.