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

Це питання про стандарти Інтернет-протоколу.

DHCP-клієнт (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-клієнта? Чи змінилися стандарти?

networking dhcp standards

— someuser
джерело

Ви впевнені, що не контролюєте a RENEW DHCPREQUEST? Згідно з це ідентифікатор сервера НЕ ПОВИНЕН бути заповнені протягом a RENEW -запит. І бачачи як призначення вашої DHCPREQUEST є одноадресний (0.0.0.0 до 255.255.255.255) може бути RENEW DHCPREQUEST. (PS. Не експерт тут :)

— Rik

@Rik 255.255.255.255 - це широкомовна адреса.

— someuser

Мммм, так ... і This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents.. Ммм, отже, нам потрібен інший метод, щоб побачити, чи є це RENEW чи ні. (Мені потрібно зробити деякі читання на цьому :) Але, як я прочитав це є деякі випадки, де 'server identifier' MUST NOT be filled in.

— Rik

(знову ... не експерт), але я прямо бачу останні 2 DHCPREQUEST Чи встановлено "Ідентифікатор сервера DHCP" (рядок 73 і 77)? Також читання через RFC 2131 тільки під час вибору SELECTING, "DHCP Server Identifier" (Ідентифікатор DHCP-сервера) має бути заповнений.

— Rik

Клієнт розпочав повну процедуру ініціалізації після першого DHCPREQUEST, оскільки сервер надіслав DHCPNAK. Це не INIT-REBOOT, RENEWAL, і т.д., я думаю. Також там (при журналі) є кілька dhcp-клієнтів.

— someuser

Я збираюся відповісти ... (більше місця;)

Спочатку питання. Ви відчуваєте затримку в отриманні правильного IP-адреси з сервера? Як я це бачу, знадобилося більше хвилини з половиною, щоб отримати правильний IP (192.168.1.33). Якщо це так, то, можливо, нам слід придивитися до запитів.

Я думаю, що протокол є правильним, як зараз.

Я фільтрував тільки трафік з / на LenovoMo в / з MS-NLB-PhysServer. (Принаймні я думаю, що я зробив;)
я використовував фільтр
((((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)

Ось що я отримав (клацніть правою кнопкою миші та виберіть "відкрити в новій вкладці" для більшої версії):

enter image description here

Дивлячись на перший запит DHCP (рядок # 1), ваші клієнтські запити 192.168.1.35 .

enter image description here

Він отримує NAK DHCP (немає правильного IP) назад з сервера.
Клієнт переходить у режим виявлення DHCP і надсилає декілька пакетів для виявлення (як і слід).
Сервер відправляє пропозицію DHCP (також кілька разів), і я думаю, що він пропонує 192.168.1.33.

enter image description here

У 9-му рядку клієнти знову намагається отримати 192.168.1.35 з запитом DHCP
(двічі, чому? можливо, він наполегливий;) (клієнту дозволено надсилати декілька запитів)
Знову сервер відповідає DHCP NAK.
...
Це триває хвилин.
...
Нарешті, у рядку # 63 клієнт виконує запит DHCP з IP 192.168.1.33
з "Варіант: (54) DHCP Server Identifier" (як і слід). (Дивись нижче)

Я не впевнений (поки що), чому це займає так довго, але всі DHCP-запити, які робить клієнт (до рядка 63) запит 192.168.1.35 і таким чином є проханнями ~~ПОВЕРНЕННЯ~~ той самий IP під час INIT-REBOOT .

Питання: правильна поведінка DHCP-клієнта? Чи змінилися стандарти?

Але ... Я думаю, що відповідь на питання ...
ТАК Це правильна поведінка клієнта
і НІ , стандарти не змінилися;)

enter image description here

— Rik
джерело

Це не РЕНВЕР, я думаю. 1 - RENEW є одноадресним. 2 - RENEW НЕ ПОВИНЕН містити запитуваний IP-адресу. Перше повідомлення - INIT-REBOOT DHCPREQUEST, я думаю, і цей пакет правильний тоді. Але про інше я не знаю. Все одно, дякую.

— someuser

@someuser Haaa, Так ... журнал починається з протоколу 4.4.2 Ініціалізація з відомою мережевою адресою . Це говорить: The client begins in INIT-REBOOT ... The client MUST insert its known network address as a 'requested IP address' І The client MUST NOT include a 'server identifier' in the DHCPREQUEST message.

— Rik

Є 3 "ID транзакції", які починаються з DHCPREQUEST. Тоді остаточний (рядок # 63) повинен бути ВИБІР (де обраний IP та "id сервера" є ПОВИННІ). Клієнту дозволяється надсилати кілька запитів протягом однієї хвилини, щоб переконатися, що сервер отримує їх. Тому ті, що знаходяться між ними, швидше за все, повторно посилають.

— Rik

Я знайшов добре статті . :)

— someuser

@someuser Так, це набагато легше читати, ніж сухий матеріал RFC 2131 ;) Я все ще здивований, чому Android намагається DHCPREQUEST 2 додаткових рази (рядок # 9 і # 35 з "секунд минув: 1") зі старим IP (протягом цілої хвилини), перш ніж прийняти пропозицію сервер. Можна подумати, що після отримання першого NAK знатиметься прийняти наступну пропозицію. (зекономить багато часу) Ааа, ну ... це завжди краще, ніж описана ситуація тут .

— Rik