forme de l'article dhc
This commit is contained in:
parent
ab4743bb40
commit
f4db33a307
1 changed files with 11 additions and 5 deletions
|
@ -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
|
||||
```
|
||||
|
|
Loading…
Reference in a new issue