Network packet sniffing is a foundational skill for diagnosing connectivity issues, understanding protocol behavior, investigating security incidents, and learning how networks actually work under the hood. While a previous article in this series focused specifically on tcpdump, this article takes a broader view: what packet sniffing actually is at a technical level, the different tools available on Linux beyond tcpdump, how promiscuous mode and switched networks affect what you can capture, and the legal/ethical considerations every administrator must keep in mind.
What Happens When You “Sniff” a Packet?
Every network interface card (NIC) normally only processes frames addressed specifically to its own MAC address, discarding everything else at the hardware level. Packet sniffing works by telling the NIC (and the OS driver) to instead pass along a copy of every frame it sees — not just the ones addressed to it. This special listening state is called promiscuous mode.
flowchart TD
A[Frames Arrive at NIC] --> B{Promiscuous Mode Enabled?}
B -->|No - Normal Mode| C[Only Frames for This MAC Are Passed Up]
B -->|Yes - Sniffing Mode| D[ALL Frames Are Passed Up to Capture Tool]
D --> E[tcpdump / Wireshark / tshark etc.]
Why You Can’t Always See “Everyone’s” Traffic
A common misconception is that plugging into any network lets you see all traffic on that network. This was true on old hub-based networks, where every device physically received every frame. Modern networks use switches, which intelligently forward frames only to the port where the destination MAC address actually lives — meaning a sniffer on one switch port typically only sees:
- Traffic addressed to or from its own MAC address
- Broadcast and multicast traffic
- Nothing else, by default
| Network Type | What a Sniffer Can See |
|---|---|
| Hub | All traffic on the segment |
| Switch (default) | Only its own traffic + broadcasts |
| Switch with port mirroring/SPAN | Traffic from mirrored port(s), as configured |
| Wireless (monitor mode) | All traffic on the same channel, if using monitor mode |
To capture traffic between other devices on a switched network, you typically need administrative access to configure port mirroring (SPAN) on the switch itself, or use techniques like ARP spoofing (which raises serious legal and ethical concerns and should only ever be done with explicit authorization, e.g., in a penetration testing engagement).
The Major Linux Packet Sniffing Tools
| Tool | Interface | Best For |
|---|---|---|
tcpdump | Command-line | Quick diagnostics, scripting, headless servers |
Wireshark | Graphical | Deep protocol analysis, visual packet inspection |
tshark | Command-line (Wireshark’s engine) | Scriptable, Wireshark-quality dissection without a GUI |
ngrep | Command-line | Pattern-matching within packet payloads, like grep for network traffic |
iftop | Command-line (terminal UI) | Real-time bandwidth usage per connection, not full packet content |
Using tshark (Wireshark’s Command-Line Engine)
sudo apt install tshark
sudo tshark -i eth0
tshark gives you Wireshark’s excellent protocol dissection (recognizing HTTP, DNS, TLS handshakes, and hundreds of other protocols by name) directly in the terminal:
sudo tshark -i eth0 -Y "http.request"
The -Y flag applies a display filter (Wireshark syntax), which is more expressive than tcpdump‘s BPF filters for protocol-aware filtering.
Using ngrep — Grep for Network Traffic
sudo apt install ngrep
sudo ngrep -d eth0 "GET" port 80
This searches live network traffic on port 80 for any packet containing the literal string “GET” — extremely useful for quickly spotting specific HTTP requests without wading through full packet dumps.
Using Wireshark (Graphical)
Wireshark provides the same capture engine as tshark/dumpcap, with a rich graphical interface for filtering, following TCP streams, and visualizing traffic patterns.
sudo apt install wireshark
sudo wireshark
Note: Running Wireshark as root is discouraged for security reasons; instead, add your user to the wireshark group so the capture helper (dumpcap) can run with the necessary privileges without running the entire GUI as root:
sudo usermod -aG wireshark $USER
A Practical Comparison Example
Let’s look at the same HTTP request captured three different ways.
With tcpdump:
sudo tcpdump -i eth0 -A port 80 -c 5
With tshark (more protocol-aware):
sudo tshark -i eth0 -Y "http.request" -T fields -e http.host -e http.request.uri
With ngrep (pattern search):
sudo ngrep -d eth0 "Host:" port 80
Each tool trades off convenience, readability, and depth of protocol understanding differently — tcpdump is fast and universal, tshark understands protocols deeply, and ngrep is ideal for quick text pattern searches.
Wireless Packet Sniffing: Monitor Mode
Sniffing Wi-Fi traffic requires putting the wireless adapter into monitor mode (different from promiscuous mode), which allows capturing raw 802.11 frames rather than just the traffic destined for your own connection:
sudo airmon-ng start wlan0
sudo tcpdump -i wlan0mon
Not all wireless adapters/drivers support monitor mode — this is a hardware/driver capability, not just a software setting.
Real-World Use Case: Investigating Unexpected Outbound Traffic
Suppose a server appears to be sending unusual outbound connections, possibly indicating malware or a misconfigured application.
sudo tcpdump -i eth0 -n 'not port 22 and not port 443' -c 50
This excludes expected SSH and HTTPS traffic, surfacing anything unusual. Combined with tshark‘s protocol identification, you can quickly narrow down what’s generating the unexpected traffic:
sudo tshark -i eth0 -q -z conv,ip
This produces a summary of all IP conversations (who talked to whom, how much data), which is often the fastest way to spot an anomaly.
Comparison Table: Sniffing Tool Selection Guide
| Situation | Recommended Tool |
|---|---|
| Quick check on a remote server via SSH | tcpdump |
| Deep protocol-level debugging (TLS handshake issues, HTTP header inspection) | tshark or Wireshark |
| Searching for a specific string/pattern live | ngrep |
| Visual, exploratory analysis of a saved capture | Wireshark |
| Wireless network analysis | airmon-ng + tcpdump/Wireshark in monitor mode |
| Bandwidth usage overview, not full content | iftop or nload |
Legal and Ethical Considerations
Packet sniffing is a powerful capability that comes with serious responsibility:
- Only capture traffic on networks and systems you own or have explicit authorization to monitor. Unauthorized interception of communications is illegal in most countries (e.g., under wiretapping and computer misuse laws).
- Be mindful of sensitive data. Captured traffic can contain passwords, personal data, or confidential business information — handle capture files with the same care as any sensitive data store, and delete them when no longer needed.
- Inform relevant stakeholders when performing network monitoring as part of official IT operations or security work, in line with your organization’s policies.
- Use encryption (TLS/SSH/VPN) as the primary defense against sniffing by others — packet sniffing tools exist for legitimate diagnostics, but the same techniques could be misused by an attacker on a compromised or shared network.
Best Practices
- Start narrow, then widen. Begin with a specific filter based on what you’re investigating, rather than capturing everything and searching afterward.
- Use
-nto skip DNS resolution for faster captures and cleaner output when hostnames aren’t needed. - Save captures for team collaboration — a
.pcapfile can be shared with colleagues or attached to a support/security ticket for deeper review. - Combine tools. Use
tcpdumpfor a quick live look, then switch totshark/Wiresharkfor deeper analysis of a saved capture. - Automate common captures with scripts and cron-based rotation for ongoing monitoring needs, but be mindful of storage growth.
- Respect the legal boundary of authorized use at all times.
Troubleshooting
Problem: Sniffer sees almost no traffic on a switched network
This is expected switch behavior — you’re only seeing your own host’s traffic and broadcasts. You need port mirroring (SPAN) configured on the switch to see other hosts’ traffic.
Problem: Wireless adapter won’t enter monitor mode
Check driver support:
iw list | grep -A 10 "Supported interface modes"
Not all Wi-Fi chipsets/drivers support monitor mode; some require specific alternative drivers.
Problem: tshark/Wireshark requires root even after adding to the wireshark group
Log out and back in (group membership changes require a new login session), and confirm the dumpcap binary has proper capabilities set:
getcap /usr/bin/dumpcap
Problem: Capturing HTTPS traffic shows nothing useful
This is expected and correct — TLS encrypts the payload. To inspect encrypted application traffic for debugging purposes, you’d typically need to configure the application (like a browser) to log its TLS session keys, then load those keys into Wireshark — a deliberate, application-side debugging feature, not something a passive sniffer alone can do.
Conclusion
Packet sniffing on Linux spans a rich ecosystem of tools — from the fast, universal tcpdump, to the deeply protocol-aware tshark and Wireshark, to the pattern-matching simplicity of ngrep. Understanding the underlying mechanics — promiscuous mode, the difference between hub and switched network visibility, and monitor mode for wireless — lets you choose the right tool for any diagnostic or investigative task, while always operating within clear legal and ethical boundaries.
