arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Better article

Browse source
This commit is contained in:
Quentin Dufour 2017-02-10 14:24:16 +01:00
parent 494d426c31
commit ab4743bb40
1 changed files with 24 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
_posts/2017-02-10-dhcp-gateways.md
View file

@ -1,9 +1,9 @@
--- ---
layout: post layout: post
slug: bloque-a-la-recuperation-de-l-adresse-ip slug: passerelles-et-dhcp
status: published status: published
title: Bloqué à la récupération de l'adresse IP title: DHCP et la gestion des passerelles
description: Vous dites ? Une norme ? description: DHCP DISCOVER
disqus: true disqus: true
categories: categories:
- systeme - systeme
@ -15,7 +15,10 @@ Après une récente modification de mon serveur DHCP, je me retrouvais dans l'im
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. 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. Le serveur DHCP fonctionnait avec les autres ordinateurs.
## Fonctionnement (simplifié) de DHCP ## Le protocole
C'est une version simplifiée et probablement plutot fausse des échanges de message entre un client et un serveur DHCP.
Il faut savoir que certains messages sont envoyés en UNICAST, d'autres en BROADCAST, qu'il y a d'autres messages et bein d'autres cas.
```raw ```raw
Client Serveur Client Serveur
@ -25,17 +28,13 @@ Client Serveur
|<------ ACK ------| |<------ ACK ------|
``` ```
Le client demande une adresse, le serveur lui en propose une, le client accepte. Pour faire simple, le client demande une adresse, le serveur lui en propose une, le client la prend, le serveur accuse bonne réception.
*Il est intéressant de noter que BOOTP est l'ancêtre de DHCP et que DHCP est rétro compatible avec BOOTP. De ce fait, la plus part du paquet DHCP va être vide, et les paramètres DHCP vont se trouver dans les options du paquet BOOTP.*
## Logs ## Logs
J'ai commencé par regarder les logs de `isc-dhcp-server`. 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 ```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]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa (android-xx) via br0
@ -44,8 +43,16 @@ dhcpd[2207]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa
dhcpd[2207]: DHCPOFFER on 192.168.1.77 to 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
``` ```
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
Il semble ici que le terme *DHCPREQUEST* fasse référence à un message *DISCOVER* DHCP. Il semble ici que le terme *DHCPREQUEST* fasse référence à un message *DISCOVER* DHCP.
Je suppose donc que la tablette envoie des requêtes *DISCOVER* et que le serveur lui envoie un paquet *OFFER* auquel la tablette ne répond pas.
## Modification de la configuration en aveugle ## 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. 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.
@ -76,7 +83,7 @@ sudo tcpdump -i br0 -vv -e -n port 67 or port 68 and ether host aa:aa:aa:aa:aa:a
``` ```
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`. 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. Ce qui confirme bien ma thèse suite à la lecture des logs.
Les paquets `OFFER` sont quasiment identiques. Les deux seules différences sont : Les paquets `OFFER` sont quasiment identiques. Les deux seules différences sont :
@ -93,6 +100,8 @@ Default-Gateway Option 3, length 4: 192.168.1.254
Default-Gateway Option 3, length 8: 192.168.1.254,192.168.1.1 Default-Gateway Option 3, length 8: 192.168.1.254,192.168.1.1
``` ```
A la suite de ça, je suppose donc que c'est le client DHCP qui ne sait pas quoi faire de ces deux gateways.
## Etude du client DHCP ## Etude du client DHCP
Le protocole DHCP indique que le client doit envoyer son nom : Le protocole DHCP indique que le client doit envoyer son nom :
@ -101,6 +110,7 @@ Le protocole DHCP indique que le client doit envoyer son nom :
Vendor-Class Option 60, length 16: "android-dhcp-6.0" 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 ? Je connais maintenant le nom du client DHCP utilisé par la tablette.
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* *A suivre*