3 KiB
| layout | slug | status | title | description | disqus | categories | tags | ||
|---|---|---|---|---|---|---|---|---|---|
| post | bloque-a-la-recuperation-de-l-adresse-ip | published | Bloqué à la récupération de l'adresse IP | Vous dites ? Une norme ? | true |
|
Après une récente modification de mon serveur DHCP, je me retrouvais dans l'impossibilité de connecter une tablette à mon réseau.
Cette dernière restait bloquée à Récupération de l'adresse IP. Après avoir un peu cherché sur internet, je n'ai pas trouvé de solution satisfaisante.
Le serveur DHCP fonctionnait avec les autres ordinateurs.
Fonctionnement (simplifié) de DHCP
Client Serveur
|--- DHCPREQUEST -->|
|<--- DHCPOFFER ----|
|----- DHCPACK ---->|
Le client demande une adresse, le serveur lui en propose une, le client accepte.
Logs
J'ai commencé par regarder les logs de isc-dhcp-server.
J'ai trouvé un long enchainement de DHCPOFFER et de DHCPREQUEST sans jamais trouver de DHCPACK.
dhcpd[2207]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPOFFER on 192.168.1.77 to aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPOFFER on 192.168.1.77 to aa:aa:aa:aa:aa:aa (android-xx) via br0
Il semblerait donc que le client, notre tablette, n'aime pas la proposition du serveur DHCP.
Modification de la configuration en aveugle
J'ai donc modifié la configuration de mon serveur DHCP en la simplifiant le plus possible, jusqu'à ce que ma tablette réussisse à se connecter. Le coupable était la ligne :
option routers 192.168.1.254, 192.168.1.1;
En ne spécifiant qu'une seule passerelle, le problème est résolu :
option routers 192.168.1.254;
Mais d'où vient ce problème ?
Traffic réseau
Je me suis demandé ce que pouvait bien envoyer isc-dhcp-server à ma tablette pour qu'elle n'en veuille pas.
J'ai donc comparé les paquets envoyé avec les deux configurations différentes.
Pour écouter le traffic réseau j'ai utilisé tcpdump. L'option -vv est bien pratique car elle permet d'expliquer le contenu du paquet.
Dans le cas d'un protocole inconu, -XX permet d'avoir un hexdump. Les deux sont combinables.
sudo tcpdump -i br0 -vv -e -n port 67 or port 68 and ether host aa:aa:aa:aa:aa:aa
Les paquets DHCPOFFER avec sont quasiment identiques. Celui avec les deux gateways fait 4 octets de plus (on notera que c'est aussi la taille d'une ipv4).
Des valeurs générés aléatoirements sont aussi différentes. Mais pour le reste, c'est identique.
En tout cas, tcpdump n'a pas de problème à décoder nos champs gateway dans les deux cas.
Default-Gateway Option 3, length 4: 192.168.1.254
Default-Gateway Option 3, length 8: 192.168.1.254,192.168.1.1
Etude du client DHCP
Le protocole DHCP indique que le client doit envoyer son nom :
Vendor-Class Option 60, length 16: "android-dhcp-6.0"
A suivre