NTP funktioniert nicht

dirk

12 Feb 2018 12 Feb '18

14:47

Hallo, mein Zeitserver funktioniert schon wieder nicht mehr. Vom letzten Mal habe ich mir gemerkt er liefert die Zeit nicht aus, wenn er selber keine korrekte Zeit erhält. Also: # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 78.46.204.247 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 51.15.175.224 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 185.183.156.211 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 Kann es denn sein, dass keiner von den servern eine Zeit auslierfert? Auch die PTB nicht? Merkwürdig. Kann jemand helfen? -- Dirk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Show replies by date

Martin Burnicki

12 Feb 12 Feb

19:05

Am 12.02.2018 um 15:47 schrieb dirk:

...

Hallo,

mein Zeitserver funktioniert schon wieder nicht mehr. Vom letzten Mal habe ich mir gemerkt er liefert die Zeit nicht aus, wenn er selber keine korrekte Zeit erhält.

Ja, so ist es.

...

Also: # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

78.46.204.247 .INIT. 16 u - 64 0 0.000 0.000 0.000 [...]

Kann es denn sein, dass keiner von den servern eine Zeit auslierfert? Auch die PTB nicht? Merkwürdig.

Funktioniert denn die Internet-Anbindung generell? Kannst du die IP-Adressen anpingen? Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist. Um das zu testen, kannst du dann mal temporär die Firewall abschalten, und (damit es schneller geht) den ntpd neu starten. Als root: rcSuSEfirewall2 stop rcntpd restart Wenn du dann mehrmals in Abständen "ntpq -pn" aufrufst und du siehst, dass die "reach"-Werte in der Ausgabe nicht mehr 0 bleiben, sondern hochzählen, ist in der Tat die Firewall schuld. Du solltest dann in Yast in die Firewall-Einstellungen gehen und den Port für NTP freischalten. Danach sollte es auch mit laufender Firewall funktionieren. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

dirk

20:08

Am 12.02.2018 20:05, schrieb Martin Burnicki:

...

Am 12.02.2018 um 15:47 schrieb dirk:

...
Hallo,

mein Zeitserver funktioniert schon wieder nicht mehr. Vom letzten Mal habe ich mir gemerkt er liefert die Zeit nicht aus, wenn er selber keine korrekte Zeit erhält.

Ja, so ist es.

...
Also: # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

78.46.204.247 .INIT. 16 u - 64 0 0.000 0.000 0.000 [...]

Kann es denn sein, dass keiner von den servern eine Zeit auslierfert? Auch die PTB nicht? Merkwürdig.

Funktioniert denn die Internet-Anbindung generell? Kannst du die IP-Adressen anpingen?

Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist. Um das zu testen, kannst du dann mal temporär die Firewall abschalten, und (damit es schneller geht) den ntpd neu starten. Als root:

rcSuSEfirewall2 stop rcntpd restart

Wenn du dann mehrmals in Abständen "ntpq -pn" aufrufst und du siehst, dass die "reach"-Werte in der Ausgabe nicht mehr 0 bleiben, sondern hochzählen, ist in der Tat die Firewall schuld.

Du solltest dann in Yast in die Firewall-Einstellungen gehen und den Port für NTP freischalten. Danach sollte es auch mit laufender Firewall funktionieren.

Martin

Internetverbindung ist vorhanden. Leider keine Verbesserung: # rcSuSEfirewall2 stop redirecting to systemctl # rcntpd restart bash: rcntpd: Kommando nicht gefunden. # rcntp status redirecting to systemctl ntp.service - LSB: Network time protocol daemon (ntpd) Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Mon, 12 Feb 2018 15:39:37 +0100; 5h 19min ago Process: 8750 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS) Process: 8764 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ntp.service └ 8793 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf # rcntp restart redirecting to systemctl # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ping web.de PING web.de (82.165.230.17) 56(84) bytes of data. 64 bytes from web.de (82.165.230.17): icmp_seq=1 ttl=242 time=25.2 ms 64 bytes from web.de (82.165.230.17): icmp_seq=2 ttl=242 time=22.5 ms ^C --- web.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 22.531/23.891/25.251/1.360 ms # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Burnicki

22:36

Am 12.02.2018 um 21:08 schrieb dirk:

...

Am 12.02.2018 20:05, schrieb Martin Burnicki:

...
Am 12.02.2018 um 15:47 schrieb dirk:

...
Hallo,

mein Zeitserver funktioniert schon wieder nicht mehr. Vom letzten Mal habe ich mir gemerkt er liefert die Zeit nicht aus, wenn er selber keine korrekte Zeit erhält.

Ja, so ist es.

...
Also: # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

78.46.204.247 .INIT. 16 u - 64 0 0.000 0.000 0.000 [...]

Kann es denn sein, dass keiner von den servern eine Zeit auslierfert? Auch die PTB nicht? Merkwürdig.

Funktioniert denn die Internet-Anbindung generell? Kannst du die IP-Adressen anpingen?

Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist. Um das zu testen, kannst du dann mal temporär die Firewall abschalten, und (damit es schneller geht) den ntpd neu starten. Als root:

rcSuSEfirewall2 stop rcntpd restart

Wenn du dann mehrmals in Abständen "ntpq -pn" aufrufst und du siehst, dass die "reach"-Werte in der Ausgabe nicht mehr 0 bleiben, sondern hochzählen, ist in der Tat die Firewall schuld.

Du solltest dann in Yast in die Firewall-Einstellungen gehen und den Port für NTP freischalten. Danach sollte es auch mit laufender Firewall funktionieren.

Martin

Internetverbindung ist vorhanden. Leider keine Verbesserung:

# rcSuSEfirewall2 stop redirecting to systemctl # rcntpd restart bash: rcntpd: Kommando nicht gefunden. # rcntp status redirecting to systemctl ntp.service - LSB: Network time protocol daemon (ntpd) Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Mon, 12 Feb 2018 15:39:37 +0100; 5h 19min ago Process: 8750 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS) Process: 8764 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ntp.service └ 8793 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf # rcntp restart redirecting to systemctl # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ping web.de PING web.de (82.165.230.17) 56(84) bytes of data. 64 bytes from web.de (82.165.230.17): icmp_seq=1 ttl=242 time=25.2 ms 64 bytes from web.de (82.165.230.17): icmp_seq=2 ttl=242 time=22.5 ms ^C --- web.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 22.531/23.891/25.251/1.360 ms # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000

OK, wie sieht denn deine Datei /etc/ntp.conf aus? kannst du mal alle Zeilen mit "restrict" auskommentieren und dann nochmal ntpd neu starten? Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

dirk

22:56

Am 12.02.2018 23:36, schrieb Martin Burnicki:

...

Am 12.02.2018 um 21:08 schrieb dirk:

...
Am 12.02.2018 20:05, schrieb Martin Burnicki:

...
Am 12.02.2018 um 15:47 schrieb dirk:

...
Hallo,

mein Zeitserver funktioniert schon wieder nicht mehr. Vom letzten Mal habe ich mir gemerkt er liefert die Zeit nicht aus, wenn er selber keine korrekte Zeit erhält.

Ja, so ist es.

...
Also: # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

78.46.204.247 .INIT. 16 u - 64 0 0.000 0.000 0.000 [...]

Kann es denn sein, dass keiner von den servern eine Zeit auslierfert? Auch die PTB nicht? Merkwürdig.

Funktioniert denn die Internet-Anbindung generell? Kannst du die IP-Adressen anpingen?

Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist. Um das zu testen, kannst du dann mal temporär die Firewall abschalten, und (damit es schneller geht) den ntpd neu starten. Als root:

rcSuSEfirewall2 stop rcntpd restart

Wenn du dann mehrmals in Abständen "ntpq -pn" aufrufst und du siehst, dass die "reach"-Werte in der Ausgabe nicht mehr 0 bleiben, sondern hochzählen, ist in der Tat die Firewall schuld.

Du solltest dann in Yast in die Firewall-Einstellungen gehen und den Port für NTP freischalten. Danach sollte es auch mit laufender Firewall funktionieren.

Martin

Internetverbindung ist vorhanden. Leider keine Verbesserung:

# rcSuSEfirewall2 stop redirecting to systemctl # rcntpd restart bash: rcntpd: Kommando nicht gefunden. # rcntp status redirecting to systemctl ntp.service - LSB: Network time protocol daemon (ntpd) Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Mon, 12 Feb 2018 15:39:37 +0100; 5h 19min ago Process: 8750 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS) Process: 8764 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ntp.service └ 8793 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf # rcntp restart redirecting to systemctl # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ping web.de PING web.de (82.165.230.17) 56(84) bytes of data. 64 bytes from web.de (82.165.230.17): icmp_seq=1 ttl=242 time=25.2 ms 64 bytes from web.de (82.165.230.17): icmp_seq=2 ttl=242 time=22.5 ms ^C --- web.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 22.531/23.891/25.251/1.360 ms # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000 # ntpq -pn remote refid st t when poll reach delay offset jitter ==============================================================================

213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.21 .INIT. 16 u - 64 0 0.000 0.000 0.000 130.149.17.8 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.108 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.104 .INIT. 16 u - 64 0 0.000 0.000 0.000 129.69.1.153 .INIT. 16 u - 64 0 0.000 0.000 0.000 192.53.103.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 204.11.201.10 .INIT. 16 u - 64 0 0.000 0.000 0.000 194.25.134.196 .INIT. 16 u - 64 0 0.000 0.000 0.000 62.128.1.19 .INIT. 16 u - 64 0 0.000 0.000 0.000 132.199.4.1 .INIT. 16 u - 64 0 0.000 0.000 0.000

OK, wie sieht denn deine Datei /etc/ntp.conf aus?

kannst du mal alle Zeilen mit "restrict" auskommentieren und dann nochmal ntpd neu starten?

Martin

Es gibt keine Zeilen mit "restrict": # cat ntp.conf # LCL is unsynchronized ## ## Add external Servers using ## # rcntp addserver <yourserver> ## ## ## Miscellaneous stuff ## driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file # logconfig =syncstatus + sysevents # logconfig =all # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable # # Authentication stuff # keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 server de.pool.ntp.org iburst server ntps1-0.cs.tu-berlin.de iburst server ntps1-1.cs.tu-berlin.de iburst server ptbtime1.ptb.de iburst server ptbtime2.ptb.de iburst server rustime01.rus.uni-stuttgart.de iburst server ptbtime3.ptb.de iburst server pool.ntp.org iburst server ntp1.t-online.de iburst server de.pool.ntp.arcor-ip.net iburst server ntp.ur.de iburst # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Burnicki

13 Feb 13 Feb

07:06

Am 12.02.2018 um 23:56 schrieb dirk:

...

Am 12.02.2018 23:36, schrieb Martin Burnicki:

...
OK, wie sieht denn deine Datei /etc/ntp.conf aus?

kannst du mal alle Zeilen mit "restrict" auskommentieren und dann nochmal ntpd neu starten?

Martin

Es gibt keine Zeilen mit "restrict":

# cat ntp.conf # LCL is unsynchronized

## ## Add external Servers using ## # rcntp addserver <yourserver> ##

## ## Miscellaneous stuff ##

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile /var/log/ntp # alternate log file # logconfig =syncstatus + sysevents # logconfig =all

# statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable

# # Authentication stuff # keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 server de.pool.ntp.org iburst server ntps1-0.cs.tu-berlin.de iburst server ntps1-1.cs.tu-berlin.de iburst server ptbtime1.ptb.de iburst server ptbtime2.ptb.de iburst server rustime01.rus.uni-stuttgart.de iburst server ptbtime3.ptb.de iburst server pool.ntp.org iburst server ntp1.t-online.de iburst server de.pool.ntp.arcor-ip.net iburst server ntp.ur.de iburst # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables

Hm, Firewall oder "restrict" sind eigentlich die Kandidaten, die hier in Frage kommen. Aber wie du in einer anderen Antwort (jetzt erst) schriebst, ist ja noch ein weiterer Router mit im Spiel, auf dem ebenfalls eine Firewall läuft, die die NTP-Pakete blocken könnte. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

dirk

12:31

Am 13.02.2018 08:06, schrieb Martin Burnicki:

...

Am 12.02.2018 um 23:56 schrieb dirk:

...
Am 12.02.2018 23:36, schrieb Martin Burnicki:

...
OK, wie sieht denn deine Datei /etc/ntp.conf aus?

kannst du mal alle Zeilen mit "restrict" auskommentieren und dann nochmal ntpd neu starten?

Martin

Es gibt keine Zeilen mit "restrict":

# cat ntp.conf # LCL is unsynchronized

## ## Add external Servers using ## # rcntp addserver <yourserver> ##

## ## Miscellaneous stuff ##

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile /var/log/ntp # alternate log file # logconfig =syncstatus + sysevents # logconfig =all

# statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable

# # Authentication stuff # keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 server de.pool.ntp.org iburst server ntps1-0.cs.tu-berlin.de iburst server ntps1-1.cs.tu-berlin.de iburst server ptbtime1.ptb.de iburst server ptbtime2.ptb.de iburst server rustime01.rus.uni-stuttgart.de iburst server ptbtime3.ptb.de iburst server pool.ntp.org iburst server ntp1.t-online.de iburst server de.pool.ntp.arcor-ip.net iburst server ntp.ur.de iburst # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables

Hm, Firewall oder "restrict" sind eigentlich die Kandidaten, die hier in Frage kommen.

Aber wie du in einer anderen Antwort (jetzt erst) schriebst, ist ja noch ein weiterer Router mit im Spiel, auf dem ebenfalls eine Firewall läuft, die die NTP-Pakete blocken könnte.

Martin

Sorry, die Firewall auf dem Router funktioniert mit den Standardeinstellungen schon seit Jahren problemlos. Auch mit dem NTP. Habe aber nochmal jetzt die Firewall auf dem Router und die Firewall auf dem PC deaktiviert. Es hat sich leider nichts verbessert. In Yast kann ich ja die eingestellten Zeitserver testen. Bei allen erhalte ich die Antwort dass die Server laufen und korrekt antworten. Habe jetz mit meinem Laptop direkt an der Fritzbox die Zeit synchronisieren können. Direkt am router nicht. Auch mit deaktivierter Firewall nicht. Muss demnach irgendwie mit der Umstellung von Cisco Modem auf FB zu tun haben. Trotzdem vielen Dank für Deine Unterstützung. Dadurch konnte ich den Fehler eingrenzen. -- Dirk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Johannes Kapune

16:18

Hallo Dirk, kann es sein dass die FritzBox den NTP-Server im Netzwerk macht? Im Menue: Heimnetz - Netzwerk - Zeitsynchronisation Johannes Am 13.02.2018 um 13:31 schrieb dirk:

...

Am 13.02.2018 08:06, schrieb Martin Burnicki:

...
Am 12.02.2018 um 23:56 schrieb dirk:

...
Am 12.02.2018 23:36, schrieb Martin Burnicki:

...
OK, wie sieht denn deine Datei /etc/ntp.conf aus?

kannst du mal alle Zeilen mit "restrict" auskommentieren und dann nochmal ntpd neu starten?

Martin

Es gibt keine Zeilen mit "restrict":

# cat ntp.conf # LCL is unsynchronized

## ## Add external Servers using ## # rcntp addserver <yourserver> ##

## ## Miscellaneous stuff ##

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile /var/log/ntp # alternate log file # logconfig =syncstatus + sysevents # logconfig =all

# statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable

# # Authentication stuff # keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 server de.pool.ntp.org iburst server ntps1-0.cs.tu-berlin.de iburst server ntps1-1.cs.tu-berlin.de iburst server ptbtime1.ptb.de iburst server ptbtime2.ptb.de iburst server rustime01.rus.uni-stuttgart.de iburst server ptbtime3.ptb.de iburst server pool.ntp.org iburst server ntp1.t-online.de iburst server de.pool.ntp.arcor-ip.net iburst server ntp.ur.de iburst # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables

Hm, Firewall oder "restrict" sind eigentlich die Kandidaten, die hier in Frage kommen.

Aber wie du in einer anderen Antwort (jetzt erst) schriebst, ist ja noch ein weiterer Router mit im Spiel, auf dem ebenfalls eine Firewall lÃ€uft, die die NTP-Pakete blocken kÃ¶nnte.

Martin

Sorry, die Firewall auf dem Router funktioniert mit den Standardeinstellungen schon seit Jahren problemlos. Auch mit dem NTP. Habe aber nochmal jetzt die Firewall auf dem Router und die Firewall auf dem PC deaktiviert. Es hat sich leider nichts verbessert. In Yast kann ich ja die eingestellten Zeitserver testen. Bei allen erhalte ich die Antwort dass die Server laufen und korrekt antworten.

Habe jetz mit meinem Laptop direkt an der Fritzbox die Zeit synchronisieren kÃ¶nnen. Direkt am router nicht. Auch mit deaktivierter Firewall nicht.

Muss demnach irgendwie mit der Umstellung von Cisco Modem auf FB zu tun haben.

Trotzdem vielen Dank fÃŒr Deine UnterstÃŒtzung. Dadurch konnte ich den Fehler eingrenzen.

-- Dirk

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Handwerker, Jan (IMK)

17:26

Hallo Dirk, beim heiteren Ursachen-Raten möchte ich mitmachen: Mich hat ntp mal überrascht, indem es _nicht_ synchronisierte, weil die Uhrzeit zu sehr (mehr als 15 min.) von der Rechneruhrzeit abwich. Sprich: Kleine Abweichungen korrigiert es, bei größeren glaubt es, es gäbe einen vernünftigen Grund für die Abweichung und synchronisiert deshalb die Uhrzeit nicht. Ich weiß nicht mehr, ob es dafür eine lesbare Fehlermeldung gab. Ich erinnere mich nur noch blass, aber wenn's hilft, wär es ja nett :-). Gruß Jan Am 13.02.2018 um 17:18 schrieb Johannes Kapune:

...

Hallo Dirk, kann es sein dass die FritzBox den NTP-Server im Netzwerk macht?

Im Menue: Heimnetz - Netzwerk - Zeitsynchronisation

Johannes

Am 13.02.2018 um 13:31 schrieb dirk:

-- _________________________________________________________________ Jan Handwerker http://www.imk-tro.kit.edu/jan.handwerker.php

Martin Burnicki

21:39

Am 13.02.2018 um 18:26 schrieb Handwerker, Jan (IMK):

...

Hallo Dirk,

beim heiteren Ursachen-Raten möchte ich mitmachen: Mich hat ntp mal überrascht, indem es _nicht_ synchronisierte, weil die Uhrzeit zu sehr (mehr als 15 min.) von der Rechneruhrzeit abwich. Sprich: Kleine Abweichungen korrigiert es, bei größeren glaubt es, es gäbe einen vernünftigen Grund für die Abweichung und synchronisiert deshalb die Uhrzeit nicht.

Ich weiß nicht mehr, ob es dafür eine lesbare Fehlermeldung gab. Ich erinnere mich nur noch blass, aber wenn's hilft, wär es ja nett :-).

Das Standard-Verhalten des ntpd ist: 1.) Wenn die Abweichung kleiner ist als 128 ms, wird die Systemzeit weich nachgeführt. Das sollte der Regelfall sein im laufenden Betrieb. 2.) Wenn die Abweichung größer ist als 128 ms, aber kleiner als 1000 s (der sogenannte "panic threshold"), wird die Systemzeit hart gesetzt. Allerdings erst, wenn die Abweichung 900 Sekunden (= 15 Minuten) lang anhält. 3.) Wenn die Abweichung größer ist als 1000 s, beendet sich der ntpd mit einer Fehlermeldung, die sinngemäß sagt, man solle die Systemzeit erstmal grob richtig setzen. "Früher" hat man dazu einmal "ntpdate" aufgerufen, bevor ntpd als Daemon gestartet wurde. Wenn ntpd neu gestartet wird und Parameter -g angegeben wurde, wird 3.) einmalig außer Kraft gesetzt, um auch bei einer initialen größeren Zeitabweichung die Systemzeit richtig zu setzen, so dass normalerweise bereits eine Genauigkeit unter 128 ms erreicht wird und man sich den Aufruf des "ntpdate" vorher spart. Mit "iburst" in der Konfiguration geht das auch recht schnell. Nur wenn *danach* nochmal eine größere Zeitabweichung auftritt, z.B. weil "root" die Systemzeit verstellt, um ntpd zu "testen", treten Fälle 2.) oder 3.) auf. Wenn die "refid" in der Ausgabe von "ntpq -pn" auf ".INIT." steht, bedeutet das, dass ntpd keine Antwort von dieser Zeitquelle bekommt, wenn ntpd die Zeitquelle erstmalig kontaktiert. Da das hier für *alle* konfigurierten NTP-Server der Fall ist, hört sich das für mich nach einem Firewall-Problem an, da von keinem server eine Antwort eintrifft.. Im Prinzip könnte es auch ein Routing-Problem sein, aber wenn ein "ping" auf die externen Server funktioniert, trifft das wohl hier nicht zu. Es wäre auch sinnvoll, mit "journalctl" nach Log-Ausgaben von ntpd zu sehen. Leider (IMO) spezifiziert Suse ja in ntp.conf ein "alternate logfile", so dass Startup-Meldungen im Syslog landen, aber weitere Meldungen des ntpd ggf. in /var/log/messages. Fürs Debugging wäre es IMO sinnvoll, die Zeile "logfile" auszukommentieren und dafür das Kommentarzeichen vor "logconfig =all" zu entfernen, um soviele Meldungen wie möglich über einen einzigen Weg (journalctl) zu bekommen. Wenn es sich aber tatsächlich um ein Firewall-Problem handelt, kommen entweder die Antworten der einzelnen Server nicht beim lokalen ntpd an, oder die Anfragen des ntpd erreichen noch nicht einmal die einzelnen Server. Da gibt es dann wohl keine hilfreichen Log-Meldungen. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Handwerker, Jan (IMK)

14 Feb 14 Feb

08:03

Hallo Martin, vielen Dank für die ausführliche Erklärung. Jetzt muss ich sie mir nur noch so ablegen, dass ich sie das nächste Mal wieder finde, wenn _ich_ ein Problem mit ntp habe (was durchaus ab und wann vorkommt). Wenn ich nicht zur Problemlösung beitragen konnte, habe ich zumindest eine schöne Beschreibung für ntp getriggert :-). Gruß Jan Am 13.02.2018 um 22:39 schrieb Martin Burnicki:

...

Am 13.02.2018 um 18:26 schrieb Handwerker, Jan (IMK):

...
Hallo Dirk,

beim heiteren Ursachen-Raten möchte ich mitmachen: Mich hat ntp mal überrascht, indem es _nicht_ synchronisierte, weil die Uhrzeit zu sehr (mehr als 15 min.) von der Rechneruhrzeit abwich. Sprich: Kleine Abweichungen korrigiert es, bei größeren glaubt es, es gäbe einen vernünftigen Grund für die Abweichung und synchronisiert deshalb die Uhrzeit nicht.

Ich weiß nicht mehr, ob es dafür eine lesbare Fehlermeldung gab. Ich erinnere mich nur noch blass, aber wenn's hilft, wär es ja nett :-).

Das Standard-Verhalten des ntpd ist:

1.) Wenn die Abweichung kleiner ist als 128 ms, wird die Systemzeit weich nachgeführt. Das sollte der Regelfall sein im laufenden Betrieb.

2.) Wenn die Abweichung größer ist als 128 ms, aber kleiner als 1000 s (der sogenannte "panic threshold"), wird die Systemzeit hart gesetzt. Allerdings erst, wenn die Abweichung 900 Sekunden (= 15 Minuten) lang anhält.

3.) Wenn die Abweichung größer ist als 1000 s, beendet sich der ntpd mit einer Fehlermeldung, die sinngemäß sagt, man solle die Systemzeit erstmal grob richtig setzen. "Früher" hat man dazu einmal "ntpdate" aufgerufen, bevor ntpd als Daemon gestartet wurde.

Wenn ntpd neu gestartet wird und Parameter -g angegeben wurde, wird 3.) einmalig außer Kraft gesetzt, um auch bei einer initialen größeren Zeitabweichung die Systemzeit richtig zu setzen, so dass normalerweise bereits eine Genauigkeit unter 128 ms erreicht wird und man sich den Aufruf des "ntpdate" vorher spart. Mit "iburst" in der Konfiguration geht das auch recht schnell.

Nur wenn *danach* nochmal eine größere Zeitabweichung auftritt, z.B. weil "root" die Systemzeit verstellt, um ntpd zu "testen", treten Fälle 2.) oder 3.) auf.

Wenn die "refid" in der Ausgabe von "ntpq -pn" auf ".INIT." steht, bedeutet das, dass ntpd keine Antwort von dieser Zeitquelle bekommt, wenn ntpd die Zeitquelle erstmalig kontaktiert. Da das hier für *alle* konfigurierten NTP-Server der Fall ist, hört sich das für mich nach einem Firewall-Problem an, da von keinem server eine Antwort eintrifft.. Im Prinzip könnte es auch ein Routing-Problem sein, aber wenn ein "ping" auf die externen Server funktioniert, trifft das wohl hier nicht zu.

Es wäre auch sinnvoll, mit "journalctl" nach Log-Ausgaben von ntpd zu sehen. Leider (IMO) spezifiziert Suse ja in ntp.conf ein "alternate logfile", so dass Startup-Meldungen im Syslog landen, aber weitere Meldungen des ntpd ggf. in /var/log/messages.

Fürs Debugging wäre es IMO sinnvoll, die Zeile "logfile" auszukommentieren und dafür das Kommentarzeichen vor "logconfig =all" zu entfernen, um soviele Meldungen wie möglich über einen einzigen Weg (journalctl) zu bekommen.

Wenn es sich aber tatsächlich um ein Firewall-Problem handelt, kommen entweder die Antworten der einzelnen Server nicht beim lokalen ntpd an, oder die Anfragen des ntpd erreichen noch nicht einmal die einzelnen Server. Da gibt es dann wohl keine hilfreichen Log-Meldungen.

Martin

-- _________________________________________________________________ Jan Handwerker http://www.imk-tro.kit.edu/jan.handwerker.php

Martin Burnicki

08:35

Hallo Jan, Am 14.02.2018 um 09:03 schrieb Handwerker, Jan (IMK):

...

Hallo Martin,

vielen Dank für die ausführliche Erklärung. Jetzt muss ich sie mir nur noch so ablegen, dass ich sie das nächste Mal wieder finde, wenn _ich_ ein Problem mit ntp habe (was durchaus ab und wann vorkommt). Wenn ich nicht zur Problemlösung beitragen konnte, habe ich zumindest eine schöne Beschreibung für ntp getriggert :-).

Eine etwas ausführliche Beschreibung (allerdings in Englisch) findest du auch in diesem Whitepaper: "NTP Basics" https://www.meinberg.de/download/burnicki/ntp_basics.pdf Gruß, Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Peter Mulller

10:40

Am Mittwoch, 14. Februar 2018 09:03:01 schrieb Handwerker, Jan (IMK):

...

Hallo Martin,

vielen Dank für die ausführliche Erklärung.

Dem Dank schließe ich mich an, sehr ausführliche Antwort!

...

Jetzt muss ich sie mir nur noch so ablegen, dass ich sie das nächste Mal wieder finde, wenn _ich_ ein Problem mit ntp habe

Dafür gibt es eine Lösung: Du musst dir nur "opensuse mailingliste" und "Archiv" merken, über eine Suchmaschine gelangst du dann zu https://lists.opensuse.org/opensuse-de/ . "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" Linus Torvalds Peter Mulller -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Marcus Roeckrath

10:02

Hallo Johannes, Am Dienstag, 13. Februar 2018 17:18 schrieb Johannes Kapune:

...

kann es sein dass die FritzBox den NTP-Server im Netzwerk macht?

Im Menue: Heimnetz - Netzwerk - Zeitsynchronisation

Kann es sein, dass der Provider das blockt? Seite ich Glasfaser über Helinet habe, muss ich deren NTP-Server nutzen; jeder andere ist nicht erreichbar. -- Gruß Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Burnicki

15:54

Am 14.02.2018 um 11:02 schrieb Marcus Roeckrath:

...

Hallo Johannes,

Am Dienstag, 13. Februar 2018 17:18 schrieb Johannes Kapune:

...
kann es sein dass die FritzBox den NTP-Server im Netzwerk macht?

Im Menue: Heimnetz - Netzwerk - Zeitsynchronisation

Kann es sein, dass der Provider das blockt?

Seite ich Glasfaser über Helinet habe, muss ich deren NTP-Server nutzen; jeder andere ist nicht erreichbar.

Wow, das ist ja übel! Von so einer Einschränkung habe ich bisher noch nie gehört, außer vielleicht in manchen Hotels, wo nur bestimmte Ports für die Gäste freigegeben sind und z.B. VPN/SSH nicht funktioniert. Aber dein Internetprovider? Schreibt der dir auch vor, welche webseiten du besuchen darfst?!?! Unglaublich! Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Marcus Roeckrath

22:44

Hallo Martin, Am Mittwoch, 14. Februar 2018 16:54 schrieb Martin Burnicki:

...

...
Kann es sein, dass der Provider das blockt?

Seite ich Glasfaser über Helinet habe, muss ich deren NTP-Server nutzen; jeder andere ist nicht erreichbar.

Wow, das ist ja übel!

Von so einer Einschränkung habe ich bisher noch nie gehört, außer vielleicht in manchen Hotels, wo nur bestimmte Ports für die Gäste freigegeben sind und z.B. VPN/SSH nicht funktioniert.

Aber dein Internetprovider? Schreibt der dir auch vor, welche webseiten du besuchen darfst?!?!

Nein, ansonsten gibt es keinerlei Sperren oder ähnliches. Mir fiel es irgendwann nach dem Wechsel von der Telekom zu Helinet auf, dass die im fli4l-Router eingetragenen NTP-Quellen nicht synchronisierten und hatte dann den Provider diesbezüglich angefragt, der das dann auch sofort bestätigte.

...

Unglaublich!

Wenn die jetzt schon in den USA gefallene Netzneutralität auch hier nicht mehr gilt, kommen noch ganz andere Zeiten auf uns zu - die Politiker nennen das dann Digitaloffensive - also es wird offensiv teuer. -- Gruß Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Burnicki

13 Feb 13 Feb

21:49

Am 13.02.2018 um 13:31 schrieb dirk:

...

Sorry, die Firewall auf dem Router funktioniert mit den Standardeinstellungen schon seit Jahren problemlos. Auch mit dem NTP. Habe aber nochmal jetzt die Firewall auf dem Router und die Firewall auf dem PC deaktiviert. Es hat sich leider nichts verbessert. In Yast kann ich ja die eingestellten Zeitserver testen. Bei allen erhalte ich die Antwort dass die Server laufen und korrekt antworten.

Habe jetz mit meinem Laptop direkt an der Fritzbox die Zeit synchronisieren können. Direkt am router nicht. Auch mit deaktivierter Firewall nicht.

Muss demnach irgendwie mit der Umstellung von Cisco Modem auf FB zu tun haben.

Nach meinen Erahrungen mit der Fritzbox gibt es damit kein Problem, wenn man die Standardeinstellungen verwendet. Die Fritzbox kann sich mit einem Pool-Server synchronisieren und dann als NTP-Server fürs lokale Netz fungieren, aber sie läßt auch NTP-Pakete an externe Server rein und raus. Ich bin mir allerdings nicht sicher, ob das auch im "Gastnetz" funktioniert, wenn man dort Portbeschränkungen ("Filter" in der Fritzbox) aktiviert hat. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Schröder

12 Feb 12 Feb

22:37

Am 12. Februar 2018 um 21:08 schrieb dirk :

...

# rcntpd restart bash: rcntpd: Kommando nicht gefunden.

man systemctl :-)

...

# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000

Was sagt sudo nmap -P0 -sU -p123 213.251.52.43 ? Ich tippe darauf, daß Dein Firewall ntp blockt. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

dirk

22:57

Am 12.02.2018 23:37, schrieb Martin Schröder:

...

Am 12. Februar 2018 um 21:08 schrieb dirk :

...
# rcntpd restart bash: rcntpd: Kommando nicht gefunden.

man systemctl :-)

...
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000

Was sagt sudo nmap -P0 -sU -p123 213.251.52.43 ?

Ich tippe darauf, daß Dein Firewall ntp blockt.

Gruß Martin

# nmap -P0 -sU -p123 213.251.52.43 Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2018-02-12 23:59 CET Nmap scan report for 213.251.52.43 Host is up (0.033s latency). PORT STATE SERVICE 123/udp open ntp Nmap done: 1 IP address (1 host up) scanned in 0.24 seconds -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

dirk

23:16

Am 12.02.2018 23:37, schrieb Martin Schröder:

...

Am 12. Februar 2018 um 21:08 schrieb dirk :

...
# rcntpd restart bash: rcntpd: Kommando nicht gefunden.

man systemctl :-)

...
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 213.251.52.43 .INIT. 16 u - 64 0 0.000 0.000

Was sagt sudo nmap -P0 -sU -p123 213.251.52.43 ?

Ich tippe darauf, daß Dein Firewall ntp blockt.

Gruß Martin

Firewall hmmm? Ich habe einen Unitymedia Anschluss mit einer Fritzbox Cable an die ein Bintec Router als exposed host angeschlossen ist. Und diese Fritzbox hat erst vor Kurzem ein Cisco Modem abgelöst, was mit einem erneuten Start des Internetassistenten auf dem Bintec Router verbunden war. Auf dem Bintec ist auch eine Firewall aktiviert. Allerdings sind dort nur die Standardregeln aktiv. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

David Haller

13 Feb 13 Feb

11:29

Hallo, Am Mon, 12 Feb 2018, Martin Burnicki schrieb:

...

Am 12.02.2018 um 15:47 schrieb dirk: [..] Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist.

Läuft systemd-timedated? -dnh --

...

Als Newbie möchte ich wissen ob man unter Linux Vieren befürchten muß? Rein statisch gesehen, ist die Wahrscheinlichkeit, unter Linux von einer Vier erwischt zu werden, nicht größer, als eine Null verpaßt zu bekommen. -- Christoph Lorentz in dcoulm! -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Martin Burnicki

15 Feb 15 Feb

21:50

Am 13.02.2018 um 12:29 schrieb David Haller:

...

Hallo,

Am Mon, 12 Feb 2018, Martin Burnicki schrieb:

...
Am 12.02.2018 um 15:47 schrieb dirk: [..] Falls ja, könnte es sein, dass UDP-Port 123 durch die Firewall blockiert ist.

Läuft systemd-timedated?

Hm, ich habe bisher keine Erfahrung mit systemd-timedated. Wenn der auch auf UDP Port 123 lauschen möchte, sollte es einen Konflikt geben mit ntpd: 1.) Wenn erst ntpd startet und danach timedated, hat ntpd Port 123 geöffnet und sollte normal mit seine Upstream-Servern kommunizieren können. Wenn danach timedated startet es den Port nicht mehr öffnen. 2.) Wenn erst timedated startet und Port 123 verwendet, und danach ntpd gestartet wird, kann ntpd den Port nicht mehr öffnen und beendet sich sofoert wieder mit einer entsprechenden Fehlermeldung im Syslog. 3.) Wenn timedated nicht den Port 123 verwendet, kann ntpd unabhängig von der Reihenfolge immer normal starten. Es gibt keinen Konflikt, es ist genau so als ob man bei laufendem ntpd ein "ntpdate -q" an einen Server absetzt, wobei ntpdate dann auch einen anderen Port verwendet. Natürlich könnte es allerdings zu einer instabilen Zeitsynchronisierung kommen, wenn ntpd die eine Korrektur anbringt und timedated eine andere. Da in diesem Problemfall ntpd ja läuft, aber lediglich nicht kommunizieren kann, gibt es nach meiner Erfahrung ein Problem mit einer Firewall, mit dem Routing generell, oder mit "restrict"-Zeilen in ntp.conf. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

2262

Age (days ago)

2265

Last active (days ago)

List overview

Download

21 comments

8 participants

participants (8)

David Haller
dirk
Handwerker, Jan (IMK)
Johannes Kapune
Marcus Roeckrath
Martin Burnicki
Martin Schröder
Peter Mulller

NTP funktioniert nicht

tags

participants (8)