Introduction
Packet analysis is the practice of capturing and examining network traffic at a low level. It is one of the most direct ways to understand what is actually happening on a network, rather than what you assume is happening. Whether you are debugging an application, investigating suspicious traffic, or studying how protocols work, being able to read packets is an invaluable skill.
The Layered Structure of a Packet
Every packet you capture is actually a stack of protocol headers wrapped around each other. At the outermost layer is the Ethernet frame, which contains source and destination MAC addresses. Inside that is the IP header, containing source and destination IP addresses, TTL, protocol number, and fields for fragmentation. Inside the IP header is either a TCP or UDP segment, which contains port numbers and, in TCP's case, flags and sequence numbers. Finally, inside that is the application data.
When you analyze packets, you peel back these layers one at a time. Knowing what each field means and where to find it is what separates someone who can read network captures from someone who just sees hex dumps.
Key IP Header Fields
The IP header is 20 bytes in the common case, though it can be longer with optional fields. The internet header length field tells you the actual size, it is measured in 32-bit words, so a value of 5 means 5 × 4 = 20 bytes. The total length field gives the size of the entire packet including the header and payload.
The TTL field shows how many more router hops the packet can survive. The protocol field tells you what is embedded in the IP payload, 6 for TCP, 17 for UDP, 1 for ICMP. The IP ID is a 16-bit number that increments with each packet and is used to identify which fragments belong together when a packet is split across multiple frames.
Understanding Fragmentation in Captures
IP fragmentation occurs when a packet is too large for a link's Maximum Transmission Unit. A router splits it into smaller pieces, each with its own IP header. When analyzing fragmented traffic, three fields matter: the IP ID, which is identical across all fragments of the same original packet; the more-fragments flag (M bit), which is 1 for every fragment except the last; and the fragment offset, which tells the receiver where in the original data this fragment belongs.
The fragment offset is stored in units of 8 bytes, so the raw value in the header must be multiplied by 8 to get the actual byte offset. A first fragment has M=1 and offset=0. A middle fragment has M=1 and a non-zero offset. The last fragment has M=0 and a non-zero offset. A non-fragmented packet has M=0 and offset=0.
First fragment: M=1, offset=0
Middle fragment: M=1, offset nonzero
Last fragment: M=0, offset nonzero
Unfragmented: M=0, offset=0Reading TCP Header Fields
In a TCP segment, the source and destination ports identify which applications are communicating. The sequence number tracks position in the byte stream. The acknowledgment number confirms what has been received so far. The flags field. SYN, ACK, FIN, RST, PSH, URG, tells you what kind of segment this is.
When analyzing TCP traffic, the flags tell the story. A SYN with no ACK is the start of a connection attempt. A SYN/ACK is the server's response. A RST is an abrupt termination, which could be a normal response to a closed port, or it could indicate something unexpected. A FIN begins the graceful shutdown sequence.
Identifying Scans and Anomalies
Packet analysis lets you identify scanning activity by looking at patterns rather than individual packets. A host sending SYN packets to sequential or random ports on another host is conducting a port scan. SYN packets with no matching SYN/ACK responses, followed by RST replies from the target, indicate closed ports being probed. A host receiving ICMP echo requests from many sources simultaneously might be the target of a reconnaissance sweep.
Unusual flag combinations are another red flag. TCP packets with FIN, PSH, and URG all set but no SYN or ACK are characteristic of an Xmas scan. Packets with no flags set at all are NULL scans. Both are used to evade firewalls that focus on blocking SYN traffic.
Stimulus and Response Thinking
One of the most useful frameworks for packet analysis is to think in terms of stimulus and response. Every packet you see should raise the question: what caused this, and what response would normally follow? An ICMP echo reply without a preceding echo request means something sent a ping with a spoofed source address. A TCP RST with no prior SYN means either something is misconfigured or a scan is in progress.
Once you develop the habit of looking for stimulus-response pairs, anomalies stand out much more clearly. Responses without stimuli and stimuli without responses are both worth investigating.
ICMP Error Messages and Their Payloads
ICMP error messages embed a copy of the original packet's IP header plus 8 bytes of payload. Those 8 bytes are enough to capture the TCP or UDP source and destination ports, which lets you tie the error message back to the original communication that caused it. When you see a destination unreachable message, look inside it, the embedded header tells you exactly which packet triggered the error.
Conclusion
Packet analysis is a skill that rewards practice. The more captures you read, the faster you get at identifying what is normal, what is unusual, and what the traffic is telling you. Start with simple captures, a ping, an HTTP request, a TCP connection, and trace each packet against what you know about the protocol. Build from there. The wire does not lie, and learning to read it is one of the most honest ways to understand networks.