Reading a packet
A packet on the wire is a stack of headers, each one saying what comes next: the Ethernet type field names IPv4, the IP protocol field names TCP, the TCP port suggests DNS or HTTP. The decoder walks that chain. Each header is shown with its fields, their byte offsets and, for packed fields like the IP flags or the TCP data offset, the exact bits. Hover a field to see where it lives in the hex dump at the bottom.
Getting the bytes
| Source | Command / action | Link layer |
|---|---|---|
| tcpdump, one packet with Ethernet header | tcpdump -c1 -xx -ni eth0 port 53 | Ethernet |
| tcpdump without the link layer | tcpdump -c1 -x -ni eth0 … | Raw IPv4/IPv6 (detected) |
| tcpdump on “any” | tcpdump -c1 -xx -ni any … | Linux cooked (SLL) |
| Wireshark | Right-click packet → Copy → …as a Hex Dump, or File → Export Packet Dissections | Ethernet |
| Whole capture | tcpdump -c100 -w out.pcap port 53 | Read from the file |
| Scapy / Python | bytes(pkt).hex() | Depends on the first layer |
Checksums
IPv4 covers only its header; TCP, UDP and ICMPv6 cover their header, their data and a pseudo-header with the IP addresses, protocol and length, which is why a NAT that rewrites addresses must also rewrite transport checksums. A wrong checksum in a capture taken on the sending machine is almost always checksum offloading: the kernel leaves the field for the network card to fill in after the capture point. On a capture from a different machine or a mirror port, a wrong checksum means real corruption. UDP over IPv4 may legally carry 0 to mean “not computed”.
Things the decoder points out
- TTL values that reveal the sender’s OS (64 Linux/macOS, 128 Windows, 255 network gear) and how many hops away it is.
- Private, link-local, multicast and documentation addresses; locally administered MACs (virtual machines, randomised Wi-Fi addresses).
- TCP handshake state from the flags, window scaling and MSS from the options, SACK blocks, timestamps.
- Fragmented IP packets, which the decoder stops at (the transport header is only in the first fragment).
- In ICMP errors, the quoted original datagram is decoded too, so you can see which connection a “port unreachable” or “TTL exceeded” refers to.
- In TLS ClientHello, the SNI host name, offered versions, groups and ALPN protocols — everything that is still visible in clear text.
Questions
Why does the decoder say my TCP checksum is wrong?
If the capture was taken on the machine that sent the packet, the checksum was going to be filled in by the network card after the capture (checksum offloading); Wireshark shows the same thing. Disable it with ethtool -K eth0 tx off when you need real values in captures, or capture on the receiving side.
Can it read a whole pcap file?
Yes, drop a .pcap or .pcapng (up to 8 MB, 5000 packets listed). Click a packet in the list to decode it. The file never leaves your browser.
What about 802.11 Wi-Fi frames or radiotap?
Not decoded yet; captures with those link types list the packets but show the bytes as payload. Ethernet, Linux cooked, raw IP and BSD loopback are supported.
Does it reassemble TCP streams or follow conversations?
No. It decodes one packet at a time. For stream analysis use Wireshark; for understanding exactly what one header says, this is quicker.
My payload shows as “TCP payload” although it is HTTP.
HTTP is recognised by the first bytes (a method or HTTP/1.x) regardless of port. Encrypted traffic on 443 is shown as TLS records, and anything else is shown as raw bytes with an ASCII column.