Nothing hidden.
Nothing guessed.
Every field below is read from your capture and shown with the evidence behind it. Where the packets cannot answer a question, the report says so instead of inventing a cause.
What it extracts6 layers
A capture is just bytes until something names them. Here is everything this reads.
Capture files
Any source, any byte order
- libpcap (.pcap, .cap, .dmp) in all four byte orders, microsecond and nanosecond
- PCAPNG (.pcapng) including per-interface timestamp resolution
- Ethernet, VLAN and QinQ, MPLS, Linux cooked v1/v2, raw IPv4/IPv6, BSD loopback
- Up to 6 files at once — upload a firewall's receive/transmit/firewall/drop set together
- Truncated (snaplen) captures are detected and said so, not silently mis-read
TCP
Followed by sequence number, not by guesswork
- Three-way handshake state, and the RTT measured from SYN to SYN-ACK
- Retransmissions, fast retransmissions, out-of-order segments and sequence gaps
- Duplicate ACKs, zero windows, keep-alives, window scaling and MSS
- Resets — by which side, at what moment, before or after data flowed
- Clean FIN exchanges vs connections that were cut
- The first 64 KB of each direction reassembled, so the conversation can be read
TLS & certificates
Why the padlock did not appear
- ClientHello: SNI, ALPN, offered versions — what the client asked for
- ServerHello: the version and cipher actually negotiated
- Alerts, decoded into what they mean rather than a number
- Certificate subject, issuer, SANs, validity, key size, signature algorithm
- Expired, not-yet-valid, self-signed, name mismatch against the SNI (RFC 6125)
- Certificates re-signed by an inspection middlebox, which is usually the answer
DNS
The failure that looks like a network fault
- Questions and answers: A, AAAA, CNAME, PTR, NS, MX, SRV
- NXDOMAIN, SERVFAIL and REFUSED, each with its plain-language cause
- Lookup round-trip time, and retries
- Lookups that were never answered at all
HTTP
Whether the network broke or the application said no
- Method, URI, version, Host, User-Agent, Referer, X-Forwarded-For
- Status and reason, Server, Content-Type, Location, Via, HSTS
- A note on what the status actually means — a 502 is not a network problem
ICMP, ARP and the rest
The layers everyone forgets to check
- ICMP errors tied to the exact flow they complain about, via the quoted headers
- Fragmentation-needed with the next-hop MTU — the classic PMTU black hole
- ARP requests that were never answered: from IP up, identical to a firewall drop
- One address answering from two MACs: duplicate IP, failover, or a moved device
- IPv6, GRE tunnels (decoded recursively), and IP fragments
What it works outthe useful part
Reading the fields is table stakes. The value is in joining them together — one packet never explains anything on its own.
Names, pinned to addresses
DNS answers, TLS SNI, HTTP Host headers and certificate CN/SANs are pooled into one map, so every address in the report carries the names it answers to — and a tooltip saying which of those four sources taught it. This is what turns 93.184.216.34 back into the thing the user typed.
Hosts
One row per address: names, MACs, whether it acted as client or server, the ports it served, how many peers it spoke to, bytes each way, a TTL-based guess at its OS and how many hops away it sits, and how many of its streams failed. This is the view that answers "is it my end or theirs?".
Conversations
Every address pair, with the services they ran between them, bytes in each direction, duration, and the worst verdict of anything they did.
One ordered story
SYNs, handshakes, first data, SNI, certificates, alerts, resets, FINs, ICMP errors, DNS answers and dead ARP, merged into a single timeline with severities — so "what happened at 14:02:11" has an answer.
Multi-stage firewall captures
A flow seen in the receive stage but never in transmit, or present in the drop stage, is reported as a firewall decision rather than a network fault. That distinction is usually the whole ticket.
What the capture was filtered to
The tool works out from the traffic itself whether you captured with src host X, dst host X, host X, or no filter at all — and then refuses to blame the network for a direction your filter excluded. See below.
One-sided captures
If you captured with src host 10.1.1.10, no reply is in the file — not because nothing replied, but because your filter excluded it. Read naively, every stream looks broken. This tool infers the filter from the traffic and changes what it is willing to conclude.
| What the packets show | Said about an unfiltered capture | Said about a one-sided capture |
|---|---|---|
| SYN sent, no SYN-ACK | Failed The server never answered — a drop, no route, or the server is down. | Degraded No SYN-ACK here, but the reply could not have been recorded. The SYN did leave the client, which rules out a local stack problem. |
| Traffic in one direction only | Failed Asymmetric routing, a one-way SPAN, or a filter. | Expected Exactly what this capture can show. Order, timing and TCP options remain fully valid. |
| UDP request with no reply | Failed Dropped, or the service is down. | Expected Absence of a reply here is not evidence that none was sent. |
Every one of these names the filter it inferred and tells you to re-capture with host X — both directions — to settle the question for good.
How to use it
Four steps, no account, nothing stored anywhere but your own host.
-
Take the capture
Capture both directions if you possibly can — it is the difference between "the server never answered" and "I could not have seen the answer". On any Linux box:
tcpdump -i any -s 0 -w problem.pcap host 10.1.1.10
-s 0 keeps whole packets: without it, TLS certificates and HTTP headers are cut off and cannot be analyzed. host X keeps both directions; src host X keeps only one, and the report will tell you so.
-
Upload it
Drop the file on the upload page. Up to six files at once. From a Palo Alto, upload the whole receive / transmit / firewall / drop set together and label each one — the stage is guessed from the filename, and you can correct it. The report then shows where the packets stopped.
-
Read the verdict first
The top of the report counts healthy, degraded and failed streams, and states what the capture was filtered to. Each stream expands into a sequence ladder, the findings behind its verdict, the TLS and HTTP detail, and the evidence for each claim. Below that: hosts, conversations, name resolution and unanswered ARP.
-
Then go to the packets
The packet explorer filters the whole capture live — by source, destination, protocol, port, stream, or free text. Type a name and it resolves to the address it was seen answering to. Every filter returns the matching packets with timestamps, plus who those addresses are, the flows they belong to, the timeline of what happened, and the lookups involved.
Useful starting filters: proto=DNS · q=RST (who is refusing connections) · q=ZEROWINDOW (who stopped reading) · q=NXDOMAIN (names that do not exist)
How your capture is protected
A capture is evidence: real addresses, real names, sometimes real credentials. Uploading one here should cost you nothing.
- Only real captures are accepted. A file becomes a job only if its first four bytes are a pcap or pcapng magic number, read from disk after upload — the extension is a hint, never the decision. A script renamed .pcap is refused.
- Nothing from the wire can attack the page. Every SNI, Host header, DNS name and certificate subject is escaped on output, and the Content-Security-Policy allows no inline script or style without a per-request nonce.
- Nothing executes in the upload folder. It is denied to the web, the PHP engine is off in it, handlers are removed, and stored files are mode 0600.
- Rejected uploads leave no trace — the half-built job directory is removed with them.
- Reports are never indexed. They hold someone else's traffic and they expire in 24 hours.
- No outbound request, ever. No CDN, no webfont, no analytics, no third-party API.
What it never does
- Send your capture anywhere. Parsing happens on this host, in PHP, with no outbound request.
- Keep it. Uploads and results are deleted after 24 hours, on the next visit to the upload page.
- Ask who you are. There is no account, no email, no tracking, and no ads.
- Guess. Where the packets do not support a conclusion, the report says what is missing instead.
Part of SiteAlertAI — web, SSL/TLS, email, URL and network intelligence in one place.