Tout d'abord, je vous prie de m'excuser si cette queston n'a pas sa place ici. J'ai un souci DHCP chez moi, à la maison, dans mon réseau domestique. N'hésitez pas à me guider vers le meilleur endroit où exposer mon problème.
Sinon, voici de quoi il s'agit.
Comme j'ai pas mal d'objets auxquels je souhaite donner une IP permenente, j'associe les MAC address avec l'adresse IP dans des réservations DHCP. La box internet de mon fournisseur n'étant vraiment pas pratique pour tenir à jour cette gestion, j'ai "depuis toujours" utilisé les rôles "serveur DHCP" et "serveur DNS" à une machine qui tourne Windows Server dont je n'ose pas publier la version ici.
Sur la box de mon FAI j'ai donc désactivé la fonction "serveur DHCP" et ça tourne ainsi depuis deux décennies...
Je me suis donc mis en tête de déplacer la fonction DNS+DHCP sur un raspberryPi dédié à cela, en utilisant dnsmasq. Ainsi mon réseau domestique ne sera plus mis en péril si mon vieux serveur Windows rend l'âme.
Dans cette nouvelle configuration, j'ai une poignée d'appareils qui n'arrivent pas à acquérir un lease DHCP, et pas de bol il y a mes 3 routeurs mesh de la marque Linksys/Belkin.
Toutes les 3 secondes l'appareil lance un DISCOVER, le Rpi .213 répond un OFFER avec la bonne IP .93, l'appareil fait un REQUEST, puis la box internet .1 renvoie un NAK et le RPI renvoie un ACK. Une demi-seconde plus tard, le serveur Windows .5 dont j'ai réactivé le service DHCP envoie à son tour un OFFER, ... et ainsi de suite toutes les 3 secondes.
D'après ta capture c'est l'équipement en .1 qui fait de la merde car il répond avec un "DHCP NAK" alors qu'a aucun moment il a été sélectionné dans le "DHCP Request".
Exemple avec la Frame 344 qui est un "DHCP Request", donc envoyé par le client au serveur DHCP sélectionné via un broadcast : Option: (54) DHCP Server Identifier (192.168.68.213) Length: 4 DHCP Server Identifier: 192.168.68.213
Donc normalement a partir de ce moment AUCUN serveur à part "192.168.68.213" devrait répondre (ou j'ai mal compris la rfc2131).
Par contre la capture provient de quel équipement (j'ai l'impression que cela viens du RPI en .213) ?
Car il serait intéressant d'avoir une capture au niveau de l'équipement 192.168.68.1 (possible avec un switch capable de faire du port mirroring).
Le .213 est effectivement le RPi, et c'est lui a capture la trace. Le .1 qui balance des NAK, c'est la B-box de mon FAI (Sagem rebranded Proximus).
C'est vrai qu'une trace en mode promiscuous de cette box permettrait de savoir tout le contexte autour de ces NAK indésirables.
Entre-temps j'ai eu une coupure de courant généralisée. Il y a des travaux partout ! Cette fois-ci c'est le renforcement des réseaux 400 volts. Le RPi a dû rebooter plus vite que le sagem. Tous les appareils ont obtenu leur lease, et les renew ont l'air de passer crème.
J'ai aussi commandé la fibre qui passe enfin chez moi, et je pense que la box de mon FAI (.1) sera remplacée. Il viennent le 21/4. On verra à ce moment-là. Entre-temps ça tient avec du pritt.
De rien et si jamais il y a une solution un poil plus radicale qui demande du matériel adapté, si tu as un switch mangeable capable de faire du DHCP Snooping, tu dis au switch d'interdire tout équipement sauf le RPI a donner des leases DHCP.
C'est plus utilisé en entreprise mais dans ce cas précis cela évite de se prendre la tête et peut fonctionner avec n'importe quel FAI
