Le protocole DHCP permet à un hôte de contacter un serveur central qui maintient une liste d'adresses IP qui peuvent être assignées dans un ou plusieurs sous-réseaux. Un client DHCP peut requérir une adresse de cette liste, et l'utiliser pendant une durée temporaire pour communiquer sur le réseau. Le protocole DHCP fournit également un mécanisme par lequel un client peut obtenir des détails importants du réseau auquel il est rattaché, tels que l'adresse du routeur par défaut, du serveur de nom, etc.
Au démarrage, dhclient lit le fichier dhclient.conf pour les instructions de configuration. Il obtient alors la liste de toutes les interfaces réseaux du système à configurer. Il tente alors de configurer chaque interface avec le protocole DHCP.
Pour garder la trace des concessions en dépit des redémarrages du système ou du serveur, dhclient garde la liste des concessions qui lui ont été assignées dans le fichier dhclient.leases(5). Au démarrage, après avoir lu le fichier dhclient.conf, dhclient lit le fichier dhclient.leases pour se rafraîchir la mémoire à propos des concessions qu'il a reçues.
Quand une nouvelle concession est acquise, elle est ajoutée à la fin du fichier dhclient.leases. Pour éviter que ce fichier ne deviennent gigantesque, de temps en temps, dhclient créer un nouveau fichier dhclient.leases depuis sa base de données interne. L'ancienne version de dhclient.leases est conservée sous le nom dhclient.leases~ jusqu'à la prochaine réécriture de la base de données.
Les anciennes concessions sont conservées au cas où le serveur DHCP serait injoignable lors de la première invocation de dhclient (généralement lors de la phase de démarrage initiale du système). Dans ce cas, les anciennes concessions du fichier dhclient.leases qui n'ont pas encore expiré sont testées, et si elles sont considérées valides, elles sont utilisées jusqu'à ce qu'elles expirent ou que le serveur DHCP devienne disponible.
Un hôte mobile qui peut avoir besoin d'accéder de temps en temps à un réseau sur lequel il n'y a pas de serveur DHCP, peut être préchargé avec une concession pour une adresse statique de ce réseau. Quand toutes les tentatives de contacter le serveur DHCP auront échoué, le dhclient essayera de valider la concession statique, et en cas de succès, il utilisera jusqu'à ce qu'il redémarre.
Un hôte mobile peut aussi voyager sur des réseaux sur lesquels DHCP n'est pas disponible, mais BOOTP l'est. Dans ce cas, il peut être avantageux de s'arranger avec l'administrateur réseau pour obtenir une entrée dans la base de données BOOTP, ainsi l'hôte démarrera plus rapidement sur ce réseau plutôt que de faire une boucle dans la liste des anciennes concessions.
Les noms des interfaces réseaux que dhclient doit tenter de configurer peuvent être spécifiés sur la ligne de commande. Si aucun nom d'interface n'est indiqué sur la ligne de commande, dhclient identifiera si possible toutes les interfaces réseaux, en éliminant celles qui ne permettent pas la diffusion, et tentera de configurer chacune d'elles.
Il est aussi possible de spécifier les interfaces par nom dans le fichier dhclient.conf(5). Si les interfaces sont spécifiées de cette manière, alors le client configurera seulement les interfaces spécifiées dans le fichier de configuration ou sur la ligne de commande, et ignorera toutes les autres interfaces.
Si le client DHCP doit écouter et transmettre sur un autre port que celui par défaut (port 68), le paramètre -p peut être utilisé. Il doit être suivi du numéro de port UDP que dhclient doit utiliser. C'est surtout utile pour débogguer. Si un port différent est spécifié pour écouter et transmettre, le client utilisera aussi un port de destination différent - augmenté de 1 par rapport au port de destination spécifié.
Le client DHCP transmet normalement tous ses messages protocolaires avant d'acquérir une adresse IP, vers 255.255.255.255, l'adresse IP de diffusion limitée. À des fins de mise au point, il peut être utile que le serveur transmette ses messages à une autre adresse. Ceci peut être fait avec le paramètre -s, suivi par l'adresse IP ou le nom de domaine de la destination.
À des fins de tests, le champ giaddr de tous les paquets que le client envoie peut être positionné avec le paramètre -g, suivi par l'adresse IP à envoyer. Ce n'est utile que pour le test, et n'est pas censé marcher de manière consistante ou utile.
Le client DHCP fonctionne au premier plan jusqu'à ce qu'il ait configuré l'interface, puis il poursuit son fonctionnement en arrière plan. Pour forcer dhclient à fonctionner toujours en tant que processus d'avant-plan, le paramètre -d doit être spécifié. C'est utile quand le client fonctionne au sein d'un débogguer, ou en dehors de l'inittab sur les systèmes System V.
Le client affiche normalement un message de démarrage et la séquence du protocole sur la sortie standard jusqu'à ce qu'il acquière une adresse, et enregistre les messages de log en utilisant le mécanisme syslog(3). Le paramètre -q empêche que les messages autres que ceux d'erreurs soient écrits sur la sortie d'erreur standard.
Normalement le client ne libère pas la concession courante car ce n'est pas requis par le protocole DHCP. Certains fournisseurs d'accès à Internet exigent que leurs clients notifient le serveur s'ils veulent libérer l'adresse IP assignée. Le paramètre -r libère explicitement la concession courante, et une fois que la concession a été libérée, le client quitte.
Avec le paramètre -1, dhclient n'essaye qu'une seule fois d'obtenir une concession. S'il échoue, dhclient quitte avec le code de sortie égal à 2.
Normalement, le client DHCP prend ses informations de configurations dans /etc/dhclient.conf, stocke sa base de données des concessions dans /var/state/dhcp/dhclient.leases, enregistre son numéro de processus dans le fichier /var/run/dhclient.pid, et configure l'interface réseau en utilisant /sbin/dhclient-script. Pour spécifier d'autres fichiers, il faut utiliser respectivement les paramètres -cf, -lf, -pf et -sf suivi par le nom du fichier. C'est particulièrement utile si, par exemple, /var/state/dhcp ou /var/run n'ont pas encore été montés quand le client DHCP démarre.
Normalement, le client DHCP quitte s'il ne parvient pas à identifier une interface réseau à configurer. Sur un ordinateur portable et plus généralement tout ordinateur avec des bus d'entrées-sorties supportant la permutation à chaud, il est possible qu'une interface soit ajoutée après le démarrage du système. Le paramètre -w peut être utiliser pour que le client ne quitte pas s'il ne parvient pas à trouver une telle interface. Le programme omshell(8) peut être utiliser pour notifier au client qu'une interface réseau à été ajoutée ou supprimée, et que le client peut tenter de configurer une adresse IP pour cette interface.
On peut indiquer explicitement au client DHCP de ne pas tenter de configurer une interface en utilisant le paramètre -n. C'est souvent utile en combinaison avec le paramètre -w.
Le client peut devenir un processus démon (daemon) immédiatement, plutôt que d'attendre d'avoir acquis une adresse IP. Pour cela, il suffit d'utiliser le paramètre -nw.
Plutôt que d'implémenter directement la couche sous le protocole OMAPI directement, les programmes utilisateurs devrait utiliser l'API dhcpctl ou OMAPI lui-même. Dhcpctl est une enveloppe qui fait un peu de ménage que OMAPI ne fait pas automatiquement. Dhcpctl et OMAPI sont documentés dans dhcpctl(3) et omapi(3). La plupart des choses que vous voudrez faire avec le client peut être fait directement en utilisant la commande omshell(1), plutôt que de devoir écrire un programme spécial.
L'objet contrôle a un attribut - l'état attribut. Pour arrêter le client, positionnez l'état attribut à 2. Il y aura alors automatiquement un message DHCPRELEASE. Pour le mettre en pause, positionner l'état attribut à 3. Pour reprendre après une pause, positionnez l'état attribut à 4.
Ce client a été substantiellement modifié et amélioré par Elliot Poger pour l'utiliser sous Linux alors qu'il travaillait sur le projet MosquitoNet à Stanford.
La version actuelle doit beaucoup aux améliorations d'Elliot pour Linux, mais elle a été substantiellement réorganisée et partiellement réécrite par Tel Lemon pour utiliser le même cadre de travail réseau que celui utilisé par le serveur DHCP de l'Internet Software Consortium. La plupart du code spécifique à un système d'exploitation a été déplacé dans un script shell, pour qu'au fur à mesure que le support pour d'autres systèmes d'exploitations est ajouté, il ne soit pas nécessaire de porter et de maintenir du code pour ces systèmes d'exploitations. À la place le script shell peut invoquer les outils natifs pour accomplir la même tâche.