When users say the network is slow, PcapAI runs 100 diagnosis rules in 11 areas on the capture and says which part of the network each problem comes from: the client, the network path, a server, DNS or the capture itself, with who usually owns the fix.
This page lists the problems those rules look for and the thresholds behind them. The free summary shows the problems found in about two minutes; the PDF adds the hosts, the times, the measured values and the fix steps.
run on every capture
TCP to applications
home to data center
captures up to 20 MB
Where the fault lies
Each problem in the report names the part of the network it comes from and who usually fixes it, so the PDF can go straight to the right team, ISP or vendor.
| The problem points at | Who usually owns the fix |
|---|---|
| Network path | Network team or ISP |
| Server | Server / application owner |
| Client | Desktop / end-user IT |
| DNS server | DNS administrator |
| The capture | Whoever took the capture |
| Depends on the evidence | Named in the report for each case |
The checks
Grouped by the 11 coverage areas of the report. An area with no problem is marked as checked and clean; an area the capture cannot support is marked as not assessed, with the reason.
Whether connections open, stay open and get reused.
A server answers connection attempts with a reset, a router or firewall rejects them, or they get no answer at all. Blocked outbound mail ports are reported separately.
Some connections only succeed after SYN retries, adding seconds of delay before anything happens.
The server has to resend its handshake reply because the client's ACK does not arrive.
Connections that were working are reset in the middle of use.
Keep-alive probes go unanswered before connections are reset: the peer or the path to it is gone.
Connections are not reused, which adds a handshake to every request.
Clients reuse source ports quickly, a sign of ephemeral-port pressure.
A client reaches the RPC endpoint mapper, but the dynamic ports it is given are blocked.
Applications wait for IPv6 to time out before they fall back to IPv4.
How much data had to be resent, in which direction, and how the loss was recovered.
The share of data segments retransmitted per server and direction. Several affected clients point at the server side or a shared link; a single client cannot be told apart from its own link.
Lost packets are only recovered after timeouts, freezing transfers for a fraction of a second each time.
Senders resend data that had already arrived, a sign of delay spikes or lost acknowledgements rather than loss.
A sender retransmits with growing timeouts and gets no acknowledgement: the receiver or the path to it stopped responding.
Connections that sat idle for a minute or more stop working: a firewall, NAT or load balancer dropped their state.
Echo requests in the capture get no reply.
Network round trips against the time a server takes to answer: the core of "network or server?".
Round trips take longer than expected for this kind of path (private or public).
Round-trip times jump at times, typical of queueing on a congested link.
The network is fast, but the server takes long to answer each request.
Servers that speak first, such as mail or FTP servers, wait before greeting each client.
Whether transfers are held back by the receiver or by TCP settings rather than by the network.
The receiving side pauses transfers because its application does not read data fast enough.
The sender repeatedly has to wait for the receiver to open its window.
Without window scaling each transfer is capped at 64 KB per round trip.
Connections use small segments, a sign of a tunnel or MSS clamping.
A large transfer runs well below what the path allows, and the report names what limits it.
Name resolution failures, slow resolvers and client settings that make names fail.
A share of lookups sent to one DNS server gets no answer at all.
The server answers with 'server failure'.
The server refuses to answer some clients.
Queries are rejected as malformed or unsupported.
The server takes long per answer.
Clients use a DNS server address where no DNS service is running.
Large answers must be fetched over TCP, but those connections fail.
Every lookup goes to a single DNS server, a single point of failure.
Active Directory locator records are missing from DNS.
A short name is tried with many suffixes before it resolves, or never does.
Clients ask public DNS servers for internal names, which cannot resolve there.
One client sends an unusually high number of queries.
Names that DNS cannot resolve are broadcast to the LAN instead.
A NetBIOS name conflict on the LAN.
Why devices do not get an address, or get it late.
Devices ask for an IP address and no DHCP server answers.
Devices fail to get an address and assign themselves one, which cuts them off.
The server answers some address requests with NAK.
Devices detect that the address DHCP gave them is taken and decline it.
Two servers hand out addresses, often a rogue router or a misconfigured device.
Getting an address takes several seconds.
Leases are so short that devices renew constantly.
Layer-2 problems that make a whole segment slow or unreliable.
Both answer for the address, so traffic goes to either one at random.
A client asks for the gateway's address again and again and gets no answer.
A redundant gateway address keeps failing over.
ARP traffic peaks far above normal.
Broadcast and multicast frames peak high enough to load every device on the segment.
A single device sends most of the broadcast and multicast traffic.
It asks the LAN for internet addresses directly: a wrong subnet mask or gateway.
The switches signal topology changes during the capture.
Devices send flow-control frames that briefly stop all traffic on their links.
Devices fail port authentication, so their switch port stays closed.
Two devices try to use the same IPv6 address.
Several devices advertise themselves as the IPv6 router.
Some neighbors never answer address resolution.
Packets that are too big for the path, and errors the network reports about traffic.
Full-size packets are retransmitted again and again while small ones pass.
Packets are larger than the path allows and are split into fragments.
Routers or hosts send ICMP messages such as unreachable, prohibited by policy or time exceeded.
Secure connections that fail, hang or start slowly, and servers with weak settings.
Secure connections fail during the handshake with an alert.
Something closes the connection as soon as the TLS handshake starts: the server or a device on the path.
Secure connection attempts get no answer from the server.
The server takes long to complete each handshake.
Expired, self-issued or issued for another name; certificates are visible only before TLS 1.3 encrypts them.
The server uses TLS versions older than 1.2.
Errors and slow answers from the services users actually notice.
A share of answers from a web server are server errors.
Requests to a web server are rejected as client errors.
The server takes long to start each answer.
Clients are redirected over and over.
The proxy demands authentication or refuses connections.
FTP commands fail on the server.
Logins work but transfers and listings fail because the data connection is blocked.
SMTP replies reject messages.
The mail server rejects commands or drops sessions.
Mail clients fail to log in.
Database servers answer with errors.
Kerberos requests get no reply.
Domain logins fail, and the report names the error.
LDAP requests are answered with errors.
Directory lookups are slow, which slows logons and applications.
File operations fail on the server.
File operations are slow on the server side.
Some devices use SMB1, which modern Windows servers reject.
Connections fail before the login screen.
Connections close right after the initial handshake.
Clients cannot reach their NTP server.
The NTP server says its own clock is not synchronized.
VPN connection attempts get no answer from the peer.
Browsers try QUIC, get no answer, and fall back to TCP.
Requests to a UDP service get no answer.
A device does not answer SNMP polling.
A device answers SNMP polls with errors.
Whether the capture can support the conclusions; the report says what to capture next.
One-sided capture hides the answers from the other side.
Receivers acknowledged data the capture never saw.
Frames captured twice are excluded from loss figures.
Captures under 10 seconds are too short for some checks.
Scan probes are left out of the connectivity checks so they do not look like failures.
Rule counts are the ones printed in the coverage section of every Troubleshooting report. Some problems are checked by more than one rule, for example packet loss per server, across many servers and per direction.
Thresholds
The limits depend on the type of network, detected from the capture or chosen before you upload. Packet loss and server response times are graded low, medium and high; a round trip above the limit for its path is reported as high latency.
| Network type | Packet loss (low / medium / high) | Round trip, private path | Round trip, public path | Server response (low / medium / high) |
|---|---|---|---|---|
| Home, small office, corporate | 1% / 3% / 8% | 150 ms | 300 ms | 500 / 1,500 / 5,000 ms |
| Data center | 0.1% / 0.5% / 2% | 5 ms | 200 ms | 200 / 1,000 / 3,000 ms |
| Industrial network | 0.5% / 2% / 5% | 10 ms | 300 ms | 300 / 1,000 / 3,000 ms |
Packet loss is the share of data segments retransmitted on connections to one server. Server response is the time from a request to the start of the answer.
The deliverable
See a real one: the TCP retransmission storm case and its 10-page sample PDF, or what every report contains. Security findings are covered on the MITRE ATT&CK coverage page.
Common Questions
It separates two times in every connection: the network round trip and the time the server takes to answer a request. A fast round trip with a slow answer points at the server; slow or spiky round trips and packet loss point at the network path. Loss that affects several clients points at the server side or a shared link, while loss seen by a single client cannot be told apart from that client's own link.
A loss rate or a round trip that is normal on an office or internet path is a fault in a data center. The report applies the limits of the network type detected from the capture, or the one you choose before uploading: home, small office, corporate, data center or industrial.
The capture-quality checks catch the usual problems: traffic seen in one direction only, packets the capture itself dropped, duplicate frames, and captures shorter than 10 seconds. The report marks the areas it could not assess and says how to capture better next time.
No. PcapAI only reads the capture. The report describes each fix in words, names who usually owns it, and gives read-only commands such as ping, traceroute or dig to confirm the problem and the fix from a host you control.
Upload a .pcap or .pcapng file up to 20 MB, no account needed. The free summary shows the problems in about two minutes; the client-ready PDF is $9, with a full refund within 7 days.
