Поведение DHCP-клиента

2255
someuser

Это вопрос о стандартах интернет-протокола.

  • DCHP-клиент (dhcpcd-5.2.10 из Android 4.x) инициализирует интерфейс
  • DHCP-клиент отправляет сообщение DHCPDISCOVER
  • DHCP-сервер отправляет сообщение DHCPOFFER
  • Затем клиент отправляет сообщение DHCPREQUEST, которое содержит «Запрошенный IP-адрес», отличный от «Ваш IP-адрес», из DHCPOFFER и не содержит «Идентификатор сервера DHCP».

Я вижу это из захвата пакета (может быть открыт с Wireshark) на устройстве dhcp-сервера.

RFC 2131 говорит:

The client broadcasts a DHCPREQUEST message that MUST include  the 'server identifier' option to indicate which server  it has selected, and that MAY include other options specifying  desired configuration values.  The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server.

Вопрос: корректно ли поведение DHCP-клиента? Могут ли стандарты измениться?

1
Вы уверены, что не отслеживаете `RENEW DHCPREQUEST`? Согласно [этому] (http://stackoverflow.com/questions/12565095/how-client-unicasts-a-renew-dhcp-request-if-server-id-must-not-be-filled-in) серверу Идентификатор ** НЕ ДОЛЖЕН ** заполняться во время запроса RENEW. И учитывая, что ** назначение ** вашего `DHCPREQUEST` является ** одноадресным ** (от 0.0.0.0 до 255.255.255.255), это может быть` RENEW DHCPREQUEST`. (PS. Не эксперт здесь :) Rik 10 лет назад 0
@Rik 255.255.255.255 - широковещательный адрес. someuser 10 лет назад 0
Мммм, да ... и `Это сообщение DHCPREQUEST транслируется и ретранслируется через агентов ретрансляции DHCP / BOOTP. Ммм, так что нам нужен другой метод, чтобы увидеть, является ли это `RENEW` или нет. (Мне нужно немного почитать об этом :) Но когда я читаю, есть некоторые случаи, когда «идентификатор сервера» НЕ ДОЛЖЕН быть заполнен ». Rik 10 лет назад 0
(опять же ... не эксперт) но прав ли я, увидев, что последние 2 `DHCPREQUEST имеют установленный" Идентификатор сервера DHCP "(строки 73 и 77)? Также считывая [RFC 2131] (http://tools.ietf.org/html/rfc2131.html) только в состоянии ВЫБОР, необходимо заполнить «Идентификатор сервера DHCP». Во время INIT-REBOOT, RENEWAL и REBINDING НЕ ДОЛЖЕН быть установлен. Rik 10 лет назад 0
Клиент запустил полную процедуру инициализации после первого DHCPREQUEST, потому что сервер отправил DHCPNAK. Это не INIT-REBOOT, RENEWAL и т. Д., Я думаю. Также там (в журнале) есть несколько dhcp-клиентов. someuser 10 лет назад 0

1 ответ на вопрос

1
Rik

I'm going to an answer... (more room ;)

First a question. Are you experiencing a delay in getting a correct IP from the server? As i see it, it took more than a minute and a half to get a correct IP (192.168.1.33). If that's the case maybe we should look closer to the requests.

I think the protocol is correct the way it is now.

I filtered only traffic from/to LenovoMo to/from MS-NLB-PhysServer. (At least i think i did ;)
i used filter
((((eth) && !(bootp.hw.mac_addr == 00:bb:3a:89:67:be)) && !(bootp.hw.mac_addr == b4:98:42:d6:63:c1)) && !(bootp.hw.mac_addr == e0:69:95:74:b2:43)) && !(bootp.hw.mac_addr == 78:e4:00:9d:fd:6b)

This is what i got (right click and choose "open in new tab" for a bigger version):

enter image description here

  • Looking at the first DHCP Request (line #1) your client requests 192.168.1.35.

enter image description here

  • It gets a DHCP NAK (no correct IP) back from the server.
  • The client goes in DHCP Discover mode and sends several packets for discovery (as it should).
  • The server sends a DHCP Offer (also multiple times) and i think it's offering 192.168.1.33.

enter image description here

  • At line 9 the clients tries again to get 192.168.1.35 with a DHCP Request
    (twice, why? maybe it's stubborn ;) (it is allowed for the client to send multiple requests)
  • Again server responds with DHCP NAK.
  • ...
  • This goes on for minute.
  • ...
  • Finally at line #63 the client does a DHCP Request with IP 192.168.1.33
    with the "Option: (54) DHCP Server Identifier" (as it should). (see below)

I'm not sure (yet) why it takes so long but all the DHCP Requests the client makes (until line #63) are requesting 192.168.1.35 and thus are requests for RENEWAL the same IP during INIT-REBOOT.

Question: is correct behavior of the DHCP-client? May standards have changed?

But... I think the answer to the question is...
YES, this is correct behavior of the client
and NO, the standards haven't changed ;)


enter image description here

Это не ОБНОВЛЕНИЕ, я думаю. 1 - RENEW является одноадресным. 2 - ОБНОВЛЕНИЕ НЕ ДОЛЖНО содержать Запрошенный IP-адрес. Первое сообщение INIT-REBOOT DHCPREQUEST, я думаю, и тогда этот пакет верен. Но я не знаю о другом. Спасибо, в любом случае. someuser 10 лет назад 0
@someuser Хааа, да ... журнал начинается с протокола [4.4.2 Инициализация с известным сетевым адресом] (http://tools.ietf.org/html/rfc2131.html#section-4.4.2). Это гласит: `Клиент начинается с INIT-REBOOT` ...` Клиент ДОЛЖЕН вставить свой известный сетевой адрес в качестве «запрошенного IP-адреса». И ** `Клиент НЕ ДОЛЖЕН включать« идентификатор сервера »в сообщение DHCPREQUEST. `**. Rik 10 лет назад 0
Существует 3 «идентификатора транзакции», которые начинаются с DHCPREQUEST. Тогда финал (строка # 63) должен быть SELECTING (где ДОЛЖНЫ быть выбраны IP и «идентификатор сервера»). Клиенту разрешено отправлять несколько запросов в течение одной минуты, чтобы убедиться, что сервер их получает. Так что те, кто находится между ними, скорее всего повторно отправят. Rik 10 лет назад 0
Я нашел хорошую [статью] (http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm). :) someuser 10 лет назад 0
@ someuser Да, это намного легче читать, чем сухой материал в [RFC 2131] (http://tools.ietf.org/html/rfc2131.html);) Я все еще озадачен тем, почему Android пытается использовать DHCPREQUEST. 2 дополнительных раза (строки № 9 и № 35 с «прошедшими секундами: 1») со старым IP-адресом (на целую минуту), прежде чем принять ПРЕДЛОЖЕНИЕ сервера. Вы можете подумать, получив первый NAK, который будет знать, чтобы принять следующее ПРЕДЛОЖЕНИЕ. (сэкономит много времени) Ааа, ну ... это всегда лучше, чем описанная ситуация [здесь] (https://code.google.com/p/android/issues/detail?id=33590). Rik 10 лет назад 0
Есть еще один странный момент. Я видел задержку между пакетами несколько часов назад. Клиент отправляет DISCOVER, сервер отвечает. Клиент снова отправляет DISCOVER через _4-10_ (иначе) секунд. У меня есть подозрение о существовании какой-то проблемы с сетью. someuser 10 лет назад 0
@someuser Если это только для устройства Android, это может зависеть от ОС. Во время моих поисков я обнаружил довольно много ошибок в реализации DHCP в Android. Как [здесь] (https://code.google.com/p/android/issues/detail?id=12066) (непосредственно начиная с фазы ВЫБОР с неправильным IP-адресом) и некоторых других. Таким образом, вы можете отфильтровать журналы в Wireshark только с трафиком от другого клиента (и сервера) и посмотреть, является ли он также ненормальным. (Или [здесь] (http://cafbit.com/entry/rapid_dhcp_or_how_do) еще один пример трафика Android с двойным запросом, но в течение 11 секунд) Rik 10 лет назад 0
Только несколько устройств Android. :) Но эти устройства обычно получают адреса по DHCP в домашней сети (как говорят их владельцы). Это странно. someuser 10 лет назад 0
@ someuser Итак, у вас есть проблемы с устройствами Android? Какой протокол WiFi вы используете. Если это 802.11n, вы можете вернуться к 802.11g. Например, если вы получаете скорость соединения только 65 Мбит / с. Некоторые маршрутизаторы имеют старую реализацию 802.11n, и в этом случае я испытал настройку на 802.11g / only, что могло бы стабилизировать многие вещи. Rik 10 лет назад 0
Я не знаю о версии WiFi (нужно указать), но я постараюсь предложить этот способ для решения. Благодарю. someuser 10 лет назад 0

Похожие вопросы