Dificuldade de DHCP

Question

O ISC DHCP Server está rodando no Fedora 10. Já que não está fazendo mais nada, ninguém se preocupou em atualizá-lo ... Eu notei um comportamento que me parece muito estranho: o servidor DHCP obtém um DISCOVER como broadcast, envia OFFER como unicast para o relé DHCP - e imediatamente depois envia a mesma oferta como um bcast.

O próprio cliente está se comportando mal, está continuamente enviando pacotes DHCP DISCOVER, mas eu não acho que isso possa fazer com que o servidor transfira a oferta. Alguém tem alguma idéia de por que isso pode acontecer - talvez seja uma característica desse servidor da Idade da Pedra?

    

Answer 1

Eu não tenho certeza se está realmente se comportando mal. O DHCP é disciplinado por RFC2131 , que estabelece explicitamente (você pode verificar-se, no topo da página 24) que DHCPOFFER, DHCPACK, O DHCPNAK é enviado ao cliente via entrega unicast, exceto que algumas implementações do cliente não permitem a recepção de tais unicasts até que um endereço IP correto tenha sido configurado.

Essas implementações definem o bit BROADCAST no campo 'flags' como 1 em qualquer DHCPDISCOVER ou Mensagens DHCPREQUEST, que por sua vez instrui o servidor e o agente de retransmissão de boot para usar uma transmissão de transmissão em vez da difusão unicast (mais usual).

EDITAR:

Sim, por todos os meios: parece que o seu servidor quase nunca usado tem uma dessas implementações DHCP somente de broadcast. No entanto, se você vir sua mensagem DHCPDISCOVER inicial com tcpdump / wireshark, poderá verificar se o bit de transmissão está definido ou não, não é necessário adivinhar.

Você pode tornar sua vida muito mais fácil usando o dhcpdump em vez de trabalhar com os filtros tcpdump ou wireshark , porque capture apenas pacotes dhcp e os apresente de maneira facilmente acessível. Por exemplo, na minha rede doméstica, capturei esta solicitação:

 $ 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)

A linha que nos interessa é:

 FLAGS: 7f80

Este é, obviamente, um número em formato hexadecimal, cujo primeiro bit é 0 : assim, de acordo com RFC2131, página dez , esta é uma solicitação que aceita uma resposta unicast. Se o primeiro bit tivesse sido um 1 , ele teria sinalizado que o cliente DHCP precisava de uma resposta broadcast .