quentin.dufour.io/_posts/2017-02-10-dhcp-gateways.md

94 lines
3 KiB
Markdown
Raw Normal View History

2017-02-10 13:00:05 +00:00
---
layout: post
slug: bloque-a-la-recuperation-de-l-adresse-ip
status: published
title: Bloqué à la récupération de l'adresse IP
description: Vous dites ? Une norme ?
disqus: true
categories:
- systeme
- linux
tags:
---
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
```raw
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.
```raw
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 :
```raw
option routers 192.168.1.254, 192.168.1.1;
```
En ne spécifiant qu'une seule passerelle, le problème est résolu :
```raw
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.
```raw
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.
```raw
Default-Gateway Option 3, length 4: 192.168.1.254
```
```raw
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 :
```raw
Vendor-Class Option 60, length 16: "android-dhcp-6.0"
```
*A suivre*