DHCP client et serveur sous Linux embarqué : définir les exigences
Un équipement embarqué a besoin d’un client DHCP lorsqu’il reçoit sa propre configuration IPv4 d’un réseau existant. Il a besoin d’un serveur DHCP lorsqu’il attribue une configuration à des équipements en aval ou à un téléphone de mise en service. Une passerelle peut nécessiter les deux rôles, sur des interfaces distinctes et définies. Le cahier des charges doit préciser ces interfaces, les responsables de leur configuration et leur comportement en cas de panne avant de choisir un démon ou d’ajouter des paquets à l’image Linux.
Ce guide traite du DHCP IPv4 dans les produits Linux embarqués. Les annonces de routeur IPv6 et DHCPv6 demandent une conception séparée. Les configurations et essais ci-dessous sont des propositions d’ingénierie, pas des résultats d’un déploiement Obeita.
Commencer par la topologie d’installation
« Prendre en charge DHCP » peut recouvrir plusieurs interprétations incompatibles. Un capteur raccordé au commutateur d’une usine est généralement client. Un point d’accès de maintenance peut ne servir que le téléphone du technicien. Une passerelle routée peut obtenir une adresse WAN et desservir un LAN séparé. Un pont peut simplement transmettre les diffusions des clients à un serveur existant ; ajouter un autre serveur sur ce pont affecterait tout le domaine de diffusion.
| Rôle du produit | Attribution des adresses | Décision à consigner |
|---|---|---|
| Terminal du réseau d’usine | Client sur la liaison montante | L’informatique gère sous-réseau, baux et DNS |
| AP local de configuration | Serveur sur l’interface de configuration | Accès local uniquement ou transfert vers Internet |
| Passerelle routée | Client WAN et serveur LAN | Sous-réseaux séparés et règles explicites de transfert |
| Pont transparent | Le serveur réseau existant dessert les clients raccordés | Adresse de gestion et limites de diffusion |
Étiquetez les ports physiques en plus des noms Linux. Une révision de carte, un adaptateur USB ou une mise à jour de pilote peut modifier l’énumération. Conservez dans la documentation de livraison l’association prévue entre connecteur, adresse MAC, appartenance au pont/VLAN et rôle réseau.
Spécifier le comportement du client après le premier bail
L’attribution initiale comprend normalement découverte, offre, demande et acquittement. L’adresse louée possède ensuite une durée de validité, un renouvellement et un mécanisme de réassociation ; un appareil ne doit pas continuer à considérer un bail expiré comme valide. Ces transitions sont définies dans la RFC 2131. La recette doit couvrir les transitions ultérieures, sans s’arrêter à un démarrage à froid réussi.
Définissez les états visibles par l’application : liaison indisponible, acquisition de configuration, adresse valide, réseau local accessible et service applicatif accessible. Un acquittement DHCP établit la configuration ; il ne vérifie ni DNS, ni Internet, ni votre service MQTT. L’interface et les journaux doivent permettre de distinguer ces états.
Le responsable réseau doit décider si le client accepte une route par défaut et des paramètres DNS, quelle identité il transmet et s’il permet une réservation. Documentez les options attendues, notamment masque, routeur et serveur DNS, en vous référant à la RFC 2132. Évitez de rendre le produit dépendant d’une adresse particulière sans accord de l’informatique du site.
Pour plusieurs interfaces, précisez la priorité des routes et la responsabilité du DNS. Deux gestionnaires réseau sur la même interface peuvent écraser leurs adresses respectives. Deux baux valides sur des interfaces différentes peuvent néanmoins installer une route par défaut non souhaitée. Désignez un responsable de configuration par interface et testez l’ensemble avec le gestionnaire cellulaire, le port de maintenance statique et le pont des conteneurs.
Maintenir le serveur dans son segment autorisé
Le serveur de configuration ne doit démarrer qu’après l’attribution de l’adresse locale prévue à son interface. Limitez les interfaces d’écoute et vérifiez qu’aucune offre ne sort vers le réseau d’usine. Une écoute globale associée à un pont accidentel peut produire un serveur DHCP indésirable. Le pare-feu constitue une limite supplémentaire, sans remplacer une affectation correcte des interfaces.
Séparez attribution des adresses, routage, relais DNS et NAT. Recevoir une adresse sur un téléphone ne signifie pas que la passerelle fournit Internet. Pour une configuration exclusivement locale, prévoyez comment l’application joint l’équipement lorsque le téléphone indique « pas d’Internet ». Vérifiez la méthode manuelle documentée même si un portail captif est fourni.
L’extrait dnsmasq suivant dessert un segment dédié sans annoncer de routeur par défaut ni de serveur DNS. Il suppose br-setup configuré séparément en 192.168.77.1/24, aucune liaison vers un autre segment doté de DHCP et un répertoire de baux existant et inscriptible. Vérifiez les options dans le manuel dnsmasq de la version installée. Il s’agit d’un point de départ en laboratoire, pas d’une configuration réseau et sécurité complète.
# 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.leasesSi le produit doit router le trafic Internet, spécifiez-le séparément et fournissez les bonnes options routeur/DNS. Si les interfaces sont créées dynamiquement, testez le démarrage et le redémarrage du démon sans supposer que son association reste correcte. Vérifiez l’absence de chevauchement entre sous-réseaux amont et aval ; prévoyez une procédure contrôlée de modification en cas de conflit.
Définir conflits, épuisement du pool et identité persistante
Le pool doit tenir compte des clients simultanés, des anciens baux encore valides et des changements fréquents pendant la mise en service. Les téléphones peuvent utiliser des adresses Wi-Fi privées : le même appareil ne conserve pas nécessairement une identité MAC permanente. Limitez les demandes abusives et définissez le message présenté à l’installateur lorsque le pool est plein.
Décidez si les baux du serveur survivent au redémarrage. Perdre leur base ne provoque pas forcément une collision immédiate, mais change les informations disponibles pour réutiliser les adresses sans risque. Appliquez la politique de persistance prévue et testez le redémarrage avec des clients toujours connectés. N’effacez pas tous les réglages de l’équipement pour résoudre un seul problème DHCP.
Une adresse IPv4 dupliquée exige un défaut visible et une politique de récupération. La RFC 5227 décrit la détection des conflits par ARP. Vérifiez les mécanismes réellement implémentés par votre pile client/serveur et capturez le trafic conflictuel. Un ping réussi peut masquer un second hôte répondant par intermittence à la même adresse.
Utiliser une matrice de recette orientée défaillances
| Injection | Observation | Critère proposé |
|---|---|---|
| Serveur absent au démarrage, puis rétabli | Délais de reprise, CPU, état applicatif | Ressources bornées ; acquisition automatique dans le délai convenu |
| Bail court ; bloquer les renouvellements puis toutes les réponses | Renouvellement, réassociation et expiration | Aucune utilisation applicative du bail expiré ; reprise sans redémarrer l’équipement |
| DHCP change le routeur ou le DNS | Routes, résolveur et connexions existantes | Nouvelle configuration appliquée ; connexions rétablies selon la politique applicative |
| Redémarrage serveur avec clients actifs | Base de baux et doubles attributions | Aucune attribution dupliquée dans la population testée |
| Pool épuisé ou hôte statique conflictuel | Journaux et réponse à l’installateur | Défaut précis ; récupération définie sans altérer d’autres réglages |
| WAN et AP de configuration actifs simultanément | Captures des deux interfaces | Offres de configuration limitées au segment prévu |
Choisissez les seuils temporels selon l’installation et les baux pris en charge. Joignez à chaque résultat durée du bail, firmware, configuration du démon, modèle du routeur et système du client. Pour un serveur DHCP, répétez avec les familles de téléphones et d’ordinateurs supportées ; un ordinateur fonctionnel ne suffit pas à valider une procédure mobile.
Diagnostiquer la première transition manquante
Dans un laboratoire autorisé, capturez une interface à la fois. Ces commandes sont des exemples de diagnostic ; noms d’interfaces et utilitaires disponibles varient selon l’image :
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'L’absence de découverte suggère un problème d’interface, de processus ou de responsabilité de configuration. Une découverte sans offre oriente vers VLAN, serveur, relais ou filtrage. Un acquittement sans adresse exploitable suggère un script client ou l’intégration au gestionnaire réseau. Une adresse valide avec résolution des noms défaillante appelle un contrôle DNS ; un DNS fonctionnel avec service défaillant appelle un diagnostic applicatif. Conservez horodatages et identifiants de transaction, puis anonymisez les identifiants clients avant tout partage hors projet.
Transformer la topologie en périmètre de livraison
Le service de connectivité des équipements d’Obeita permet de cadrer les rôles des interfaces et la recette réseau. La réalisation livrée de passerelle RK3528 illustre différents chemins Ethernet et des rôles LAN/WAN proposés ; elle ne démontre pas un comportement DHCP testé sur votre réseau.
Pour une évaluation, fournissez le schéma connecteurs/VLAN, la population cliente, les contraintes DHCP du site, les exigences de configuration locale et l’image actuelle. Convenez du responsable de configuration, des erreurs visibles, de la capture et de la matrice d’essai avant de cocher « DHCP pris en charge ».
