Неправильное поведение DHCP

Question

ISC DHCP-сервер работает на Fedora 10. Так как он больше ничего не делает, никто не потрудился обновить его ... Я заметил поведение, которое выглядит очень странным для меня: DHCP-сервер получает DISCOVER в качестве широковещательной рассылки, отправляет OFFER в качестве одноадресной передачи на ретранслятор DHCP - и сразу после этого отправляет то же самое предложение, что и bcast.

Сам клиент плохо себя ведет, он постоянно отправляет пакеты DHCP DISCOVER, но я не думаю, что это может привести к тому, что сервер отправит предложение. Кто-нибудь знает, почему это может произойти - возможно, это особенность этого сервера каменного века?

Answer 1

Я не уверен, что это действительно плохо себя ведет. DHCP является дисциплинированным RFC2131, который прямо заявляет (вы можете проверить сами, начало страницы 24), что DHCPOFFER, DHCPACK, DHCPNAK отправляются клиенту посредством одноадресной доставки, за исключением того, что некоторые реализации клиента не позволяют принимать такие одноадресные рассылки до правильный IP-адрес был настроен.

Такие реализации устанавливают бит BROADCAST в поле 'flags' равным 1 в любых сообщениях DHCPDISCOVER или DHCPREQUEST, что, в свою очередь, предписывает серверу и агенту ретрансляции bootp использовать широковещательную доставку вместо (более обычной) одноадресной.

РЕДАКТИРОВАТЬ:

Да, во что бы то ни стало: кажется, что ваш почти никогда не используемый сервер имеет одну такую реализацию DHCP только для широковещательной передачи. Однако, если вы видите его первоначальное сообщение DHCPDISCOVER с tcpdump/wireshark, то вы можете проверить, установлен ли широковещательный бит или нет, не нужно догадываться.

На самом деле вы можете значительно упростить свою жизнь, используя dhcpdump вместо работы с фильтрами tcpdump или wireshark, поскольку он будет захватывать только пакеты dhcp и представлять их вам в доступной форме. Например, в моей домашней сети я записал этот запрос:

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

Интересующая нас линия:

 FLAGS: 7f80

Это, конечно, число в шестнадцатеричном формате, первый бит которого равен 0: таким образом, согласно RFC2131, страница десять, это запрос, который принимает одноадресный ответ. Если бы самый первый бит был 1, то это означало бы, что клиенту DHCP требуется широковещательный ответ.