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. Start at how to use it if you are here for the commands.
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, 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 and issuer from the presented chain
- TLS 1.3 encrypts the certificate — the report says so rather than skipping over it
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
- Lookups that were never answered at all
HTTP
Whether the network broke or the application said no
- Method, URI, version, Host, User-Agent
- Status and reason, Server, Content-Type
- Credentials sent in the clear — an Authorization header or a password in a form body
ICMP, ARP and the rest
The layers everyone forgets to check
- ICMP errors decoded into the reason a delivery failed
- Fragmentation-needed — the classic PMTU black hole
- ARP requests that were never answered: from IP up, identical to a firewall drop
- IPv6, IP fragments, VLAN and QinQ tags
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 and HTTP Host headers are pooled into one map, so every address in the report carries the names it answers to. This is what turns 93.184.216.34 back into the thing the user typed.
Hosts
One row per address: the names it answers to, how many peers it spoke to, packets and bytes. This is the view that answers "is it my end or theirs?".
Conversations
Every address pair, with the service between them, bytes in each direction, and the worst verdict of anything they did.
One ordered story
Handshakes, SNI, certificates, alerts, resets, DNS answers and dead ARP, merged into a single ordered account — so "what happened here" has an answer.
Multi-stage firewall captures
Upload every stage together and they are analysed as one session rather than several. A flow present in one stage and absent from the next is a firewall decision rather than a network fault.
What the capture was filtered to
The tool works out from the traffic itself whether both directions are present, and then refuses to blame the network for a direction your filter excluded.
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 — the report then shows where the packets stopped.
Read the verdict first
The top of the report counts healthy, degraded and failed streams, then explains each one in a sentence. Below that: hosts, conversations, name resolution and unanswered ARP.
Then go to the packets
The packet filter narrows the whole capture — by source, destination, protocol, port, or free text. Type a name and it resolves to the address it was seen answering to.
Taking the capture on your box
The command matters more than the tool. Two rules carry every line below: capture whole packets, and capture both directions when you can.
Linux / macOS — tcpdump
tcpdump -i any -s 0 -w problem.pcap host 10.1.1.10
The everyday one. -s 0 keeps whole packets — without it, certificates and HTTP headers are truncated and cannot be read. host X keeps both directions.
Narrow it to one service
tcpdump -i eth0 -s 0 -w tls.pcap 'host 10.1.1.10 and port 443'
Quieter link, same evidence. Quote the filter so the shell leaves it alone.
One side only (and why the report cares)
tcpdump -i any -s 0 -w oneway.pcap src host 10.1.1.10
Sometimes all you are allowed. Upload it anyway — the report detects the filter and marks the missing direction as "not captured" rather than blaming the far end.
Wireshark / dumpcap
dumpcap -i 1 -s 0 -w problem.pcapng -f "host 10.1.1.10"
Ring buffers are fine: -b duration:60 -b files:10. Upload any one file, or several together.
SPAN / mirror port
monitor session 1 source interface Gi1/0/10 both monitor session 1 destination interface Gi1/0/24
Say both. A one-direction SPAN is the most common cause of a capture that looks like a broken network but is not.
Palo Alto (PAN-OS)
Monitor > Packet Capture — set a filter, enable all four stages, then export: receive / transmit / firewall / drop
Upload the whole set together and label each file. The report then says which stage the packets reached — and where they stopped, which is the answer you came for.
Fortinet (FortiGate)
diagnose sniffer packet any 'host 10.1.1.10' 6 0 a # then convert the output with fgt2eth.pl
Verbosity 6 keeps full packets; a gives absolute timestamps. Level 3 hex output converts to pcap with Fortinet's fgt2eth.pl.
Check Point (fw monitor)
fw monitor -e 'host(10.1.1.10)' -o problem.pcap # -m iIoO gives all four inspection points
The four points map exactly onto what this tool reasons about: i pre-inbound and I post-inbound are the packet arriving; o and O are it leaving. A flow present at i but absent at O is the firewall dropping it, and the report will say so.
Cisco ASA
capture CAP interface inside match ip host 10.1.1.10 any copy /pcap capture:CAP tftp://10.0.0.5/asa.pcap
Add a second capture on the outside interface to see both sides of a NAT — upload both files and label them client side and server side.
F5 BIG-IP
tcpdump -ni 0.0:nnn -s0 -w /var/tmp/f5.pcap host 10.1.1.10 # :nnn adds the F5 noise headers (flow + peer id)
The 0.0 interface means all VLANs. The :nnn suffix adds F5's own trailers, which record which flow and which pool member each packet belongs to. Capture on both the client-side and server-side VLANs: a request present on the client side and absent on the server side is the BIG-IP not passing it on.
AWS — VPC traffic mirroring
# Mirror a session to a monitoring ENI, then on that host: tcpdump -i eth0 -s 0 -w mirror.pcap host 10.1.1.10
Traffic mirroring copies real packets to another instance, so what you capture is the genuine traffic — unlike VPC Flow Logs, which are only summaries and cannot show a handshake or a certificate.
AWS / Azure / GCP — inside the instance
sudo tcpdump -i any -s 0 -w problem.pcap host 10.1.1.10
Always available and often enough. A cloud security group drops traffic before it reaches the instance, so a capture here proves the packet arrived or never did — which is exactly the question when a security group is suspected.
Azure — Network Watcher
# Portal: Network Watcher > Packet capture > + Add # or: az network watcher packet-capture create \ --vm myVm --name cap1 --file-path /tmp/cap1.cap
Runs the capture agent inside the VM. Set the maximum bytes per packet to 0 (unlimited) or certificates and headers will be truncated.
Kubernetes — one pod
kubectl debug -it <pod> --image=nicolaka/netshoot \ -- tcpdump -i any -s 0 -w /tmp/pod.pcap kubectl cp <pod>:/tmp/pod.pcap ./pod.pcap
An ephemeral debug container shares the pod's network namespace, so it sees exactly what the application sees. Capture at the pod and again at the node to find which hop drops the traffic.
MikroTik / RouterOS
/tool sniffer set filter-ip-address=10.1.1.10 \ file-name=cap.pcap filter-stream=yes /tool sniffer start
Download the file from Files afterwards. Stop the sniffer before fetching it or the capture will be truncated.
Juniper (JunOS)
monitor traffic interface ge-0/0/0 matching "host 10.1.1.10" write-file /var/tmp/j.pcap size 0
size 0 is JunOS's whole-packet setting. On SRX, a security-flow trace often answers 'was it policy?' faster than a capture does.
Windows
pktmon start --capture --pkt-size 0 -f problem.etl pktmon etl2pcap problem.etl -o problem.pcap
Built in since Windows 10 1809. --pkt-size 0 is the equivalent of -s 0.
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 the bytes 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.
- Stored files are private. Written mode 0600 under a job id made of a timestamp and 128 bits of randomness, in a directory nothing serves.
- Rejected uploads leave no trace — the half-built job directory is removed with them.
- Reports are never indexed and clear themselves on inactivity.
- No outbound request, ever. No CDN, no webfont, no analytics, no third-party API.
Check something else next
The other modules look at the same target from a different angle.