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

forme de l'article dhc

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

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

@ -18,7 +18,7 @@ Le serveur DHCP fonctionnait avec les autres ordinateurs.
## 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.
Il faut savoir que certains messages sont envoyés en UNICAST, d'autres en BROADCAST, qu'il y a d'autres messages et bien d'autres cas.
```raw
Client Serveur
@ -46,6 +46,7 @@ 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
@ -75,24 +76,29 @@ Mais d'où vient ce problème ?
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.
### Outils
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.
Dans le cas d'un protocole inconnu, `-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
```
### Messages envoyés
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`.
Ce qui confirme bien ma thèse suite à la lecture des logs.
Les paquets `OFFER` sont quasiment identiques. Les deux seules différences sont :
### Comparaison des deux paquets OFFER
* Celui avec les deux gateways fait 4 octets de plus (on notera que c'est aussi la taille d'une ipv4).
Après comparaison du dump hexadecimal des deux paquets `OFFER`, ces derniers 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, et c'est du à la seconde adresse.
* 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
```