Kann auf den Daemon von OpenNTP nicht zugreifen

[Fred Edison]

Moin moin,

ich habe folgendes Problem. Ich kann den OpenNTP zwar starten und ich bekomme auch die Meldung, dass der Daemon auf seiner eingestellten IP lauscht und die Zeit synchronisiert, aber ich kann weder mit einem NTP client auf den NTP server der FritzBox zugreifen noch funktioniert ein "telnet 10.*.*.* 123" und "telnet localhost 123". Ich bekomme immer die Meldung "Connection refused". Auch ein "netstat -al | grep 123" zeigt an, dass der Port 123 nicht offen ist.

Ich habe alles nach der Anleitung OpenNTP gemacht und laut dem syslog scheint der OpentNTP ja auch zu laufen. Ich frage mich, ob und welchen Punkt ich vergessen habe. Ich habe hier nämlich noch nichts gefunden, dass das ein Fehler sein könnte, da die letzten Einträge relativ alt sind. Deswegen gehe ich davon aus, dass dbei anderen das Paket ohne Probleme funktioniert. Ach ja mit dem Trunk (Revision 8925) hatte ich dasselbe Problem.


Hat irgendjemand eine Idee, was ich vergessen haben könnte?

messages

Jun 16 23:22:33 xxx daemon.info ntpd[5484]: listening on 10.*.*.*
Jun 16 23:22:33 xxx daemon.info ntpd[5484]: ntp engine ready
Jun 16 23:22:52 xxx daemon.info ntpd[5484]: peer 192.53.103.103 now valid
Jun 16 23:22:53 xxx daemon.info ntpd[5484]: peer 192.53.103.108 now valid
Jun 16 23:22:56 xxx daemon.info ntpd[5484]: peer 192.53.103.104 now valid
Jun 16 23:23:51 xxx daemon.info ntpd[5485]: adjusting local clock by -4.810809s
Jun 16 23:28:14 xxx daemon.info ntpd[5485]: adjusting local clock by -5.661735s
Jun 16 23:32:34 xxx daemon.info ntpd[5485]: adjusting local clock by -6.234199s
Jun 16 23:36:57 xxx daemon.info ntpd[5485]: adjusting local clock by -7.14592s
Jun 16 23:41:14 xxx daemon.info ntpd[5485]: adjusting local clock by -8.101179s
Jun 16 23:45:32 xxx daemon.info ntpd[5485]: adjusting local clock by -9.222608s

config (7390_05.22-freetz-devel (Revision 9169) )
Anhang anzeigen config.zip

Vielen Dank und viele Grüsse
Fred

 

[sf3978]

Auch ein "netstat -al | grep 123" zeigt an, dass der Port 123 nicht offen ist.

Was zeigt:

netstat -ulpen | grep 123

und

sudo nmap -sU <IP-Adresse-FritzBox> -p123

an?

 

[Fred Edison]

Was zeigt:

@fritz.box netstat -ulpen | grep 123

udp        0      0 192.*.*.*:1900      0.0.0.0:*                           1236/upnpd
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           1236/upnpd
udp        0      0 10.*.*.*:1900        0.0.0.0:*                           1236/upnpd
udp        0      0 10.*.*.*:123         0.0.0.0:*                           6345/ntpd
udp        0      0 :::46803                :::*                                1232/ctlmgr
udp        0      0 :::1900                 :::*                                1236/upnpd
udp        0      0 *::*:*:*:9075:1900 :::*                                1236/upnpd

Also der Port 123 scheint doch von dem ntpd belegt zu sein und die PID ist korrekt.

sudo nmap -sU <IP-Adresse-FritzBox> -p123

an?

OpenNTP startet nicht automatisch nach dem Reboot obwohl es eigestellt ist.

Starting Nmap 5.00 ( http://nmap.org ) at 2012-06-17 01:13 CEST
Interesting ports on fritz.box (10.*.*.1):
PORT    STATE  SERVICE
123/udp closed ntp
MAC Address: <MAC> (AVM GmbH)

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

OpenNTP gestartet

Starting Nmap 5.00 ( http://nmap.org ) at 2012-06-17 01:13 CEST
Interesting ports on fritz.box (10.*.*.1):
PORT    STATE         SERVICE
123/udp open|filtered ntp
MAC Address: <MAC> (AVM GmbH)

Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

Hmm, ok, das riecht nach der Firewall. Ich habe jetzt mal folgenden Eintrag über das Freetz-Webinterface in die AVM Firewall eingetragen.
Quelle: 10.*.*.0 255.255.255.0
Ziel: 10.*.*.1
Protokoll: UDP
Service/Port: 123

Ist aber dasselbe Ergebnis nach einem Neustart.

Vielen Dank für Deine Hilfe! Hast Du noch eine Idee?

<edit on>
Ok, dass OpenNTP nach einem Neustart nicht startet, kann ich im syslog machvollziehen.

Jan  1 01:01:13 fritz.box daemon.info ntpd[2826]: listening on 10.*.*.1
Jan  1 01:01:13 fritz.box daemon.info ntpd[2826]: ntp engine ready
Jan  1 01:01:13 fritz.box daemon.crit ntpd[2826]: imsg_get: Cannot allocate memory
Jan  1 01:01:13 fritz.box daemon.info ntpd[2826]: ntp engine exiting

Da muss ich dann auch mal ran.
<edit off>

 

[Suchiman]

OpenNTPD startet nicht wenn man es auf Automatisch stellt, da kommt auch bei immer der Fehler Cannot allocate memory, manuell starten hilft dannn aber. Zu deinem Problem: OpenNTPD geht erst in den Zeitserver Modus wenn er der meinung ist, dass die Systemzeit korrekt ist. Das kann nach "peer xxx.xxx.xxx.xxx now valid" noch eine halbe Stunde oder länger dauern. Ein Beispiel von mir

Jan  1 01:01:43 fritz user.notice FREETZMOD: Starting openntpd ... done.
Jun 15 20:47:40 fritz daemon.info ntpd[5146]: listening on 0.0.0.0
Jun 15 20:47:40 fritz daemon.info ntpd[5146]: ntp engine ready
Jun 15 20:47:56 fritz daemon.info ntpd[5146]: peer 192.53.103.103 now valid
Jun 15 20:47:58 fritz daemon.info ntpd[5146]: peer 192.53.103.104 now valid
Jun 15 20:48:01 fritz daemon.info ntpd[5146]: peer 192.53.103.108 now valid
Jun 15 20:48:49 fritz daemon.info ntpd[5147]: adjusting local clock by 0.147029s
Jun 15 21:00:19 fritz daemon.info ntpd[5147]: skew change 178.301 exceeds limit
Jun 15 21:00:19 fritz daemon.info ntpd[5146]: clock is now synced
Jun 15 21:16:45 fritz daemon.info ntpd[5147]: adjusting local clock by -0.260070s
Jun 15 21:16:45 fritz daemon.info ntpd[5147]: skew change -131.916 exceeds limit
Jun 15 21:22:43 fritz daemon.info ntpd[5147]: adjusting local clock by -0.201971s
Jun 15 21:22:43 fritz daemon.info ntpd[5146]: clock is now unsynced
Jun 15 21:30:32 fritz daemon.info ntpd[5147]: skew change 44.650 exceeds limit
Jun 15 21:30:32 fritz daemon.info ntpd[5146]: clock is now synced

erst ab "clock is now synced" ist es möglich, die Zeit zu synchronisieren.

 

[Fred Edison]

...
Jun 15 21:00:19 fritz daemon.info ntpd[5147]: skew change 178.301 exceeds limit
Jun 15 21:16:45 fritz daemon.info ntpd[5147]: skew change -131.916 exceeds limit
Jun 15 21:22:43 fritz daemon.info ntpd[5146]: clock is now unsynced
Jun 15 21:30:32 fritz daemon.info ntpd[5147]: skew change 44.650 exceeds limit
Jun 15 21:30:32 fritz daemon.info ntpd[5146]: clock is now synced
...

Danke für die Antwort. Könntest Du mir bitte mal Deinen Konfig posten?
Ich habe mal nach den Einträgen gesucht, die Du gepostet hast. 5 Minuten nach einem "clock is now synced" kommt immer ein "clock is now unsynced". Wenn das stimmt, dass ich mit dem NTP Zeitserver nur synchronisieren kann, wenn die Uhr synchron ist, dann ist es ja kein Wunder, dass das nie klappt.
Wobei es mich schon ein wenig wundert, da ich ganz früher (vor ca. 6 Jahren) einen richtigen Rechner als Router laufen liess und mit dem konnte ich zu jeder Zeit synchronisieren, auch wenn die Uhrzeit ein wenig falsch war.

Meine Konfig sieht so aus, kann gur sein, dass ich etwas kaputt gespielt habe. :|

# Addresses to listen on (ntpd does not listen by default)
# Use '0.0.0.0' to listen on every local interface
listen on 10.*.*.1
# use a random selection of 8 public stratum 2 servers
# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
server ptbtime1.ptb.de
server ptbtime2.ptb.de
server ptbtime3.ptb.de

# sync to a single server
#server ntp.example.org

# sync with all NTP servers on time, violates OpenNTPD philosophy
# format: [H]H:MM[:SS] [...]
#sync at 0:01 2:01 3:01 4:01

# add randomized offset (max. 90s) to each "sync at"
#sync at randomize

# sync using custom (randomized) interval T, violates OpenNTPD philosophy
# format: T[s|m|h] (default suffix is s)
#sync every 5m

# retry on error (NTP server communication) using next time delay T
# sequence is maintained per NTP server
# format: T[s|m|h] [...] [r|rN]
#         T  -> time delay (default suffix is s) or special value *
#         *  -> at next regular sync
#         r  -> repeat sequence from beginning
#         rN -> repeat last N entries from sequence
# default repeat is r1, on success sequence is repeated from the beginning
#error retry 30 30 30 1m 1m 2m 5m 1h 30 * 30 r2

Vielen Dank.

 

[Suchiman]

Meine ist ganz minimalistisch

# Addresses to listen on (ntpd does not listen by default)
# Use '0.0.0.0' to listen on every local interface
listen on 0.0.0.0

# Zeitserver der Physikalisch-Technischen Bundesanstalt (PTB Braunschweig)
servers ptbtime1.ptb.de
servers ptbtime2.ptb.de
servers ptbtime3.ptb.de

 

[Fred Edison]

Ok, vielen Dank.

Im Prinzip steht bei mir nicht mehr drin. Wobei es mich doch schon verwirrt, dass bei Dir "servers" drin steht und bei mir nur "server". Ich hatte in Erinnerung, dass unter Servers nur Pools mit ntp Servern eingetragen werden. Die Server von der PTB sind eigentlich single Server. Na ja, habe das mal geändert und den "ptbtime1.ptb.de" rausgeworfen, da der hin und wieder bei mir als "not valid" im syslog auftaucht. Werde mal eine Nacht schlafen.

Was noch merkwürdig ist, dass eine andere Uhr (auch mit PTB synchron) ca. ~20s vor der Uhrzeit der FritzBox liegt. Komischerweise taucht in der FritzBox aber die Meldung "ntpd[5498]: adjusting local clock by -18.993236s" . Ziehe ich diese Zeit von der FritzBox ab, bin ich bin der Uhrzeit von dem anderen Gerät.
Für mich heisst das, dass OpenNTP erkennt, dass die Uhrzeit falsch ist, aber die Uhr der FritzBox so extrem schnell falsch läuft, da sie nie richtig laufen wird. Alle 5 Minuten 18s differenz ist schon recht viel.
Es sei denn, die FritzBox synchronisiert noch mit einer anderen (falschen) Zeitquelle wie das Telefonnetz, weil ich am Anfang nach einem Reboot z.B. folgende Meldung sehe "Apr 23 00:49:47 fritz user.err telefon[1011]: set initial telefon time from linux time to 0:49:47 23.04 2012!" .

Ok, werde morgen mal weitermachen.

 

[RalfFriedl]

Ich habe jetzt mal folgenden Eintrag über das Freetz-Webinterface in die AVM Firewall eingetragen.
Quelle: 10.*.*.0 255.255.255.0
Ziel: 10.*.*.1
Protokoll: UDP
Service/Port: 123

Ist aber dasselbe Ergebnis nach einem Neustart.

Das hat damit nichts zu tun und hat wie Du schreibst auch nichts geholfen. Du den EIntrag solltest das wieder entfernen.

Wobei es mich schon ein wenig wundert, da ich ganz früher (vor ca. 6 Jahren) einen richtigen Rechner als Router laufen liess und mit dem konnte ich zu jeder Zeit synchronisieren, auch wenn die Uhrzeit ein wenig falsch war.

Der PC hatte auch eine Hardware Uhr, die Box hat keine und startete deshalb auch mit 1. Jan 2000.

Apr 23 00:49:47 fritz user.err telefon[1011]: set initial telefon time from linux time to 0:49:47 23.04 2012!

Das bedeutet, dass telefon die Zeit vom System geholt hat und nicht umgekehrt.

 

[Fred Edison]

Das hat damit nichts zu tun und hat wie Du schreibst auch nichts geholfen. Du den EIntrag solltest das wieder entfernen.


Der PC hatte auch eine Hardware Uhr, die Box hat keine und startete deshalb auch mit 1. Jan 2000.


Das bedeutet, dass telefon die Zeit vom System geholt hat und nicht umgekehrt.

1. Jup, schon erledigt.
2. Ok, dem war ich mir nicht bewusst, aber wo Du es sagst, ist es einleuchtend.
3. Hmm, ok, macht Sinn, wobei genau bei dieser Meldung die Systemzeit von 1. Jan 2000 auf die richtige Zeit gesetzt wurde, daher kam meine Annahme.
Danke.


Ok, ca. 9 Stunden später sehe ich folgende Meldungen.

Jun 17 13:49:21 fritz.box daemon.info ntpd[7992]: adjusting local clock by -2m 17.019969s
Jun 17 13:53:29 fritz.box daemon.info ntpd[7992]: adjusting local clock by -2m 18.016774s

Diese Differenz von über zwei Minuten kann ich nachvollziehen, wenn ich es mit einem anderen NTP synchronisierten Gerät vergleiche. Gehe ich Recht in der Annahme, dass OpenNTP die Zeitdifferenz zum NTP Server erkennt, diese aber nicht korrigiert? Die Zeitdifferenz wird nämlich immer grösser und die die Meldung taucht so alle 4-5 Minuten auf.

 

[RalfFriedl]

Gehe ich Recht in der Annahme, dass OpenNTP die Zeitdifferenz zum NTP Server erkennt, diese aber nicht korrigiert? Die Zeitdifferenz wird nämlich immer grösser und die die Meldung taucht so alle 4-5 Minuten auf.

Deine Beobachtung spricht dafür, aber es sollte nicht so sein.

 

[olistudent]

Ticket mit Patch: http://freetz.org/ticket/1859

Gruß
Oliver

 

[Fred Edison]

kleines Update

@olistudent
Ich habe Deinen Patch nun mit dem Freetz für die FritzBox 7170 getestet und zumindest kann ich sagen, dass OpenNTP dort automatisch startet. Ob das Problem vorher dort aufgetreten wäre, kann ich nicht sagen, da ja auf der 7170 eventuell eine andere uLibC verwendet wird.

@allgemein
Wie gesagt, auf der 7170 läuft der OpenNTP einwandfrei. Es erscheint die Meldung "clock is now synced" erscheint, erst dann können sich die NTP Clients auch syncen (wie Suchiman bereits erklärte).
Das ein telnet auf dem Port 123 nicht funktionierte, wird wohl mit dem UDP Service zusammenhängen. Wenn man darüber grübelt, macht es dann aber auch Sinn.

Ich habe nun meine 7390 so eingestellt, dass sie sich die Zeit von der 7170 holt und hier habe ich nun ein lustiges Phänomen. Es kommt die Meldung "Jun 23 23:20:11 fritz.box daemon.info ntpd[11230]: reply from 10.*.*.2: negative delay -0.000155" . Dieses Problem wird im Bug Tracking Forum von Debian diskutiert und die Meldung sagt wohl aus, dass meine FritzBox 7390 angeblich eine Antwort vom OpenNTP bekommt bevor die Anfrage geschict wurde.

So wie ich es sehe verwenden wir die BSD Version OpenNTP 3.9p1, der Bug wurde in der Debian Version 3.9p1-3 gefunden und zur Version 3.9p1+debian-7 gepatcht . Da das Problem in einer Xen Umgebung auftauchte, und ich davon ausgehe, dass es sich auch dort wie bei der FritzBox um eine softwarebasierte Uhr handelt, könnte ich mir vorstellen, dass das eventuell für das Freetz-Paket interessant sein könnte. So tief bin ich aber in Freetz nicht drin, vielleicht seht Ihr da schneller einen Zusammenhang (oder auch keinen).

Ich bleibe aber an dem Problem dran.

Danke ansonsten für die Hilfe.

 

[RalfFriedl]

Das ein telnet auf dem Port 123 nicht funktionierte, wird wohl mit dem UDP Service zusammenhängen.

Das liegt sogar ganz sicher am UDP. Telnet verwendet TCP.