Er ist wieder zurück mit Patch 1.100.ptc

[saft6luck]

Hat er natürlich nicht. Es hat allerdings den Anschein, als ob die Fritzbox über ihren DNS alle Anfragen zu pool.ntp.org auf sich selbst umbiegt.

Also meine Fritzbox macht das nachweislich nicht! Nur wenn ich fritz.box als Server verwende, wird auch die Fritzbox-Zeit verwendet.

Und ich frage noch einmal: Woher kommt die falsche Zeit? Auch bei bodo ist die Fritzbox sicherlich nicht im Jahr 2034, oder?

[salixer]

Also meine Fritzbox macht das nachweislich nicht! Nur wenn ich fritz.box als Server verwende, wird auch die Fritzbox-Zeit verwendet.

Kannst du dazu bitte in paar ntpq Ausgaben posten? Es kann auch ein Fritzbox-Modell alles ganz anders machen als das Nächste. Man liest hier bei Problemen jedenfalls oft, dass eine Fritzbox im Einsatz ist. Das kann aber natürlich auch einfach an der hohen Verbreitung der Fritzbox liegen.
Und mir ist völlig unklar, wie der ntpd zu dem 10.0.1.100 Server kommt.

Und ich frage noch einmal: Woher kommt die falsche Zeit? Auch bei bodo ist die Fritzbox sicherlich nicht im Jahr 2034, oder?

Siehe hier:
ntpq -pn 10.0.1.4

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.0.1.100      .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Solange die refid auf .INIT. steht wurde noch keine Zeit synchronisiert. Ob die Fritzbox nicht auf Anfragen antwortet oder das Problem EibPC oder am Netzwerk liegt, kann man aus dieser Ausgabe nicht schließen.

[saft6luck]

Kannst du dazu bitte in paar ntpq Ausgaben posten?

Mache ich.

Es kann auch ein Fritzbox-Modell alles ganz anders machen als das Nächste. Man liest hier bei Problemen jedenfalls oft, dass eine Fritzbox im Einsatz ist. Das kann aber natürlich auch einfach an der hohen Verbreitung der Fritzbox liegen.

Ja, war die Fritzbox denn schon einmal das Problem?

[..] Ob die Fritzbox nicht auf Anfragen antwortet oder das Problem EibPC oder am Netzwerk liegt, kann man aus dieser Ausgabe nicht schließen.

Das ist der Grund warum ich frage: Gibt es eine Ursache, bei der der ntpd auf 2034 kommt, z.B. wenn noch keine Zeit 'empfangen' wurde? Du hattest ja mal geschrieben, dass in diesem Fall das Jahr bei ~2000 sei.

[salixer]

Mache ich.

Danke

Ja, war die Fritzbox denn schon einmal das Problem?

Ich konnte da bei Zeitproblemen noch nichts konkretes festmachen, deswegen will ich das jetzt rausfinden.

Das ist der Grund warum ich frage: Gibt es eine Ursache, bei der der ntpd auf 2034 kommt, z.B. wenn noch keine Zeit 'empfangen' wurde? Du hattest ja mal geschrieben, dass in diesem Fall das Jahr bei ~2000 sei.

Die Unix-Zeit steht zu dem Zeitpunkt auf 1970. Diese Jahreszahl ist aber inkompatibel mit dem KNX-Zeitstempel, deswegen kommt da nach der Konvertierung 2034 raus.

PS: Bodo, du hast nen Testpatch von mir per Mail erhalten, der zusätzliche NTP-Server in die ntpd.conf einträgt. Mal sehen, was dabei rauskommt.

[Bodo]

Hoi Thorsten

Ja danke, hab ich erhalten.
Jetzt ist erst mal seit 15min .INIT. und die Zeit falsch.

[salixer]

Ist die Fritzbox immernoch der einzige Server wenn du "ntp -p" machst?

EDIT: Vergiss die Frage

[Bodo]

Ist die Fritzbox immernoch der einzige Server wenn du "ntp -p" machst?

Hoi

Ich hab' den zweiten Patch übertragen und es ist immer noch nur die FB in der Liste und die schmollt.

[saft6luck]

Die Unix-Zeit steht zu dem Zeitpunkt auf 1970. Diese Jahreszahl ist aber inkompatibel mit dem KNX-Zeitstempel, deswegen kommt da nach der Konvertierung 2034 raus.

Gut, dann ist das schon mal geklärt. Könnte man das auf irgend etwas vor 2010 setzen?

So, hier ist die Ausgabe des eibPCs:

ntpq -p 192.168.1.32
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*fritz.box       109.74.206.120   3 u  420 1024  377    2.805   10.049   1.191

Da steht die Fritzbox bzw. das Standard Gateway (eben die Fritzbox) drinnen.

Bei meinem Server habe ich testweise diverse ntp Server bzw. Gruppen aus dem Pool eingetragen und nie war die Fritzbox drinnen:

ntpq -pn 192.168.1.27
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*85.214.29.92    130.149.17.8     2 u   35   64  377   64.697    5.529   9.376
-91.121.104.170  193.190.230.65   2 u   38   64  377   59.505   -3.632   9.677
+217.147.223.78  194.242.34.149   2 u   40   64  377   57.860    4.858  11.353
+64.22.86.210    209.51.161.238   2 u   17   64  377  159.906    5.591   2.482
-70.86.250.6     129.7.1.66       2 u   49   64  377  207.884  -11.381   8.889
-149.20.54.20    132.163.4.101    2 u   43   64  377  211.374   11.457  12.989

Ist evtl. die automatische Konfiguration des ntpd im eibPC aktiv? Oder hat DNS ein Problem? Wenn ihr schon am Patchen seid, probiert doch mal eine IP-Adresse eines ntp-Servers aus. Dann darf die Fritzbox nicht mehr drinnen stehen.

[makki]

Ob die Fritzi das verbiegt (ich weiss es wirklich nicht, mag auch Versionsabhängig sein!) lässt sich aber mit einem

nslookup pool.ntp.org

oder im Falle von Bodo, Männer-OS () mit

dig pool.ntp.org

rausfinden.

Gibt das die IP der Fritz, dreht sie am DNS. Falls nicht (mind 3 externe IPs kommen zurück) ist sie entlastet..

Makki

[Bodo]

Gibt das die IP der Fritz, dreht sie am DNS. Falls nicht (mind 3 externe IPs kommen zurück) ist sie entlastet..

Hoi Makki

Also scheinbar entlastet?

 dig pool.ntp.org

; <<>> DiG 9.6-ESV-R1 <<>> pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 365
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;pool.ntp.org.                  IN      A

;; ANSWER SECTION:
pool.ntp.org.           243     IN      A       194.88.212.200
pool.ntp.org.           243     IN      A       77.109.132.50
pool.ntp.org.           243     IN      A       153.109.180.3

;; Query time: 15 msec
;; SERVER: 10.0.1.100#53(10.0.1.100)
;; WHEN: Tue Jun 29 02:49:44 2010
;; MSG SIZE  rcvd: 78

Danke für den Tipp

[saft6luck]

Also scheinbar entlastet?

So ähnlich sieht es bei mir auch aus.

[salixer]

Ist evtl. die automatische Konfiguration des ntpd im eibPC aktiv?

Nein, die DHCP-Konfiguration der NTP-Server ist im DHCP-Client nicht aktiviert. Die korrekte Funktion habe ich hier im Haus mit unserem DHCP-Server auch schon überprüft.
Da DNS aber auch nicht das Problem ist, werde ich mir die DHCP-Sache nochmal genauer Ansehen. Eventuell gibt es da ein Problem zwischen dem Fritzbox-DHCP-Server und dem ISC-DHCP-Client.

[saft6luck]

Nein, die DHCP-Konfiguration der NTP-Server ist im DHCP-Client nicht aktiviert. Die korrekte Funktion habe ich hier im Haus mit unserem DHCP-Server auch schon überprüft.

Ich dachte auch eher an das ntp-server-autodiscovery des ntpd.

[salixer]

Ich dachte auch eher an das ntp-server-autodiscovery des ntpd.

Falls du das "listen for broadcast time packets" meinst: Das ist ebenfalls nicht aktiviert. Ein anderes autodiscovery wäre mir nicht bekannt und aktiviert ist auch nichts. Habe jetzt einen neuen Testpatch erstellt, der knallhart alle Möglichkeiten der DHCP-Konfiguration der NTP-Server unterbindet. Mal sehen...

[Bodo]

Hoi Zammä

Also jetzt scheint es zu gehen. Dank der Hilfe von Thorsten.

% C:\Users\gun/bin/Eib/nconf -z1 10.0.1.4 
% Datum und Uhrzeit des EibPCs: 2010-06-29 18:41:37 
Sommerzeit: ja

und

ntpq -p 10.0.1.4 
     remote           refid      st t when poll reach   delay    offset   jitter 
============================================================================== 
*ptbtime1.ptb.de .PTB.            1 u   23   64   17   42.021     4.797    2.953 
 ptbtime2.ptb.de .PTB.            1 u   46   64    7   41.866     3.522   2.093