Verhalten des DHCP-Clients

2400
someuser

Dies ist eine Frage zu den Internetprotokollstandards.

  • Der DCHP-Client (dhcpcd-5.2.10 von Android 4.x) initialisiert eine Schnittstelle
  • Der DHCP-Client sendet eine DHCPDISCOVER-Nachricht
  • Der DHCP-Server sendet eine DHCPOFFER-Nachricht
  • Dann sendet der Client eine DHCPREQUEST-Nachricht, die eine andere als "Ihre IP-Adresse" von DHCPOFFER als "Angeforderte IP-Adresse" enthält und keine "DHCP-Server-Kennung" enthält.

Ich sehe es von Paketerfassung auf DHCP-Server - Einrichtung (kann mit Wireshark geöffnet).

RFC 2131 sagt:

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.

Frage: Ist das Verhalten des DHCP-Clients korrekt? Können sich die Standards geändert haben?

1
Sind Sie sicher, dass Sie kein `RENEW DHCPREQUEST` überwachen? Laut [this] (http://stackoverflow.com/questions/12565095/how-client-unicasts-a-renew-dhcp-request-if-server-id-must-not-be-filled-in) dem Server id ** MUSS NICHT während einer `RENEW'-Anfrage ausgefüllt werden. Und da das ** Ziel ** Ihres `DHCPREQUEST '** Unicast ** ist (0,0.0.0 bis 255.255.255.255), könnte es sich um ein` RENEW DHCPREQUEST` handeln. (PS. Kein Experte hier :) Rik vor 10 Jahren 0
@Rik 255.255.255.255 ist eine Broadcast-Adresse. someuser vor 10 Jahren 0
Mmmm, yeah ... und `Diese DHCPREQUEST-Nachricht wird gesendet und über DHCP / BOOTP-Relay-Agenten weitergeleitet." Mmmm, also brauchen wir eine andere Methode, um zu sehen, ob dies eine "RENEW" ist oder nicht. (Ich muss etwas darüber nachlesen :) Aber wenn ich es lese, gibt es einige Fälle, in denen "Server Identifier" NICHT ausgefüllt werden MUSS. Rik vor 10 Jahren 0
(wieder ... kein Experte) aber habe ich recht, wenn ich die letzten 2 `DHCPREQUESTs 'sehe, die" DHCP Server Identifer "(Zeile 73 und 77) eingestellt haben? Beim Lesen des [RFC 2131] (http://tools.ietf.org/html/rfc2131.html) nur im SELECTING-Status muss der "DHCP-Server-Identifikator" ausgefüllt werden Darf NICHT gesetzt werden. Rik vor 10 Jahren 0
Der Client hat nach dem ersten DHCPREQUEST einen vollständigen Initialisierungsvorgang gestartet, da der Server DHCPNAK gesendet hat. Ich denke, es ist nicht INIT-REBOOT, ERNEUERUNG usw. Auch dort (beim Log) gibt es mehrere Dhcp-Clients. someuser vor 10 Jahren 0

1 Antwort auf die Frage

1
Rik

Ich gehe zu einer Antwort ... (mehr Raum;)

Zuerst eine Frage. Haben Sie eine Verzögerung beim Abrufen einer korrekten IP-Adresse vom Server? Wie ich es sehe, dauerte es mehr als eineinhalb Minuten, um eine korrekte IP-Adresse zu erhalten (192.168.1.33). Wenn dies der Fall ist, sollten wir uns die Anfragen vielleicht genauer ansehen.

Ich denke, dass das Protokoll so ist, wie es jetzt ist.

Ich habe nur den Verkehr von / zu LenovoMo zu / von MS-NLB-PhysServer gefiltert. (Zumindest glaube ich, ich habe es getan;)
Ich habe Filter verwendet
((((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)

Das ist was ich habe (Rechtsklick und wählen Sie "In neuem Tab öffnen" für eine größere Version):

enter image description here

  • Wenn Sie sich die erste DHCP-Anfrage (Zeile 1) ansehen, fordert Ihr Client 192.168.1.35 an .

enter image description here

  • Es erhält ein DHCP-NAK (keine korrekte IP-Adresse) vom Server zurück.
  • Der Client wechselt in den DHCP-Erkennungsmodus und sendet mehrere Pakete zur Erkennung (je nach Bedarf).
  • Der Server sendet ein DHCP-Angebot (auch mehrfach), und ich denke, es bietet 192.168.1.33.

enter image description here

  • In Zeile 9 versucht der Client erneut, 192.168.1.35 mit einer DHCP-Anfrage zu erhalten
    (zweimal, warum? Vielleicht ist es hartnäckig;) (Der Client darf mehrere Anfragen senden)
  • Der Server antwortet erneut mit DHCP NAK.
  • ...
  • Das geht für eine Minute weiter.
  • ...
  • In Zeile 63 führt der Client schließlich eine DHCP-Anfrage mit IP 192.168.1.33
    mit der Option "Option: (54) DHCP Server Identifier" aus (wie es sollte). (siehe unten)

Ich bin mir (noch) nicht sicher, warum es so lange dauert, aber alle DHCP-Anfragen, die der Client (bis Zeile # 63) vornimmt, fordern 192.168.1.35 und sind somit Anfragen für RENEWAL die gleiche IP während INIT-REBOOT .

Frage: Ist das Verhalten des DHCP-Clients korrekt? Können sich die Standards geändert haben?

Aber ... Ich denke, die Antwort auf die Frage ist ...
JA, das ist korrektes Verhalten des Kunden
und NEIN, die Standards haben sich nicht geändert;)


enter image description here

Es ist keine ERNEUERUNG, denke ich. 1 - RENEW ist Unicast. 2 - RENEW darf NICHT die angeforderte IP-Adresse enthalten. Die erste Nachricht ist INIT-REBOOT DHCPREQUEST, denke ich, und dieses Paket ist dann korrekt. Aber ich weiß nichts über andere. Danke trotzdem. someuser vor 10 Jahren 0
@someuser Haaa, ja ... das Protokoll beginnt mit dem Protokoll [4.4.2 Initialisierung mit bekannter Netzwerkadresse] (http://tools.ietf.org/html/rfc2131.html#section-4.4.2). Das besagt: "Der Client beginnt in INIT-REBOOT" ... "Der Client MUSS seine bekannte Netzwerkadresse als" angeforderte IP-Adresse "angeben." UND ** "Der Client DARF KEINE" Server-ID "in der DHCPREQUEST-Nachricht enthalten "**. Rik vor 10 Jahren 0
Es gibt 3 "Transaktions-IDs", die mit DHCPREQUEST beginnen. Dann muss das letzte (Zeile # 63) das SELECTING sein (wobei gewählte IP und "Server-ID" ein MUSS sind). Es ist zulässig, dass der Client innerhalb einer Minute mehrere Anforderungen sendet, um sicherzustellen, dass der Server diese erhält. Diejenigen, die dazwischen sind, werden wahrscheinlich erneut gesendet. Rik vor 10 Jahren 0
Ich habe einen guten [Artikel] gefunden (http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm). :) someuser vor 10 Jahren 0
@someuser Ja, das ist viel einfacher zu lesen als das trockene Material unter [RFC 2131] (http://tools.ietf.org/html/rfc2131.html);) Ich bin immer noch verwirrt, warum Android das DHCPREQUEST versucht 2 zusätzliche Zeiten (Zeile # 9 und # 35 mit "Sekunden verstrichen: 1") mit der alten IP (für eine ganze Minute), bevor Sie das ANGEBOT des Servers annehmen. Sie würden denken, nach Erhalt des ersten NAK würde es wissen, das nächste ANGEBOT anzunehmen. (würde viel Zeit sparen) Aah, na ja ... es ist immer besser als die hier beschriebene Situation (https://code.google.com/p/android/issues/detail?id=33590). Rik vor 10 Jahren 0
Es gibt einen anderen seltsamen Moment. Ich habe vor einigen Stunden eine Verzögerung zwischen Paketen gesehen. Der Client sendet eine DISCOVER, der Server antwortet. Der Client sendet DISCOVER nach _4-10_ (anders) Sekunden erneut. Ich habe den Verdacht, dass es ein Netzwerkproblem gibt. someuser vor 10 Jahren 0
@someuser Wenn dies nur beim Android-Gerät der Fall ist, kann es betriebssystemspezifisch sein. Bei meinen Suchen habe ich ziemlich viele Fehler in der DHCP-Implementierung in Android gefunden. Wie [hier] (https://code.google.com/p/android/issues/detail?id=12066) (direkt in der SELECTING-Phase mit falscher IP-Adresse gestartet) und ein paar andere. Vielleicht möchten Sie die Protokolle in Wireshark nur mit Verkehr von einem anderen Client (und einem anderen Server) filtern und sehen, ob es auch nicht normal ist. (Oder [hier] (http://cafbit.com/entry/rapid_dhcp_or_how_do) ein weiteres Beispiel für Android-Verkehr mit doppelter Anforderung, jedoch innerhalb von 11 Sekunden. Rik vor 10 Jahren 0
Nur wenige Android-Geräte. :) Diese Geräte werden jedoch normalerweise per DHCP im Heimnetzwerk angesprochen (wie ihre Besitzer sagen). Es ist komisch. someuser vor 10 Jahren 0
@someuser Sie haben also Probleme mit den Android-Geräten? Welches WiFi-Protokoll verwenden Sie? Wenn es sich um 802.11n handelt, möchten Sie möglicherweise zu 802.11g zurückwechseln. Zum Beispiel, wenn Sie nur eine Verbindungsgeschwindigkeit von 65 Mbps erhalten. Einige Router haben eine alte Implementierung von 802.11n, und in diesem Fall habe ich erfahren, dass sie auf 802.11g eingestellt ist / nur stabilisieren würde. Rik vor 10 Jahren 0
Ich kenne die WLAN-Version nicht (muss angeben), aber ich werde versuchen, diesen Lösungsweg anzubieten. Vielen Dank. someuser vor 10 Jahren 0

Verwandte Probleme