From 494d426c3187dc587ff4eeddd5e0ab1d5b9f5e8d Mon Sep 17 00:00:00 2001 From: Quentin Dufour Date: Fri, 10 Feb 2017 14:14:39 +0100 Subject: [PATCH] Une update --- _posts/2017-02-10-dhcp-gateways.md | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/_posts/2017-02-10-dhcp-gateways.md b/_posts/2017-02-10-dhcp-gateways.md index a0a52d3..aaf36e7 100644 --- a/_posts/2017-02-10-dhcp-gateways.md +++ b/_posts/2017-02-10-dhcp-gateways.md @@ -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*