Why Packet Captures Help ISP Tickets
When you call your ISP and say “my internet is slow,” the standard response is a modem reboot script followed by scheduling a technician who may or may not see the problem. When you open a ticket and attach a packet capture showing TCP retransmissions, an MTR report showing loss at a specific upstream hop, and modem event logs with T3 timeouts — you get escalated to the network team instead.
Packet captures serve two purposes. First, they prove the problem is real and reproducible, not a one-time glitch. Second, they often point directly at the failure location — a capture showing loss of TCP sessions at a specific time, correlated with modem T3 timeouts in the event log, tells an ISP engineer exactly where to look. This guide covers what to capture, how to capture it, and what format to provide.
What to Collect Before the Packet Capture
A packet capture alone is not enough. Assemble all of this before opening the ticket:
| Evidence Type | Tool / Source | What It Shows |
|---|---|---|
| Packet capture (.pcap file) | Wireshark, tcpdump | TCP retransmissions, packet loss events, connection resets |
| MTR report | mtr --report -c 100 | Where on the path loss occurs; which hops are affected |
| Modem event log | 192.168.100.1 → Event Log | T3/T4 timeouts, modem registration events with timestamps |
| Modem signal levels | 192.168.100.1 → Signal / Status | Downstream power, upstream power, SNR, uncorrected errors |
| Speed test results | speedtesthq.com (Ethernet connection) | Baseline speed on a wired connection at the time of the problem |
| Timestamps of the problem | Your notes | When the problem happens, how long it lasts, whether it is recurring |
Step-by-Step: Running a Packet Capture
The goal is to capture traffic during the problem period — not after it resolves. If the problem is intermittent, you can start a background capture and let it run for 30–60 minutes during the time the issue usually occurs.
Using tcpdump (Mac/Linux command line)
# List interfaces to find the right one
tcpdump -D
# Capture 60 minutes on the Ethernet interface, save to file
# Replace “en0” with your actual interface name
tcpdump -i en0 -w /tmp/capture.pcap -G 3600 -W 1
# Capture only traffic to/from a specific IP (focused capture)
tcpdump -i en0 host 8.8.8.8 -w /tmp/capture-dns.pcapUsing Wireshark (GUI — all platforms)
- Open Wireshark and select your Ethernet adapter
- Click the blue shark fin (Start capturing)
- Reproduce the problem — open the slow application, make the call that drops, trigger the issue
- After 5–10 minutes (or when the problem occurs), stop capture with the red square
- File → Save As → select pcapng format
- Filter for evidence: type
tcp.analysis.retransmissionin the display filter bar and note the count
Using PingPlotter (for ongoing documentation)
PingPlotter is particularly useful for intermittent problems because it runs continuously and graphs latency and packet loss over time. Configure it to monitor 1.1.1.1 and your modem's gateway IP simultaneously. Let it run for several hours. Export the graph when the problem occurs — the visual of latency spikes correlated with packet loss at a specific hop is compelling evidence. PingPlotter's free tier is sufficient for this purpose; it saves sessions to disk automatically.
What the ISP Needs From Your Capture
Most ISP network engineers cannot process raw .pcap files in tier-1 support. Frame your submission clearly:
- Summary: “Between 7:00 PM and 9:00 PM on [date], I experienced [symptom]. I captured network traffic during this period.”
- MTR report text: paste the full output of
mtr --report -c 100 1.1.1.1run during the problem period. This is readable without special software. - Modem event log: copy-paste the event log text or screenshot it with timestamps visible.
- Specific finding: “The MTR report shows 8% packet loss at hop 3, which is your first network hop after my modem. This was consistent across three test runs.”
- Packet capture: attach the .pcap file and note that “Wireshark shows 47 TCP retransmissions during the 10-minute capture period.”
This framing moves the ticket out of the first-line support script and to the network team. Include your modem's MAC address, account number, and the service address. State explicitly that you tested on Ethernet (bypassing Wi-Fi) and that the problem persists on a direct modem connection.
Frequently Asked Questions
Will ISP support actually use my packet capture?
First-level support generally will not. But a well-documented ticket with a clear MTR report and modem event log often gets escalated to a network engineer who will. The packet capture is most useful if it gets to that second tier. Some ISPs have a dedicated “advanced support” or “network operations” contact path — using those directly (or asking to be transferred there) with your evidence in hand is the most effective approach.
Is it safe to send a packet capture to my ISP?
For an ISP ticket, yes — you are sending it to the organization that already carries all your traffic. However, be aware that a packet capture can contain plaintext from unencrypted connections, DNS queries showing sites you visited, and TLS handshake metadata. Use a focused capture (filtering for traffic to the ISP's own IPs, or limiting to ICMP and TCP headers with tcpdump -s 96 to truncate payloads) if you prefer not to share application data. For most ISP troubleshooting, a capture of just ping/ICMP and TCP session establishment is sufficient to show retransmissions.
How long should the capture run?
For an intermittent problem, run the capture for the full duration of the time window when the problem usually occurs — even if that is 2 hours. File size is manageable: on a 100 Mbps connection capturing at header level (-s 96), 2 hours produces a file of a few hundred megabytes. If you need to capture full packet payloads, use ring buffers in Wireshark or tcpdump -G 600 -W 12 to keep 12 rolling 10-minute files and preserve only the ones around the problem period.