Slow app, odd errors, no clue why? A packet analyzer records the traffic on a network link and decodes it, so you can see what devices actually said to each other.
| Item | Value |
|---|---|
| Capture filter example | tcp port 80 |
| Display filter example | tcp.port == 80 |
| Capture filter syntax | libpcap, shared with tcpdump |
| When capture filters are set | Before the capture starts |
| Display filters can change | On the fly |
These points come from the Wireshark wiki on capture filters. Tools and syntax change over time, so check the source before you rely on them.
What a packet analyzer does
A packet analyzer, also called a packet sniffer or protocol analyzer, copies frames from a network interface and breaks them into protocol layers. You see addresses, ports, flags and payload details packet by packet.
That is a different job from a dashboard. Where network monitoring tools show trends such as bandwidth and uptime, an analyzer shows the individual conversation behind a spike.
The decoding is the real value. Raw bytes are unreadable, but an analyzer knows many protocols and labels each field, so a failed handshake or a reset connection stands out.
How capture and filtering work
Where packets come from
Most analyzers use the libpcap library (or its Windows counterpart) to read packets from the network card. The Wireshark wiki says it “uses the same syntax for capture filters as tcpdump, WinDump, Analyzer, and any other program that uses the libpcap/WinPcap library.”
Live capture normally needs elevated rights, and you only see traffic that reaches your interface. On a switched network, that may require a mirror port or a tap.
- Local capture: record on the machine that has the problem. This is the simplest option and shows exactly what that host sends and receives.
- Port mirroring: a switch copies traffic from one or more ports to a monitoring port.
- Network tap: a small inline device passes a copy of the traffic to your analyzer without relying on switch settings.
Capture filters versus display filters
The two filter types look alike but work differently. The wiki puts it this way: “Capture filters (like tcp port 80) are not to be confused with display filters (like tcp.port == 80).”
- Capture filters decide what is stored. Per the wiki, they “are set before starting a packet capture and cannot be modified during the capture.”
- Display filters decide what you see. The wiki says “you can change them on the fly.”
- Filtering at capture keeps files small. Filtering at display keeps your options open, since hidden packets are still in the file.
A sensible habit is to use a loose capture filter, or none on a quiet link, and then narrow things down with display filters. If you filter too tightly at capture, the one packet that explains the fault may never be recorded.
Choosing and using an analyzer
Common tools
Wireshark is the best-known graphical analyzer, and tcpdump is the standard command-line option. Both read and write capture files, so you can record on a server with tcpdump and study the file on your desktop.
Command-line capture suits remote servers with no screen. A graphical tool suits digging through a long conversation, following a single connection, or colouring packets by protocol.
Other tools exist, including terminal-based viewers and analyzers built into network appliances. Whatever you choose, check that it can open standard capture files, so your evidence is not locked inside one product.
What to look for in a capture
Most faults leave a recognisable pattern. Learning a handful of them covers a large share of everyday troubleshooting.
- Retransmissions: the same data sent again, often a sign of packet loss or a congested link.
- Connection resets: one side abruptly ends the session, which can point to a firewall rule or a crashed service.
- Slow name lookups: long gaps before a connection starts often mean the DNS server is slow or unreachable.
- Handshake failures: a connection request with no reply suggests the path is blocked or the host is down.
- Unexpected talkers: a device sending traffic you cannot explain deserves a closer look.
Timing matters as much as content. Check the gap between a request and its reply, because a slow server and a slow network look different once you see the timestamps.
When to use an analyzer instead of other tools
Start with simpler tools when they can answer the question. A ping or a trace route tells you whether a path exists, and a monitoring system tells you when a link is busy.
Reach for a packet analyzer when those tools say everything looks fine but users still complain. It is also the right choice when you need proof, for example to show a vendor that a device is sending malformed traffic or that a server answered late.
- An application works for some users but not others, and logs show nothing.
- A device seems to ignore requests or answer with errors.
- You need to confirm that a firewall change did what you intended.
- You suspect a misconfigured device is flooding the network with broadcasts.
Capture work costs time and storage, so keep it targeted. A short, well-aimed capture beats hours of unfiltered recording that nobody has time to read.
A practical workflow and good habits
Step by step
- Define the symptom, such as slow logins from one subnet.
- Pick the interface and set a narrow capture filter, for example a single host.
- Capture while you reproduce the problem, and stop soon after.
- Apply display filters to isolate retransmissions, resets or failed name lookups.
- Save the file and note what you changed and when.
If the cause turns out to be a bad device setting, network configuration management helps you track and fix it. Packet analysis sits within the wider field of network management software.
Keep notes as you go. A short record of the symptom, the filters used and the finding makes the next incident faster, and it gives colleagues something to review.
Habits that make captures easier to read
Synchronised clocks help when you compare captures taken on two machines. If the clocks drift, you cannot line up a request on the client with its arrival at the server.
Capture at both ends of a suspect link when you can. If a packet leaves one side but never arrives at the other, the fault lies in between, and that narrows your search quickly.
Name your files with the date, the host and the symptom. Months later, a file called capture1 tells you nothing, while a descriptive name saves a repeat investigation.
Privacy and good practice
Captures can contain passwords, session data and personal information when traffic is not encrypted. Capture only on networks you are authorised to inspect, and store files securely.
Encryption limits what an analyzer can show, which is good for privacy. You will still see who talked to whom and when, even if the payload is unreadable.
Share captures carefully. Trim them to the packets that matter, and remove or mask sensitive data before sending a file to anyone outside your team.
Frequently asked questions
Is a packet analyzer the same as a packet sniffer?
Show answer
In everyday use, yes. Both capture and decode network traffic, though “analyzer” usually implies richer decoding and statistics.
Can I change a capture filter mid-capture?
Show answer
No. The Wireshark wiki says capture filters cannot be modified during the capture, while display filters can be changed freely.
Do capture filters and display filters use the same syntax?
Show answer
No. Capture filters use libpcap syntax such as tcp port 80, while display filters use field names such as tcp.port == 80.
Why do I only see some of the traffic?
Show answer
On a switched network, a local capture normally shows traffic to and from your host, plus broadcast and multicast traffic delivered to its interface. Use port mirroring or a tap to see more.
