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

Une update

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

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

@ -18,10 +18,11 @@ Le serveur DHCP fonctionnait avec les autres ordinateurs.
## Fonctionnement (simplifié) de DHCP
```raw
Client Serveur
|--- DHCPREQUEST -->|
|<--- DHCPOFFER ----|
|----- DHCPACK ---->|
Client Serveur
|---- DISCOVER --->|
|<----- OFFER -----|
|---- REQUEST ---->|
|<------ ACK ------|
```
Le client demande une adresse, le serveur lui en propose une, le client accepte.
@ -29,7 +30,12 @@ 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.
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
@ -38,7 +44,7 @@ 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
```
Il semblerait donc que le client, notre tablette, n'aime pas la proposition du serveur DHCP.
Il semble ici que le terme *DHCPREQUEST* fasse référence à un message *DISCOVER* DHCP.
## Modification de la configuration en aveugle
@ -69,8 +75,13 @@ Dans le cas d'un protocole inconu, `-XX` permet d'avoir un hexdump. Les deux son
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.
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.
@ -90,4 +101,6 @@ Le protocole DHCP indique que le client doit envoyer son nom :
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*