106 lines
3.7 KiB
Markdown
106 lines
3.7 KiB
Markdown
---
|
|
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
|
|
|---- DISCOVER --->|
|
|
|<----- OFFER -----|
|
|
|---- REQUEST ---->|
|
|
|<------ ACK ------|
|
|
```
|
|
|
|
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.
|
|
J'ai des doutes sur la terminologie utilisée par le serveur DHCP vis à vis du nom des messages envoyés sur le réseau.
|
|
|
|
D'autant que Bootp utilise aussi les termes Request et Reply pour des cas différents :
|
|
* Une *Request* Bootp peut-être un message *Discover* DHCP
|
|
* Un *Reply* Bootp peut-être un message *Offer* DHCP
|
|
|
|
```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 semble ici que le terme *DHCPREQUEST* fasse référence à un message *DISCOVER* 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
|
|
```
|
|
|
|
Tout d'abord, dans le mode avec les deux gateways, on observe en boucle un message `DISCOVER` suivi d'un message `OFFER` et jamais de paquet `REQUEST`.
|
|
D'où mes doutes sur les logs du serveur DHCP.
|
|
|
|
Les paquets `OFFER` sont quasiment identiques. Les deux seules différences sont :
|
|
|
|
* 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.
|
|
|
|
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"
|
|
```
|
|
|
|
Mais comment débugger ça du côté d'android ? Retouver le code source ? Regarder les logs ? Mais où et comment faire quand on est pas root ?
|
|
|
|
*A suivre*
|