Skip to content

Introduction to packet sniffing

Every tool in the previous section asked a question and got back a summary — dig handed you the answer section, curl -v handed you headers, nmap handed you a port's state. None of them show you the actual bytes crossing the wire, unfiltered and unsummarized. A packet sniffer does exactly that: it captures every frame a network interface sees and hands it to you raw, with nothing decided in advance about what matters.

Why capture the raw frame at all

Every tool this module has covered so far already answers most day-to-day questions. Reach for a packet sniffer specifically when a summary isn't enough — when curl -v shows a TLS handshake failing but not which message in the handshake caused it, or when two hosts can each ping the network fine but a specific application between them still misbehaves in a way none of the higher-level tools explain. A packet capture is the layer below all of them: no tool's interpretation stands between you and what the network actually carried.

Two ways in: promiscuous mode and monitor mode

An Ethernet NIC, in its normal operating mode, only hands the operating system frames actually addressed to it — its own MAC address, a multicast group it's joined, or the broadcast address. Everything else, it silently discards at the hardware level before the OS ever sees it. Promiscuous mode turns that filtering off: the NIC passes every frame it physically receives up to the operating system, regardless of destination address, which is the setting a packet sniffer needs on a wired interface to see anything beyond its own traffic.

Wi-Fi complicates this slightly. A wireless NIC in its normal, "managed" mode is already associated with one access point and, even in promiscuous mode, still only surfaces frames belonging to that one association. Capturing every 802.11 frame in the air — including management and control frames, and traffic between other devices entirely — needs monitor mode, a separate capability not every Wi-Fi driver supports, since it takes the interface out of a normal client association altogether.

The switch problem: promiscuous mode alone often isn't enough

The switch article already covered why this matters: a switch forwards a frame only out the port where its destination MAC address was last seen, not out every port the way a hub would. Set your own NIC to promiscuous mode on a switched network and you'll still only see traffic actually addressed to your machine, plus broadcasts — the switch simply never sends anyone else's traffic to your port in the first place, so there's nothing extra for promiscuous mode to reveal.

Seeing someone else's traffic on a switched network takes one of a few deliberate techniques:

  • Port mirroring (SPAN) — a managed switch feature that copies all traffic from one port (or a whole VLAN) to a designated monitoring port, configured explicitly by whoever administers the switch.
  • A network tap — a small hardware device inserted physically inline on a cable, passively copying every bit that passes in both directions to a separate monitoring port.
  • ARP spoofing — tricking two hosts into sending their traffic through the attacker's machine by lying about MAC-to-IP mappings, which is an active attack technique, not a passive observation one, and firmly out of bounds without explicit authorization.

The first two are how legitimate network troubleshooting actually captures someone else's traffic on modern switched infrastructure. The practical takeaway: if a capture on your own laptop only ever shows your own traffic, that's not a tool failing — it's the switch doing exactly what it's supposed to.

Capturing traffic that isn't yours needs authorization, same as scanning it

The same legal and ethical line covered for nmap applies here. Capturing your own traffic on your own machine, or on a lab network you control, is unambiguous. Capturing traffic on a shared or corporate network you don't administer — even just to "see what's going on" — needs explicit permission, the same way port scanning does; unauthorized packet capture of other people's traffic can carry the same legal exposure as unauthorized network scanning does.

Where captured packets actually go: libpcap and the .pcap format

Nearly every packet-capture tool on Linux and macOS — tcpdump, tshark, Wireshark's own capture engine — is built on the same underlying library, libpcap, which handles the actual work of pulling frames off a NIC in promiscuous mode and handing them to the application. That shared foundation is why capture files move freely between tools: a capture saved from tcpdump opens directly in Wireshark, and vice versa, because both read and write the same .pcap (or the newer .pcapng) file format. Save a capture from a production server with tcpdump over SSH, then open the resulting file locally in Wireshark's full graphical interface — a combination this course's own hands-on module returns to directly.

sudo tcpdump -i eth0 -w capture.pcap -c 20

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20 packets captured
20 packets received by filter
0 packets dropped by kernel

-w writes raw packets to a file instead of printing a decoded summary to the terminal, and -c 20 stops after 20 packets. The three lines of statistics at the end are worth reading before trusting a capture at all: packets dropped by kernel climbing above zero on a busy interface means the capture couldn't keep up with traffic volume and some frames were lost before analysis ever saw them — a gap that's easy to miss if you only look at how many packets a tool displayed.

Two tools, one underlying capture engine

This module already used tcpdump repeatedly, in the TCP handshake and connection-teardown articles, filtered with BPF expressions like tcp[tcpflags] & (tcp-syn|tcp-ack) != 0. It's fast, scriptable, and available on nearly every Linux server by default — the right tool when you already know roughly what you're looking for and just need a quick capture from a terminal, especially over SSH on a remote machine with no graphical interface at all.

The next article takes tcpdump on its own terms — its filter syntax, how to read its flag notation packet by packet, and the safety rules that apply to capturing on a machine handling real traffic.

Wireshark, which follows it, is the same underlying capture engine wrapped in a graphical interface built specifically for exploring a capture you don't yet fully understand — following one TCP stream's data as an application would see it, color-coding traffic by protocol, and decoding hundreds of application-layer protocols automatically rather than showing raw hex. Reach for tcpdump to grab the capture; reach for Wireshark to actually understand what's in it once the question gets complicated enough that scrolling through a terminal stops being practical.

Sources