Zachowanie klienta DHCP

To jest pytanie o standardy protokołu internetowego.

Klient DCHP (dhcpcd-5.2.10 z Androida 4.x) inicjuje interfejs
Klient DHCP wysyła komunikat DHCPDISCOVER
Serwer DHCP wysyła komunikat DHCPOFFER
Następnie klient wysyła komunikat DHCPREQUEST, który zawiera „Żądany adres IP” inny niż „Twój adres IP” od DHCPOFFER i nie zawiera „Identyfikatora serwera DHCP”.

Widzę to z przechwytywania pakietów (można je otworzyć za pomocą Wireshark) na urządzeniu serwera dhcp.

RFC 2131 mówi:

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.

Pytanie: czy prawidłowe zachowanie klienta DHCP? Czy standardy się zmieniły?

networking dhcp standards

— someuser
źródło

Czy na pewno nie monitorujesz RENEW DHCPREQUEST? Zgodnie z tym identyfikator serwera NIE MOŻE być wypełniony podczas RENEW-request. A ponieważ Twoim celemDHCPREQUEST jest emisja pojedyncza (od 0.0.0.0 do 255.255.255.255), może to być RENEW DHCPREQUEST. (PS. Tutaj nie jestem ekspertem :)

— Rik

@Rik 255.255.255.255 to adres rozgłoszeniowy.

— someuser

Mmmm, tak ... i This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents.. Mmm, więc potrzebujemy innej metody, aby sprawdzić, czy to jest, RENEWczy nie. (Muszę poczytać o tym :) Ale kiedy to czytam, są pewne przypadki, w których 'server identifier' MUST NOT be filled in.

— Rik

(ponownie ... nie jestem ekspertem), ale czy mam rację, widząc, że ostatnie 2 DHCPREQUESTs mają ustawiony „Identyfikator serwera DHCP” (linie 73 i 77)? Odczytując również RFC 2131 tylko podczas stanu WYBIERANIA, należy wpisać „Identyfikator serwera DHCP”. Podczas INIT-REBOOT, ODNOWIENIA i PONOWNEGO REBINOWANIA NIE MUSI być ustawiony.

— Rik

Klient rozpoczął pełną procedurę inicjalizacji po pierwszym żądaniu DHCPREQUEST, ponieważ serwer wysłał DHCPNAK. Myślę, że to nie INIT-REBOOT, RENEWAL itp. Tam również (w logu) jest kilku klientów dhcp.

— someuser

Idę do odpowiedzi ... (więcej miejsca;)

Najpierw pytanie. Czy masz opóźnienie w uzyskaniu prawidłowego adresu IP z serwera? Moim zdaniem poprawne IP zajęło ponad półtorej minuty (192.168.1.33). W takim przypadku może powinniśmy przyjrzeć się bliżej zapytaniom.

Myślę, że protokół jest taki, jaki jest teraz.

Filtrowałem tylko ruch z / do LenovoMo do / z MS-NLB-PhysServer. (Przynajmniej tak mi się wydaje;)
Użyłem filtra
((((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)

Oto, co otrzymałem (kliknij prawym przyciskiem myszy i wybierz „otwórz w nowej karcie” dla większej wersji):

wprowadź opis zdjęcia tutaj

Patrząc na pierwsze żądanie DHCP (linia nr 1) klient żąda 192.168.1.35 .

wprowadź opis zdjęcia tutaj

Otrzymuje DHCP NAK (brak poprawnego adresu IP) z powrotem z serwera.
Klient przechodzi w tryb wykrywania DHCP i wysyła kilka pakietów do wykrycia (tak jak powinno).
Serwer wysyła ofertę DHCP (także wiele razy) i myślę, że oferuje 192.168.1.33.

wprowadź opis zdjęcia tutaj

W linii 9 klienci ponownie próbują uzyskać 192.168.1.35 za pomocą żądania DHCP
(dwa razy, dlaczego? Może jest uparty;) (klient może wysyłać wiele żądań)
Ponownie serwer odpowiada DHCP NAK.
...
Trwa to przez minutę.
...
Wreszcie w linii nr 63 klient wykonuje żądanie DHCP o adresie IP 192.168.1.33
z „Opcją: (54) identyfikator serwera DHCP” (tak jak powinien). (patrz poniżej)

Nie jestem (jeszcze) pewien, dlaczego to trwa tak długo, ale wszystkie żądania DHCP wysyłane przez klienta (do wiersza # 63) żądają 192.168.1.35, a zatem są prośby o ~~ODNOWIENIE~~ tego samego adresu IP podczas INIT-REBOOT .

Pytanie: czy prawidłowe zachowanie klienta DHCP? Czy standardy się zmieniły?

Ale ... Myślę, że odpowiedź na pytanie brzmi ...
TAK , to jest prawidłowe zachowanie klienta
i NIE , standardy się nie zmieniły;)

wprowadź opis zdjęcia tutaj

— Rik
źródło

Myślę, że to nie ODNOWAJ. 1 - ODNOWIENIE to emisja pojedyncza. 2 - ODNOWIENIE NIE MOŻE zawierać żądanego adresu IP. Pierwsza wiadomość to INIT-REBOOT DHCPREQUEST, tak myślę, i wtedy ten pakiet jest poprawny. Ale nie wiem o innych. W każdym razie dzięki.

— someuser

@someuser Haaa, Tak ... dziennik zaczyna się od protokołu 4.4.2 Inicjalizacja ze znanym adresem sieciowym . Który stanowi, że: The client begins in INIT-REBOOT... The client MUST insert its known network address as a 'requested IP address'I The client MUST NOT include a 'server identifier' in the DHCPREQUEST message.

— Rik

Istnieją 3 „Identyfikatory transakcji”, które zaczynają się od DHCPREQUEST. Następnie ostatnim (wiersz nr 63) musi być WYBÓR (w przypadku gdy wybrany adres IP i „identyfikator serwera” to MUSI). Klient może wysłać wiele żądań w ciągu jednej minuty, aby upewnić się, że serwer je otrzyma. Tak więc pośrednicy prawdopodobnie ponownie wysyłają wiadomości.

— Rik

Znalazłem dobry artykuł . :)

— someuser

@someuser Tak, to jest znacznie łatwiejsze do odczytania niż suchy materiał na RFC 2131 ;) Nadal zastanawiam się, dlaczego Android próbuje 2 razy DHCPREQUEST (linia nr 9 i nr 35 z „upływem sekund: 1”) z stary adres IP (przez całą minutę) przed zaakceptowaniem OFERTY serwera. Myślisz, że po otrzymaniu pierwszego NAK będzie wiedział, że przyjmie następną OFERTĘ. (zaoszczędziłoby dużo czasu) Ach, cóż ... zawsze jest lepiej niż opisana tutaj sytuacja .

— Rik