Skip to main content
logcat.ai raises $2.55M to build the future of device systems engineeringRead

Network Capture Analysis

Read any packet capture in minutes, not hours.

Drop a .pcap or .pcapng and logcat.ai profiles the whole capture, hunts the frames that matter, and answers in plain language, grounded in the decoded capture, cited to the packet.

Watch it work on a real capture

One capture, one question. The investigation drills the raw packets, separates a deliberate injection attack from RF noise, and confirms it with the exact filters you can re-run yourself.

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-capture.pcapngLink 802.11 monitor · RadiotapSpan 783 s · 267,597 framesExpert errors 11,000+ · 3,977 malformed
The investigation7 of 16 steps
Decompose the capture into threads
3 hypotheses
Injection or hardware corruption?
malformed frames trace to specific MACs
Profile the dominant AP MACs
beacons carrying corrupt IEs
Check for an active attack
deauth burst at t=546s
Query the capture for frame stats
3,977 malformed, 11,000+ errors
Correlate the beacon flood with roaming
92.7% of airtime consumed
Confirm the root cause
coordinated fuzzing plus deauth attack
The answer

A deliberate 802.11 attack: frame-injection fuzzing plus a deauth burst

This is not RF noise. Three problems, all hostile: (1) a systematic frame-injection and fuzzing campaign generates 3,977 malformed frames with corrupted IE fields across 33+ spoofed MAC identities, every one showing a physically impossible 100% Tx / 0% Rx ratio; (2) a deauthentication burst attack at t=546s targets a roaming client using injected deauth frames with an impossible reason code (341); and (3) the combined beacon flood consumes 92.7% of airtime, producing a complete roaming failure with zero successful WPA handshakes.

Frame-injection fuzzing: 3,977 malformed frames, 33+ spoofed MACs
Deauth burst attack at t=546s (impossible reason code 341)
Beacon flood consumes 92.7% of airtime
Zero successful WPA handshakes: roaming fully blocked
This is an attack signature, not a misconfiguration: isolate the spoofing MAC clusters and treat the capture window as hostile
Enable 802.11w PMF (ieee80211w=2) to authenticate deauth and disassoc frames
security · 802.11 Frame Injection + Deauth Attack
Real Deep Research output · capture name neutralized

The full investigation, end to end

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

Real Deep Research · 802.11 monitor 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.

Capture profileevery number sourced
Link layer802.11 · 2.4 GHz · Ch 1
← radiotap / wlan_radio
Frames267,597
← frame count
Duration783.3 s (~13 min)
← capture timespan
Malformed3,977 (1.49%)
← expert: malformed packet
Expert events11,000
← expert-info severity rollup
Associations1 in 783 s
← auth / assoc frame analysis
What it findsfrom a live capture
Malformed

3,977 malformed 802.11 frames (1.49%) — dominated by 'Tag Length longer than remaining payload' violations.

IE fields

Impossible Information Element values — SSID lengths >32 B, RSN/AKM suite counts in the tens of thousands.

Injection

Null and locally-administered source MACs sending management frames — a coordinated single-actor signature.

Deauth

22 deauth + 9 disassoc frames carrying fabricated reason codes (0x9ccb, 0xdb6d) — forced-disconnect attempts.

Sweeps

Five sources each contacted 110+ distinct hosts — a horizontal-scan / discovery pattern.

Beaconing

Six flows with near-perfect periodicity over ~7,500 packets each — beacon-flood candidates.

DNS

Three high-entropy domain labels — possible domain-generation algorithm (C2 rendezvous).

Assoc

Only one legitimate client association completed across the full 783-second capture.

Charts from a real capture

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.

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

Real output from an actual analysis · identifiers scrubbed

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.

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

Wireshark display filters and tshark 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's malformed, read without ever decrypting.

Real Cost

The Real Cost of Reading Captures by Hand

  • 01Hours scrolling Wireshark to find the handful of frames that matter.
  • 02Guessing which display filter even surfaces the problem.
  • 03Spotting an injection, scan, or beaconing pattern by eye across thousands of frames.
  • 04Telling deliberate frame fuzzing apart from ordinary RF corruption.
  • 05Writing it up with frame-cited evidence the next team can act on.

What logcat.ai Does Differently

Every capture is profiled deterministically first, then investigated, never guessed.

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.

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.

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.

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.

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.

What logcat.ai Extracts
802.11 mgmt

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

Flows

Source ↔ 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.

You showed up with one of these

Three ways a capture lands on you, and what comes back.

A capture too big to read by hand

Hundreds of thousands of frames and the one that matters is buried. The investigation above pulled a frame-injection attack (and the single association that survived) out of 267,597 packets, cited to the frame.

Connectivity that fails for no clear reason

Clients won't associate, sessions drop, and the capture looks fine at a glance. The analysis traced it to spoofed deauths and a malformed-beacon flood, not RF, and named the frames behind it.

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.

Common questions

Frequently Asked Questions

Network capture analysis, answered.

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.

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.

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.

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.

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.

Payloads are never decrypted — analysis works on metadata, headers, and structure. Captures are processed in your own tenant and never used to train shared models.

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.