Er ist wieder zurück mit Patch 1.100.ptc

[salixer]

Du gehst also davon aus, dass der DHCP Server den NTP Server zuweist (ist ja gut möglich), ohne Anfrage durch den Client (DHCPDISCOVER, DHCPREQUEST oder DHCPINFORM). Da bin ich aber gespannt. Werde heute mal sniffen ...

Ja, über DHCP kann man auch NTP-Server mitteilen. Siehe: ConfiguringNTP < Support < NTP.

[saft6luck]

Ja, über DHCP kann man auch NTP-Server mitteilen. Siehe: ConfiguringNTP < Support < NTP.

Ja, aber auf Anfrage. Also fragt der eibPC doch nach?

[salixer]

Ja, aber auf Anfrage. Also fragt der eibPC doch nach?

Nein, eigentlich nicht. Und damit wären wir beim Problem.

[saft6luck]

Nein, eigentlich nicht. Und damit wären wir beim Problem.

Zusammenfassend:

- eibPC fragt nicht beim DHCP Server an?!
- FB sendet NTP-Server in Antworten auf Anfragen?
- eibPC hört auf Antworten von Anfragen anderer Rechner????
-> eibPC hat ein Problem?!
-> FB ist der Böse?

Ich hatte gestern den eibPC zurückgesetzt und dann am Mirror-Port gelauscht, was da kommt, aber scheinbar reicht der Factory-Reset nicht, da ich keinerlei DHCP Anfragen des eibPCs gesehen habe (und auch keine Antworten der FB).
Wie kann man prüfen, dass der Reset funktioniert hat?

[salixer]

- eibPC fragt nicht beim DHCP Server an?!

Doch, mindestens einmal beim ersten Boot.

- FB sendet NTP-Server in Antworten auf Anfragen?

Anscheinend schon.

- eibPC hört auf Antworten von Anfragen anderer Rechner????

Was meinst du damit?

-> eibPC hat ein Problem?!

Offensichtlich hat der ISC-DHCP Client ein Problem mit der Antwort der FB.

-> FB ist der Böse?

Hat niemand gesagt. Lediglich anfangs bin ich davon ausgegangen, dass sie Anfragen auf Port 123 umleitet oder den DNS manipuliert. Das wäre schlecht gewesen, ist hier aber nicht der Fall. Ein Problem besteht aber offensichtlich wirklich: Sie kündigt sich selbst als NTP-Server an, gibt aber ab und zu keine Antwort auf NTP-Anfragen. Der NTP-Daemon im EibPC kommt dann nicht über ein "INIT" bei NTP hinaus.

Ich hatte gestern den eibPC zurückgesetzt und dann am Mirror-Port gelauscht, was da kommt, aber scheinbar reicht der Factory-Reset nicht, da ich keinerlei DHCP Anfragen des eibPCs gesehen habe (und auch keine Antworten der FB).
Wie kann man prüfen, dass der Reset funktioniert hat?

Kannst du doch im Eibstudio nachsehen, ob er auf DHCP läuft. Das NTP-Problem wird ein Reset nicht beheben.

[salixer]

So, habe gerade mal die DHCP-Kommunikation beobachtet. Der DHCP-Server ist so konfiguriert, dass er auch NTP-Server ankündigen kann.

1. Falls man den DHCP-Request für NTP-Server im EibPC aktiviert erscheint bei der Anfrage im "Bootstrap protocol" bei "Option: (t=55,l=4) Parameter Request List" unter anderem auch "42 = Network Time Protocol Servers".
Der DHCP-Server antwortet dann mit "Option: (t=42,l=4) Network Time Protocol Servers = 192.53.103.108"

2. Falls der NTP-Server-Request nicht aktiviert ist (Standardeinstellung), dann ist in der Antwort des DHCP-Servers auch kein NTP-Server zu finden.

Mein Schuss ins Blaue: Ich nehme an, dass die Fritzbox in der DHCP-Antwort immer den NTP-Server überträgt, auch wenn keiner angefordert wurde. Daraufhin wird er vom DHCP-Client übernommen.
Falls die Annahme richtig ist, kann ich aber nicht sagen, ob DHCP-Client oder Server sich nach der Spezifikation falsch verhalten. Die habe ich nämlich noch nicht gelesen.

[makki]

Dhcp

Ausm Kopf: Der Client sagt beim REQ welche Options er gerne hätte und der DHCP-Server hat beim OFFER auch nur diese (oder weniger) Options zu liefern;
im Falle von NTP macht das natürlich nur dann Sinn wenn der DHCP-Server auch einen funktionierenden NTP-Server kennt

Makki

[saft6luck]

Ausm Kopf: Der Client sagt beim REQ welche Options er gerne hätte und der DHCP-Server hat beim OFFER auch nur diese (oder weniger) Options zu liefern;
im Falle von NTP macht das natürlich nur dann Sinn wenn der DHCP-Server auch einen funktionierenden NTP-Server kennt

Ausm Kopf würde ich sagen, dass der Client alles anfragen kann und man im Server alles ausgeben kann, was man dem Client gerne mitgeben will, der Client nimmt sich dann das benötigte. Da gibt es keine Beschränkung (oder kennt jemand entsprechende Beschränkungen in den RFCs?). Die Fritzbox kennt ja einen NTP Server, der normalerweise auch tut, außer man konfiguriert ihn um. Der DHCP-Server wird nie den Status des NTP Servers prüfen, sondern die konfigurierten Einträge füllen.

Also entweder man konfiguriert den Client richtig und/oder den DHCP-Server. Was ich der FB ankreiden würde ist die fehlende Konfigurationsmöglichkeit für den Laien, aber das trifft noch schlimmer für den eibPC zu.

Beim eibPC kommt noch ein Umrechnungsfehler bei fehlender Uhrzeit hinzu, der die UNIX-Zeit dann auf irgendwas um Jahr 2034 umrechnet.

Übrigens: Wenn ich früher gewusst hätte, dass der eibPC bei aktivem DHCP den NTP-Server aus der DHCP-Antwort verwendet, hätte ich gleich meinen Server weiter verwenden können, ohne umständlich den DNS-Server umbiegen zu müssen. Man könnte es also auch als Feature bezeichnen

[makki]

Na dann Fragen wir statt dem Kopf doch mal die RFC2131, die IETF ist ja zum Glück kein Geheimbund, wo man die Standards erst nach der Zahlung von Schutzgeldern zu lesen bekommt

... Parameters requested by the client, according to the following
rules:

-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE

-- IF the server recognizes the parameter as a parameter
defined in the Host Requirements Document, the server MUST
include the default value for that parameter as given in the
Host Requirements Document in an appropriate option in the
'option' field, ELSE

-- The server MUST NOT return a value for that parameter,

The server MUST supply as many of the requested parameters as
possible and MUST omit any parameters it cannot provide.

Vulgo: hat der Server keine Ahnung (weil es z.B. nicht explizit konfiguriert/geprüft wurde), hat er bzgl. NTP-Server die mal die Klappe zu halten und nicht einen Ratewert rauszuschicken
Schon gleich gar keinen einzigen NTP-Server (statt mehrerer), der nicht funktioniert.
Am Client ist prinzipiell dagegen nichts zwangsweise zu konfigurieren, das ist elementarer Sinn und Zweck von DHCP..
Und das der Client nach NTP frägt und diesen auch dann verwendet ist gut, richtig und sinnvoll. Es könnte ja auch sein, dass der DHCP Server den intern erreichbaren, richtigen kennt!
Allerdings ist es natürlich nicht so passend sich die einmalige DHCP-AW ewig zu merken, sobald DHCP deaktiviert wird muss es auf die Default/Konfig-Werte zurück(die Diskussion müssten wir jetzt aber mit den Debian-Maintainern führen, weil das verhalten von DNS bis NTP so ist)..
(Edit: sofern ich das richtig verstanden habe, geprüft habe ich das nicht)

Wiegesagt, ich hatte mich über die Fritzi da in anderem Kontext schonmal massiv geärgert, weil da einige Dinge etwas eigenwillig interpretiert werden..

Makki

[saft6luck]

Na dann Fragen wir statt dem Kopf doch mal die RFC2131, die IETF ist ja zum Glück kein Geheimbund, wo man die Standards erst nach der Zahlung von Schutzgeldern zu lesen bekommt

Eben, geht doch. Wenn man die RFC2131 weiter ließt, kommt noch der Hinweis auf die 'vom Administrator vorgegebenen Optionen'.

Vulgo: hat der Server keine Ahnung (weil es z.B. nicht explizit konfiguriert/geprüft wurde), hat er bzgl. NTP-Server die mal die Klappe zu halten und nicht einen Ratewert rauszuschicken

Der NTP-Server in der Fritzbox ist kein "Ratewert" und ob er ein konfigurierter Wert ist, entzieht sich meiner Kenntnis. Da aber auch in der Fritzbox ein 0815 Unix DHCP-Server läuft, ist es anzunehmen, oder? Schlecht konfiguriert würde ich gelten lassen.

Schon gleich gar keinen einzigen NTP-Server (statt mehrerer), der nicht funktioniert.

Es wird mindestens einer gefordert.

Am Client ist prinzipiell dagegen nichts zwangsweise zu konfigurieren, das ist elementarer Sinn und Zweck von DHCP..

Zwangsweise nicht, aber richtig, z.B. ohne aktives DHCP die Daten des DHCP-Servers nicht verwenden, aber das schreibst du ja unten.

Und das der Client nach NTP frägt und diesen auch dann verwendet ist gut, richtig und sinnvoll. Es könnte ja auch sein, dass der DHCP Server den intern erreichbaren, richtigen kennt!

Allerdings ist es natürlich nicht so passend sich die einmalige DHCP-AW ewig zu merken, sobald DHCP deaktiviert wird muss es auf die Default/Konfig-Werte zurück(die Diskussion müssten wir jetzt aber mit den Debian-Maintainern führen, weil das verhalten von DNS bis NTP so ist)..
(Edit: sofern ich das richtig verstanden habe, geprüft habe ich das nicht)

Zustimmung!

Wiegesagt, ich hatte mich über die Fritzi da in anderem Kontext schonmal massiv geärgert, weil da einige Dinge etwas eigenwillig interpretiert werden..

Das glaube ich gerne, nur hatte ich bisher mit noch jedem 'ausgewachsenem' Router Probleme, da sind die angeblichen Probleme mit der FB Kleinigkeiten, die man über den Support auch meist geregelt bekommt.

[salixer]

Der NTP-Server in der Fritzbox ist kein "Ratewert" und ob er ein konfigurierter Wert ist, entzieht sich meiner Kenntnis. Da aber auch in der Fritzbox ein 0815 Unix DHCP-Server läuft, ist es anzunehmen, oder? Schlecht konfiguriert würde ich gelten lassen.

Die Fritzbox announced sich selbst als NTP-Server. Ich nehme an, dass man an dieser Einstellung auch nichts ändern kann.

Es wird mindestens einer gefordert.

Natürlich geht es mit einem, aber sinnvollerweise sollte man mind. drei konfiguriert haben. Bleibt noch die Frage, warum der NTP-Server in der Fritzbox oft die Anfragen des EibPC nicht beantwortet.


Es bleiben zwei mögliche Fixes:
1. Die NTP-Konfiguration per DHCP komplett unterbinden.
2. Beim Booten vor dem Netzwerkstart immer die alte ntp.conf.dhcp löschen.

Nutzer, die den EibPC mit DHCP an der Fritzbox betreiben wollen, haben mit Nr. 1 wohl unweigerlich Probleme. Bei Nr. 2 hätten die Freaks die Möglichkeit selbst die NTP-Server zu konfigurieren.
Persönlich könnte ich mich mit Nr. 2 anfreunden, da ich ja nicht unbedingt Workarounds für suboptimal konfigurierte Fritzboxen bauen muss.