Ein Paket lesen
Ein Paket auf der Leitung ist ein Stapel von Headern, von denen jeder sagt, was als Nächstes kommt: Das Ethernet-Typfeld nennt IPv4, das IP-Protokollfeld nennt TCP, der TCP-Port legt DNS oder HTTP nahe. Der Decoder folgt dieser Kette. Jeder Header wird mit seinen Feldern, deren Byte-Offsets und, bei gepackten Feldern wie den IP-Flags oder dem TCP-Data-Offset, den genauen Bits gezeigt. Fahren Sie über ein Feld, um zu sehen, wo es im Hex-Dump unten liegt.
An die Bytes kommen
| Quelle | Befehl / Aktion | Sicherungsschicht |
|---|---|---|
| tcpdump, ein Paket mit Ethernet-Header | tcpdump -c1 -xx -ni eth0 port 53 | Ethernet |
| tcpdump ohne Sicherungsschicht | tcpdump -c1 -x -ni eth0 … | Raw IPv4/IPv6 (erkannt) |
| tcpdump auf „any“ | tcpdump -c1 -xx -ni any … | Linux cooked (SLL) |
| Wireshark | Rechtsklick auf das Paket → Kopieren → …als Hex-Dump, oder Datei → Paketdissektionen exportieren | Ethernet |
| Ganze Aufzeichnung | tcpdump -c100 -w out.pcap port 53 | Aus der Datei gelesen |
| Scapy / Python | bytes(pkt).hex() | Hängt von der ersten Schicht ab |
Prüfsummen
IPv4 deckt nur seinen Header ab; TCP, UDP und ICMPv6 decken ihren Header, ihre Daten und einen Pseudo-Header mit IP-Adressen, Protokoll und Länge ab, weshalb ein NAT, das Adressen umschreibt, auch die Transport-Prüfsummen umschreiben muss. Eine falsche Prüfsumme in einer Aufzeichnung auf der sendenden Maschine ist fast immer Checksum-Offloading: Der Kernel überlässt das Feld der Netzwerkkarte, die es erst nach dem Aufzeichnungspunkt füllt. In einer Aufzeichnung von einer anderen Maschine oder einem Mirror-Port bedeutet eine falsche Prüfsumme echte Beschädigung. UDP über IPv4 darf 0 tragen, was „nicht berechnet“ heißt.
Worauf der Decoder hinweist
- TTL-Werte, die das Betriebssystem des Senders verraten (64 Linux/macOS, 128 Windows, 255 Netzwerkgeräte) und wie viele Hops er entfernt ist.
- Private, link-lokale, Multicast- und Dokumentationsadressen; lokal verwaltete MACs (virtuelle Maschinen, zufällige WLAN-Adressen).
- TCP-Handshake-Zustand aus den Flags, Window-Scaling und MSS aus den Optionen, SACK-Blöcke, Timestamps.
- Fragmentierte IP-Pakete, bei denen der Decoder stoppt (der Transport-Header steckt nur im ersten Fragment).
- In ICMP-Fehlern wird auch das zitierte ursprüngliche Datagramm dekodiert, sodass Sie sehen, auf welche Verbindung sich ein „port unreachable“ oder „TTL exceeded“ bezieht.
- Im TLS ClientHello der SNI-Hostname, die angebotenen Versionen, Gruppen und ALPN-Protokolle — alles, was noch im Klartext sichtbar ist.
Fragen
Warum sagt der Decoder, meine TCP-Prüfsumme sei falsch?
Wurde die Aufzeichnung auf der Maschine gemacht, die das Paket gesendet hat, sollte die Prüfsumme erst nach der Aufzeichnung von der Netzwerkkarte eingetragen werden (Checksum-Offloading); Wireshark zeigt dasselbe. Deaktivieren Sie es mit ethtool -K eth0 tx off, wenn Sie echte Werte in Aufzeichnungen brauchen, oder zeichnen Sie auf der Empfängerseite auf.
Kann es eine ganze pcap-Datei lesen?
Ja, ziehen Sie eine .pcap oder .pcapng hinein (bis 8 MB, 5000 Pakete gelistet). Klicken Sie ein Paket in der Liste an, um es zu dekodieren. Die Datei verlässt Ihren Browser nie.
Was ist mit 802.11-WLAN-Frames oder Radiotap?
Noch nicht dekodiert; Aufzeichnungen mit diesen Link-Typen listen die Pakete, zeigen die Bytes aber als Nutzdaten. Ethernet, Linux cooked, raw IP und BSD-Loopback werden unterstützt.
Setzt es TCP-Streams zusammen oder verfolgt es Verbindungen?
Nein. Es dekodiert ein Paket nach dem anderen. Für Stream-Analyse nehmen Sie Wireshark; um genau zu verstehen, was ein Header sagt, ist das hier schneller.
Meine Nutzdaten erscheinen als „TCP payload“, obwohl es HTTP ist.
HTTP wird an den ersten Bytes erkannt (eine Methode oder HTTP/1.x), unabhängig vom Port. Verschlüsselter Verkehr auf 443 wird als TLS-Records gezeigt, alles andere als rohe Bytes mit ASCII-Spalte.