Packet Inspector: Read a Frame Field by Field

This is the frame that carries a small plaintext HTTP request from a laptop to a server. The capture is simplified — real HTTPS traffic is encrypted after the TLS handshake, so the HTTP layer would be opaque bytes; use port 80 in a lab if you want to see it — and the addresses are documentation ranges. Everything the inspector shows is an educational model: the fields are real, the values are invented.

Read the line left to right: timestamp; link-layer addresses and EtherType; then IP addresses with ports appended after a dot; then TCP flags, sequence range, acknowledgment, window; then the decoded payload. -e adds the Ethernet header, -n disables name resolution so you see numbers, -v adds TTL and the protocol.

Destination MAC (6 bytes) is the first field on the wire for a reason: a switch or NIC can decide what to do with the frame before the rest has arrived. Here it is the gateway’s MAC, not the server’s — the laptop knows 203.0.113.10 is off-link and sent the frame to the router. Source MAC is the laptop’s interface. EtherType (2 bytes) tells the receiver’s driver which protocol handler gets the payload: 0x0800 IPv4, 0x86DD IPv6, 0x0806 ARP, 0x8100 a VLAN tag that shifts the real EtherType by four bytes.

Who reads it: every switch on the segment (destination only) and the receiving NIC (destination, to accept or ignore; EtherType, to dispatch). Who rewrites it: every router, entirely, because the next link has different endpoints. The frame check sequence at the end is computed by the sending NIC and verified by the receiving one; a mismatch is a silent drop counted in the interface’s rx_crc_errors.

Source IP and destination IP (4 bytes each in IPv4, 16 in IPv6) are the end-to-end addresses. Every router reads the destination to choose a next hop; nothing on the path should change either — except a NAT, which rewrites the source outbound and the destination on the reply, and an L4 load balancer, which may rewrite the destination to a backend. TTL (IPv4) / hop limit (IPv6) starts at a sender default — 64 on Linux and macOS, 128 on Windows, 255 on many routers — and every router subtracts one; at zero the packet is discarded and an ICMP *Time Exceeded* goes back to the source. It is the only field routinely modified in transit, and with it the IPv4 header checksum.

Protocol (IPv4) / next header (IPv6) says what is inside: 6 TCP, 17 UDP, 1 ICMP (58 ICMPv6), 47 GRE, 50 ESP. Firewalls match on it. Total length lets the receiver find the end of the packet inside a frame that may be padded to Ethernet’s 64-byte minimum. Identification, flags, fragment offset support IPv4 fragmentation; DF set means "drop and tell me rather than fragment". DSCP/TOS requests a service class that most of the internet ignores and some enterprise networks honour.

Source port (54001, ephemeral, chosen by the client kernel) and destination port (80, chosen by the application) complete the 4-tuple that identifies this connection at both ends. Sequence number is the position of the first payload byte in the client → server byte stream; tcpdump shows it relative to the initial number from the handshake, so seq 1:101 means the first 100 bytes after the SYN. Acknowledgment number is the next byte the sender expects from the peer — ack 1 says "I have received your SYN and nothing else yet". Flags describe the segment’s role: SYN (open), ACK (the ack field is valid — set on every segment after the first), PSH (deliver to the application now), FIN (I am done sending), RST (abort; nothing listens or state is gone). Window is how many more bytes the sender is willing to receive, multiplied by a scale factor negotiated in the SYN; a window of 0 means "stop".

Who reads it: only the two end hosts’ kernels — and any middlebox that keeps connection state (NAT, stateful firewall, L4 balancer), which is why those devices can break things routers cannot. Who changes it: nobody, except a NAT rewriting the source port and recomputing the checksum, and an MSS-clamping router editing the MSS option in a SYN. The checksum covers the header, the payload and a pseudo-header containing both IP addresses, so a segment that arrives at the wrong host fails it even if the bytes are intact.

The first 100 bytes of payload here are GET / HTTP/1.1\r\nHost: engineer-atlas.dev\r\n… — the request line, then headers, then a blank line. This is the only layer whose content the *application* wrote and the only one it will ever see; in real traffic it is inside TLS, so the capture would show Application Data records of random-looking bytes and the inspector could not decode them without the session keys. The Host header is what lets one IP address serve many sites, and the reason a server behind a load balancer needs X-Forwarded-For to know who really sent the request — the IP header’s source, by the time it arrives, is the balancer’s.

Who reads it: the server process (and an L7 proxy, which terminates TLS and re-sends). Who changes it: an L7 proxy may add or rewrite headers; nothing else on the path can. The transport does not know where one request ends and the next begins — the HTTP parser has to, using Content-Length or chunked encoding.