2 votes

Mauvais comportement du DHCP

Le serveur DHCP de l'ISC fonctionne sous Fedora 10. Comme il ne fait rien d'autre, personne n'a pris la peine de le mettre à jour... J'ai remarqué un comportement qui me semble très étrange : le serveur DHCP reçoit un DISCOVER en broadcast, envoie un OFFER en unicast au relais DHCP - et immédiatement après envoie le même offer en bcast.

Le client lui-même se comporte mal, il envoie continuellement des paquets DHCP DISCOVER, mais je ne pense pas que cela puisse amener le serveur à diffuser l'offre. Quelqu'un a-t-il une idée de la raison pour laquelle cela peut se produire - s'agit-il d'une caractéristique de ce serveur d'un autre âge ?

1voto

MariusMatutiae Points 45233

Je ne suis pas sûr qu'il se comporte vraiment mal. DHCP est discipliné par RFC2131 qui stipule explicitement (vous pouvez vérifier vous-même, en haut de la page 24) que DHCPOFFER, DHCPACK, DHCPNAK sont envoyés au client par unicast, sauf que certaines implémentations de clients n'autorisent pas la réception de tels unicasts tant qu'une adresse IP appropriée n'a pas été configurée.

Ces implémentations mettent le bit BROADCAST dans le champ "flags" à 1 dans tout mesage DHCPDISCOVER ou DHCPREQUEST, ce qui indique au serveur et à l'agent de relais bootp d'utiliser une distribution par diffusion au lieu de la distribution par monodiffusion (plus habituelle).

EDIT :

Oui, tout à fait : il semble que votre serveur, qui n'a presque jamais été utilisé, dispose d'une de ces implémentations DHCP de type "broadcast-only". Cependant, si vous voyez son message DHCPDISCOVER initial avec tcpdump/wireshark, vous pouvez vérifier vous-même si le bit de diffusion est activé ou non, il n'est pas nécessaire de deviner.

Vous pouvez vous simplifier la vie en utilisant dhcpdump au lieu de travailler à travers les filtres de l'un ou l'autre tcpdump o wireshark Il s'agit d'un logiciel qui ne capture que les paquets dhcp et qui les présente de manière facilement accessible. Par exemple, sur mon réseau domestique, j'ai capturé cette requête :

 $ sudo dhcpdump -i wlan0
  TIME: 2014-06-14 18:52:31.848
    IP: 0.0.0.0 (f8:1a:67:aa:80:56) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 0
 XID: 10929113
 SECS: 0
 FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:07:88:e8:6c:cf:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
OPTION:  50 (  4) Request IP address        192.168.11.52
OPTION:  57 (  2) Maximum DHCP message size 1500
OPTION:  60 ( 12) Vendor class identifier   dhcpcd-5.5.6
OPTION:  12 ( 24) Host name                 android-e0cf12b56a84f291
OPTION:  55 (  9) Parameter Request List      1 (Subnet mask)
                                         33 (Static route)
                                          3 (Routers)
                                          6 (DNS server)
                                         15 (Domainname)
                                         28 (Broadcast address)
                                         51 (IP address leasetime)
                                         58 (T1)
                                         59 (T2)

La ligne qui nous intéresse est la suivante :

 FLAGS: 7f80

Il s'agit bien sûr d'un nombre au format hexadécimal, dont le premier Le bit est 0 : ainsi, d'après l'avis du RFC2131, page dix Il s'agit d'une demande qui accepte une réponse unicast. Si le tout premier bit avait été un 1 il aurait alors signalé que le client DHCP avait besoin d'un diffusion répondre.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X