DHCP-Client und -Server in Embedded Linux richtig spezifizieren

Ein Embedded-Gerät benötigt einen DHCP-Client, wenn es seine eigene IPv4-Konfiguration von einem bestehenden Netzwerk bezieht. Es benötigt einen DHCP-Server, wenn es nachgelagerten Geräten oder einem Smartphone zur Inbetriebnahme Konfigurationen zuweist. Ein Gateway kann beide Rollen benötigen, jeweils auf klar definierten Schnittstellen. Die Produktanforderung sollte diese Schnittstellen, ihre Konfigurationsverantwortlichen und ihr Fehlerverhalten benennen, bevor ein Dienst ausgewählt oder das Linux-Abbild um Pakete ergänzt wird.

Dieser Leitfaden behandelt IPv4-DHCP in Embedded-Linux-Produkten. IPv6-Router-Advertisements und DHCPv6 benötigen ein eigenes Konzept. Die folgenden Konfigurationen und Abnahmetests sind vorgeschlagene Entwicklungsbeispiele, keine Ergebnisse einer Obeita-Installation.

Mit der Installationstopologie beginnen

„DHCP unterstützen“ kann mehrere unvereinbare Anforderungen bedeuten. Ein Sensor am Fabrik-Switch arbeitet normalerweise als Client. Ein Wartungs-Access-Point vergibt möglicherweise nur Adressen an das Smartphone eines Technikers. Ein Routing-Gateway kann eine WAN-Adresse beziehen und gleichzeitig ein separates LAN versorgen. Eine Bridge leitet dagegen möglicherweise Client-Broadcasts an einen vorhandenen Server weiter; ein zusätzlicher Server auf dieser Bridge würde die gesamte Broadcast-Domäne beeinflussen.

Produktrolle	Adressvergabe	Zu dokumentierende Entscheidung
Endgerät im Fabriknetz	Client am Uplink	Die IT verwaltet Subnetz, Lease- und DNS-Regeln
Lokaler Einrichtungs-AP	Server auf der Einrichtungsschnittstelle	Nur lokaler Zugriff oder Internetweiterleitung
Routing-Gateway	WAN-Client und LAN-Server	Getrennte Subnetze und ausdrückliche Weiterleitungsregeln
Transparente Bridge	Vorhandener Netzwerkserver versorgt angeschlossene Clients	Managementadresse und Broadcast-Grenzen

Beschriften Sie physische Anschlüsse ebenso wie Linux-Schnittstellen. Eine PCB-Änderung, ein USB-Adapter oder ein Treiberupdate kann die Enumerierung verändern. Dokumentieren Sie im Release die vorgesehene Zuordnung zwischen Anschluss, MAC-Adresse, Bridge-/VLAN-Mitgliedschaft und Netzwerkrolle.

Das Clientverhalten nach der ersten Lease festlegen

Die erste Zuweisung umfasst normalerweise Discover, Offer, Request und Acknowledgement. Danach gelten Laufzeit, Erneuerung und Rebinding; das Gerät darf eine abgelaufene Lease nicht weiter als gültig behandeln. Diese Übergänge beschreibt RFC 2131. Die Abnahme sollte auch spätere Übergänge prüfen und nicht nach einem erfolgreichen Kaltstart enden.

Definieren Sie anwendungsseitig sichtbare Zustände: Link nicht verfügbar, Konfiguration wird bezogen, Adresse gültig, lokales Netzwerk erreichbar und Anwendungsendpunkt erreichbar. Eine DHCP-Bestätigung liefert Konfiguration; sie prüft weder DNS noch Internetzugang oder den MQTT-Dienst. Oberfläche und Diagnoseprotokoll müssen diese Zustände unterscheiden können.

Der Netzwerkverantwortliche sollte festlegen, ob der Client Standardroute und DNS-Einstellungen übernimmt, welche Identität er sendet und ob eine Reservierung unterstützt wird. Dokumentieren Sie erwartete Optionen wie Subnetzmaske, Router und DNS-Server anhand von RFC 2132. Eine feste Adresse sollte nur vorausgesetzt werden, wenn dies mit der Standort-IT abgestimmt ist.

Bei mehreren Schnittstellen müssen Routenpriorität und DNS-Verantwortung feststehen. Zwei Netzwerkmanager auf derselben Schnittstelle können gegenseitig ihre Adressen überschreiben. Zwei gültige Leases auf verschiedenen Schnittstellen können dennoch eine unbeabsichtigte Standardroute installieren. Bestimmen Sie je Schnittstelle einen Konfigurationsverantwortlichen und testen Sie das Zusammenspiel mit Mobilfunkmanager, statischem Serviceport und Container-Bridge.

Den Server im autorisierten Segment halten

Der Einrichtungsserver sollte erst starten, wenn seine Schnittstelle die vorgesehene lokale Adresse hat. Beschränken Sie die Empfangsschnittstellen und prüfen Sie, dass Angebote niemals am Fabrik-Uplink erscheinen. Ein auf allen Schnittstellen lauschender Dienst kann zusammen mit einer versehentlichen Bridge zum unerwünschten DHCP-Server werden. Firewallregeln sind eine zusätzliche Grenze, kein Ersatz für korrekte Schnittstellenzuständigkeit.

Trennen Sie Adressvergabe, Routing, DNS-Weiterleitung und NAT. Eine zugewiesene Smartphone-Adresse bedeutet nicht, dass das Gateway Internetzugang bereitstellt. Legen Sie bei rein lokaler Einrichtung fest, wie die App das Gerät erreicht, wenn das Telefon „kein Internet“ meldet. Prüfen Sie den dokumentierten manuellen Zugang auch bei vorhandenem Captive Portal.

Das folgende dnsmasq-Beispiel versorgt ein dediziertes Einrichtungssegment ohne Standardrouter- oder DNS-Ankündigung. Vorausgesetzt werden die separat konfigurierte Adresse 192.168.77.1/24 auf br-setup, keine Verbindung zu einem anderen DHCP-versorgten Segment und ein vorhandenes beschreibbares Lease-Verzeichnis. Prüfen Sie die Optionen im dnsmasq-Handbuch der installierten Version. Dies ist ein Labor-Ausgangspunkt, keine vollständige Netzwerk- oder Sicherheitskonfiguration.

# Dedicated local commissioning interface only
interface=br-setup
bind-interfaces
port=0
dhcp-range=192.168.77.20,192.168.77.60,255.255.255.0,10m
dhcp-option=3
dhcp-option=6
dhcp-leasefile=/data/dhcp/setup.leases

Soll das Produkt Internetverkehr routen, spezifizieren Sie dies separat und setzen Sie passende Router-/DNS-Optionen. Bei dynamisch angelegten Schnittstellen ist das Start- und Neustartverhalten des Dienstes zu prüfen; eine dauerhaft korrekte Bindung darf nicht vorausgesetzt werden. Das nachgelagerte Subnetz darf sich nicht mit dem Uplink-Subnetz überschneiden. Für Konflikte ist ein kontrollierter Änderungsablauf vorzusehen.

Konflikte, Pool-Erschöpfung und beständige Identität definieren

Der Adresspool muss gleichzeitige Clients, alte noch gültige Leases und häufige Wechsel während der Inbetriebnahme abdecken. Smartphones können private WLAN-Adressen verwenden; dasselbe Telefon behält daher nicht zwingend dauerhaft dieselbe MAC-Identität. Begrenzen Sie missbräuchlichen Anfrageverkehr und definieren Sie die Installateurmeldung bei vollem Pool.

Entscheiden Sie, ob Server-Leases Neustarts überstehen. Eine verlorene Lease-Datenbank erzeugt nicht zwangsläufig sofort eine Kollision, verändert aber die Informationsbasis für eine sichere Wiederverwendung von Adressen. Speichern Sie sie nach der vorgesehenen Persistenzregel und testen Sie Neustarts mit weiterhin verbundenen Clients. Löschen Sie nicht sämtliche Geräteeinstellungen, um ein einzelnes DHCP-Problem zu beheben.

Doppelte IPv4-Adressen brauchen eine sichtbare Fehlermeldung und eine Wiederherstellungsregel. RFC 5227 beschreibt ARP-basierte Adresskonflikterkennung. Prüfen Sie das tatsächliche Verhalten des Client-/Server-Stacks und zeichnen Sie den Konfliktverkehr auf. Ein erfolgreicher Ping kann verdecken, dass ein anderer Host zeitweise für dieselbe Adresse antwortet.

Eine fehlerorientierte Abnahmematrix verwenden

Fehlerinjektion	Beobachten	Vorgeschlagenes Bestehenskriterium
Server beim Start fehlt und später zurückkehrt	Wiederholungen, CPU, Anwendungszustand	Begrenzter Ressourcenbedarf; automatische Konfiguration innerhalb des vereinbarten Zeitbudgets
Kurze Test-Lease; Erneuerung, danach alle Antworten blockieren	Renew-, Rebind- und Ablaufübergänge	Keine Anwendungsnutzung abgelaufener Leases; nach Rückkehr kein Geräteneustart nötig
DHCP ändert Router oder DNS	Routen, Resolver und bestehende Verbindungen	Neue Konfiguration aktiv; Verbindungen gemäß Anwendungsregel wiederhergestellt
Serverneustart bei aktiven Clients	Lease-Datenbank und doppelte Vergabe	Keine doppelte Vergabe in der getesteten Population
Pool erschöpft oder statischer Host im Konflikt	Protokolle und Installateuranzeige	Konkrete Fehlermeldung; definierte Wiederherstellung ohne Schäden an anderen Einstellungen
WAN und Einrichtungs-AP gleichzeitig aktiv	Mitschnitte beider Schnittstellen	Einrichtungsangebote bleiben im vorgesehenen Segment

Wählen Sie Zeitgrenzen nach Installationsbedarf und unterstützten Lease-Werten. Dokumentieren Sie Lease-Dauer, Firmware, Dienstkonfiguration, Routermodell und Client-Betriebssystem zu jedem Ergebnis. Wiederholen Sie Servertests mit allen unterstützten Smartphone-/Laptop-Familien; ein erfolgreicher Laptop ist kein ausreichender Nachweis für mobile Inbetriebnahme.

Den ersten fehlenden Übergang untersuchen

Erstellen Sie in einem autorisierten Labor Mitschnitte jeweils einer Schnittstelle. Die folgenden Diagnosebeispiele benötigen die im jeweiligen Abbild vorhandenen Werkzeuge und richtigen Schnittstellennamen:

ip -br link
ip -4 address show dev eth0
ip -4 route show
tcpdump -ni eth0 -vv 'udp port 67 or udp port 68 or arp'

Fehlt Discover, prüfen Sie Schnittstelle, Prozess und Konfigurationsverantwortung. Discover ohne Offer weist auf VLAN, Server, Relay oder Filter hin. Eine Bestätigung ohne nutzbare Adresse deutet auf Client-Hooks oder die Integration des Netzwerkmanagers. Bei gültiger Adresse und fehlerhaften Hostnamen prüfen Sie DNS; bei funktionierendem DNS und ausgefallenem Dienst die Anwendung. Bewahren Sie Zeitstempel und Transaktions-IDs auf und anonymisieren Sie Clientkennungen vor Weitergabe außerhalb des Projekts.

Aus der Topologie einen Lieferumfang ableiten

Obeitas Dienstleistung für Gerätevernetzung unterstützt die Definition von Schnittstellenrollen und Netzwerkabnahme. Das ausgelieferte RK3528-Netzwerkgateway-Projekt zeigt getrennte Ethernet-Pfade und vorgeschlagene LAN-/WAN-Rollen; sie belegt kein getestetes DHCP-Verhalten in Ihrem Netzwerk.

Stellen Sie für die Bewertung Anschluss-/VLAN-Diagramm, Clientumfang, lokale DHCP-Vorgaben, Einrichtungsanforderungen und aktuelles Abbild bereit. Vereinbaren Sie Konfigurationsverantwortung, Fehlermeldungen, Mitschnittverfahren und Testmatrix, bevor „DHCP unterstützt“ zum Abnahmehäkchen wird.