The scenario
You are debugging an API that returns 504 timeouts, or your laptop drops packets every time it wakes from suspend. The application logs show nothing useful. The firewall rules look correct. You need to see exactly what bytes leave your machine and what comes back. You open a terminal and type tcpdump, but the screen floods with thousands of lines of encrypted noise. You stop the capture, open the file in Wireshark, and realize you captured the wrong interface or missed the exact moment the failure occurred.
How packet capture actually works
Packet capture operates like a passive wiretap on your network interface. The kernel duplicates every frame that passes through the interface and hands the copy to your capture program before the normal network stack processes it. This is called promiscuous mode. The data arrives as raw Ethernet frames. tcpdump reads those frames, applies a Berkeley Packet Filter, and writes the result to standard output or a file. Wireshark reads the same file, decodes the protocol layers, and renders a structured table. The tools do not generate traffic. They only observe what already exists on the wire.
Think of it like a security camera pointed at a hallway. The camera does not change who walks through. It only records what happens. If you point it at the wrong hallway, you will record empty corridors. If you leave it running without storage limits, the hard drive fills up and the system slows down. Capture tools follow the same physical and logical constraints.
Install and configure the tools
Fedora ships both tools in the default repositories. You need the command-line capture utility and the graphical analyzer.
Here is how to install the packages and set up the required user permissions.
sudo dnf install tcpdump wireshark-qt # Install the CLI capture tool and the Qt GUI analyzer
sudo dnf upgrade --refresh # Pull the latest metadata before installing to avoid stale repo errors
sudo usermod -aG wireshark $USER # Add your account to the wireshark group for unprivileged pcap reading
newgrp wireshark # Apply the group change to the current shell session without logging out
Running Wireshark as root is a security risk. The application decodes untrusted network data, and a malicious packet could trigger a buffer overflow in a decoder. Fedora mitigates this by using a setuid helper binary that belongs to the wireshark group. Your user must be in that group to read capture files without sudo. The newgrp command applies the change immediately. Log out and back in if the group does not take effect.
Config files for Wireshark live in ~/.config/wireshark/. The application ships default preferences in /usr/lib64/wireshark/. Edit your home directory files. Never modify files under /usr/lib64/. Package updates will overwrite them and break your custom filters.
Reboot before you debug. Half the time the symptom is gone.
Capture traffic with tcpdump
tcpdump uses BPF syntax for capture filters. These filters run in the kernel and drop unwanted packets before they hit your disk. This keeps file sizes small and reduces CPU overhead.
Here is how to capture traffic on your active interface and limit the output to a manageable size.
ip -br link show # List interfaces and their current state to find the correct name
sudo tcpdump -i enp3s0 -w capture.pcap -c 200 -s 0 # Capture 200 packets on the active interface with full packet length
# -i selects the interface. -w writes to a file. -c stops after N packets. -s 0 disables truncation.
Interface names on modern Fedora systems rarely use eth0. They use predictable names like enp3s0, wlp2s0, or ens18. Using the wrong name produces zero output and wastes time. The ip -br link show command prints a clean list. Look for the interface with UP and RUNNING flags.
Capture filters use simple boolean logic. You can filter by host, port, protocol, or direction. The syntax is strict. Spaces around operators are required.
Here is how to apply a targeted filter so you only capture the traffic you actually need.
sudo tcpdump -i enp3s0 -w api-debug.pcap -c 50 host 192.168.1.10 and port 443 # Capture only TLS traffic to the target server
# host matches source or destination IP. port matches TCP or UDP. and combines conditions.
sudo tcpdump -i any -w loopback.pcap -c 30 port 8080 # Capture local application traffic on the loopback interface
# -i any captures on all interfaces including lo. Useful for localhost debugging.
The -c flag is your safety net. Without it, tcpdump runs until you press Ctrl+C. A busy interface can fill a 50 gigabyte drive in minutes. Always set a packet count or a file size limit. If you need continuous capture, use -W and -C to rotate files automatically.
Stop the capture before the disk fills. A full root partition breaks package manager transactions and halts system services.
Analyze the capture in Wireshark
Wireshark uses display filters, which run in userspace after the file is loaded. Display filters are more expressive than capture filters. They support string matching, protocol fields, and statistical functions. They do not reduce file size. They only hide rows in the GUI.
Here is how to open the capture file and apply a display filter to isolate the failure.
wireshark capture.pcap # Open the file in the Qt interface
# The GUI loads the pcap and renders the packet list. Wait for the bottom status bar to show "Read N packets".
Once the file loads, type your filter in the top bar. Press Enter to apply. The packet list updates instantly. Common display filters include http, tcp.port == 443, dns, and tcp.flags.syn == 1. You can combine them with &&, ||, and !.
Right-click any packet and select Follow > TCP Stream to see the full conversation. Wireshark reconstructs the byte stream, strips headers, and shows the raw payload. This is how you read HTTP requests, TLS handshakes, or database queries. If the payload is encrypted, you will see Encrypted Handshake Message or Application Data. You cannot decrypt TLS without the server's private key or the client's session keys.
Wireshark decodes protocols automatically. If it misidentifies a payload, right-click the packet, select Decode As, and force the correct protocol. This is useful when a service runs on a non-standard port.
Run journalctl -xe first. Read the actual error before guessing.
Verify the data
A capture is useless if it does not contain the traffic you intended to record. Verify the file before you spend hours analyzing it.
Here is how to confirm the capture contains the right interface, protocol, and packet count.
tcpdump -r capture.pcap -c 5 -nn # Read the first 5 packets and print them without resolving hostnames
# -r reads from a file. -nn disables DNS and port name resolution for faster output.
file capture.pcap # Confirm the file type and link-layer header format
# Should return: capture.pcap: pcap capture file, link-type EN10MB (Ethernet)
If tcpdump -r prints nothing, the capture file is empty or filtered incorrectly. If file reports link-type LINUX_SLL, you captured on a virtual or bridge interface. Wireshark handles both formats, but the column headers will differ. Check the Info column for recognizable IPs or ports. If you only see 0.0.0.0 or 127.0.0.1, you captured the wrong interface.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and exact error messages
Capture tools fail in predictable ways. Recognizing the exact error string saves hours of guessing.
The tcpdump command will refuse to start and print tcpdump: enp3s0: You don't have permission to capture on that device. This means your user is not in the wireshark group or you did not run the command with sudo. Run groups $USER to verify membership. Add yourself to the group and log out.
If you see tcpdump: verbose output suppressed, use -v or -vv for full protocol decode followed by zero packets, your filter is too strict. The BPF syntax is case-sensitive and requires spaces around operators. host 192.168.1.10 and port 443 works. host 192.168.1.10 and port443 fails silently.
Wireshark may display The file is not a supported capture file format when you open a .pcap file. This usually happens when the capture was interrupted mid-write. The file header is incomplete. Run tcpdump -r capture.pcap -c 1 to test readability. If it fails, delete the file and capture again. Never analyze a truncated capture.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. If Wireshark cannot read a capture file in /tmp/, check the context with ls -Z /tmp/capture.pcap. The default tmp_t context allows reading. If you moved the file to /var/log/, the var_log_t context may block unprivileged access. Copy it back to your home directory or adjust the context with chcon -t user_home_t.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use tcpdump versus Wireshark
Use tcpdump when you need to capture traffic on a headless server or over an SSH session. Use tcpdump when you want to apply kernel-level filters to save disk space and CPU. Use tcpdump when you are scripting automated diagnostics or integrating captures into monitoring pipelines.
Use Wireshark when you need to decode complex protocol stacks and follow conversation streams. Use Wireshark when you want statistical graphs, export features, and deep packet inspection. Use Wireshark when you are analyzing a saved capture file offline and do not need real-time filtering.
Use ss or netstat when you only need connection states and listening ports. Use iftop when you want a real-time bandwidth histogram per host. Stay on the upstream Workstation if you only deviate from the defaults occasionally.