Das lernst du
- BOOTP-Felder und DHCP-Optionen getrennt dekodieren.
- Eine echte Aufnahme feldweise erklären und Widersprüche benennen.
Voraussetzungen: F02 · DHCP-Nachrichten lesenF06 · Optionen und VererbungF12 · Paketmitschnitte auswerten
DHCPv4 übernimmt das feste BOOTP-Format. Darauf folgen die Kennung für das DHCP-Optionsformat und die Optionen. Das ist eine andere Struktur als das DHCPv6-Paketformat.
- TLV
- Type–Length–Value: Ein Optionscode benennt die Bedeutung, eine Länge die Anzahl nachfolgender Wertbytes. Pad und End sind wichtige Ausnahmen vom gewöhnlichen DHCPv4-TLV-Format.
Vom Byteoffset zum Optionswert
Grafik vergrößern
Feste Felder
Die feste BOOTP-Struktur umfasst 236 Bytes. op unterscheidet BOOTREQUEST (1) und BOOTREPLY (2). htype und hlen bezeichnen Hardwaretyp und Adresslänge; Ethernet verwendet typischerweise 1 und 6. hops zählt Relayweiterleitungen. xid ist die 32-Bit-Transaktionskennung, secs beschreibt die seit Beginn des Bezugsvorgangs vergangene Zeit. flags enthält unter anderem das Broadcast-Bit.
ciaddr ist eine bereits benutzte Clientadresse, yiaddr die angebotene bzw. zugewiesene Clientadresse. siaddr kann einen nächsten Bootstrap-Server bezeichnen und ist nicht pauschal die DHCP-Serverkennung. giaddr trägt die Relayadresse. chaddr enthält Platz für die Hardwareadresse; außerdem existieren sname und file. Option Overload kann ihre Interpretation verändern.
| Offset ab BOOTP | Feld | Bytes |
|---|---|---|
| 0–3 | op, htype, hlen, hops | je 1 |
| 4 / 8 / 10 | xid / secs / flags | 4 / 2 / 2 |
| 12 / 16 / 20 / 24 | ciaddr / yiaddr / siaddr / giaddr | je 4 |
| 28 / 44 / 108 | chaddr / sname / file | 16 / 64 / 128 |
| 236 | Magic Cookie 63 82 53 63 | 4 |
| 240… | Optionen | variabel |
Optionen tatsächlich dekodieren
Nach dem Magic Cookie folgt meist eine TLV-Folge. 35 01 02 in Hex bedeutet Code 0x35=53, Länge 1, Wert 2=DHCPOFFER. 33 04 00 00 0e 10 bedeutet Option 51 mit vier Bytes und dezimal 3.600 Sekunden. Mehrbytewerte werden in Netzwerkbyteordnung gelesen.
Pad (0) und End (255) besitzen nicht die gewöhnliche TLV-Struktur. Längen, tatsächliche Paketgröße und eventuelle Überladung müssen zusammen geprüft werden. Ein abgeschnittener Capture kann Felder fehlen lassen, ohne dass der Sender ein kurzes Paket erzeugt hat.
Einen Offset nicht mit der Position im Ethernet-Rahmen verwechseln
Die Offsets der Tabelle beginnen am BOOTP-Header, also am Anfang der UDP-Nutzdaten. Vor diesem Bereich liegen in einer Ethernet-Aufnahme noch Link-, IP- und UDP-Header. Deren Gesamtlänge kann etwa durch VLAN-Tags oder IP-Optionen variieren. Die Zahl 236 bezeichnet deshalb nicht blind Byte 236 der gesamten Capturedatei. Zuerst die tatsächliche Protokollgrenze bestimmen, dann innerhalb des DHCP-Inhalts zählen.
Das Magic Cookie 63 82 53 63 ist eine Kennung des Optionsformats, kein vier Byte langer Adressparameter. Anschließend liest du gewöhnliche Optionen als Code, Länge und genau diese Anzahl Datenbytes. 36 04 c0 a8 14 0a bedeutet Option 54, vier Bytes, Serverkennung 192.168.20.10. Die hexadezimale 36 ist dezimal 54; eine falsche Zahlenbasis führt hier direkt zur falschen Bedeutung.
Einen Decoder gedanklich absichern
Prüfe vor jeder Auswertung, ob Code, gegebenenfalls Länge und die angekündigten Daten tatsächlich im aufgezeichneten Bereich liegen. Pad und End müssen als Sonderfälle behandelt werden. Option 52 kann zusätzliche Optionsdaten in file und/oder sname ankündigen; dann dürfen diese Felder nicht zugleich unkritisch als gewöhnliche Bootdatei oder Servername gelesen werden.
Ein technisch sauberer Bericht unterscheidet außerdem „Feld nicht enthalten“, „Capture abgeschnitten“ und „Wert null“. giaddr=0.0.0.0 ist ein vorhandenes Feld mit einer Bedeutung im Ablauf; es ist nicht dasselbe wie ein nicht auswertbarer Header. Diese Trennung ist besonders wichtig, wenn du Paketdaten automatisiert prüfst oder ein vermeintlich fehlendes Merkmal als Ursache einer falschen Scopeauswahl heranziehst.
Paket 2 aus Wiresharks dhcp.pcap
- Ethernet/IP/UDP transportieren 192.168.0.1:67 → 192.168.0.10:68. BOOTP op=2, htype=1, hlen=6, hops=0, xid=0x00003d1d, flags=0.
- ciaddr=0.0.0.0, yiaddr=192.168.0.10, siaddr=192.168.0.1, giaddr=0.0.0.0; chaddr beginnt 00:0b:82:01:fc:42. In dieser Aufnahme sind siaddr und Serverkennung gleich, aber ihre Bedeutung bleibt verschieden.
- Option 53=OFFER; 1=255.255.255.0; 58=1.800; 59=3.150; 51=3.600; 54=192.168.0.1. Router und DNS stehen nicht in diesem Angebot.
- REQUEST/ACK verwenden in der Datei anschließend xid=0x00003d1e. Diese echte Besonderheit bleibt sichtbar. Sie ist kein Muster, das ein eigener Client ungeprüft übernehmen sollte.
Ergebnis: Die Datei belegt konkrete Werte. Interpretation erfordert zusätzlich den Protokollkontext; gleiche Werte in zwei Feldern machen deren Aufgaben nicht gleich.
Eigene Kontrolle der Rohbytes
Die verlinkte Datei lokal in Wireshark öffnen, Paket 2 auswählen und die Byteansicht ab BOOTP verfolgen. Alternativ tcpdump auf die gespeicherte Datei anwenden. Dies ist ein Lesebefehl, kein Capture fremden Verkehrs.
tcpdump -nn -vvv -XX -r dhcp.pcapTypische Fehler
- siaddr nicht pauschal als Server Identifier ausgeben.
- op=1 ist kein Synonym für DHCPREQUEST.
- Hexadezimale Optionscodes müssen vor Zuordnung korrekt umgerechnet werden.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 2131 · DHCPv4 ↗Protokollbasis, insbesondere §§ 3 und 4; März 1997
- RFC 2132 · DHCP-Optionen ↗Optionen 1, 3, 6, 15, 50–61; März 1997
- Wireshark · DHCP und Beispielmitschnitt ↗dhcp.pcap; echte aufgezeichnete Pakete, unabhängig vom Nordlicht-Lehrnetz
- Wireshark · dhcp.pcap herunterladen ↗Vier Pakete; mit tcpdump feldweise überprüft