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
źródło
RENEW DHCPREQUEST
? Zgodnie z tym identyfikator serwera NIE MOŻE być wypełniony podczasRENEW
-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 :)This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents.
. Mmm, więc potrzebujemy innej metody, aby sprawdzić, czy to jest,RENEW
czy nie. (Muszę poczytać o tym :) Ale kiedy to czytam, są pewne przypadki, w których'server identifier' MUST NOT be filled in
.DHCPREQUEST
s 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.Odpowiedzi:
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):
(dwa razy, dlaczego? Może jest uparty;) (klient może wysyłać wiele żądań)
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
ODNOWIENIEtego samego adresu IP podczas INIT-REBOOT .Ale ... Myślę, że odpowiedź na pytanie brzmi ...
TAK , to jest prawidłowe zachowanie klienta
i NIE , standardy się nie zmieniły;)
źródło
The client begins in INIT-REBOOT
...The client MUST insert its known network address as a 'requested IP address'
IThe client MUST NOT include a 'server identifier' in the DHCPREQUEST message
.