ntpd - peer not valid

P

PaulAtreides

Well-Known Member
Warum funktioniert die Abfrage für ntpd nicht? Bei der Statusabfrage über ntpctl erhalte ich für alle Server peer not valid

ntpctl -s all
0/5 peers valid, constraint offset 2s, clock unsynced

peer
wt tl st next poll offset delay jitter
162.159.200.1 time.cloudflare.com
1 2 - 277s 300s ---- peer not valid ----
45.131.109.21 from pool pool.ntp.org
1 2 - 0s 0s ---- peer not valid ----
85.214.96.5 from pool pool.ntp.org
1 2 - 0s 0s ---- peer not valid ----
172.104.134.72 from pool pool.ntp.org
1 2 - 0s 0s ---- peer not valid ----
85.214.46.39 from pool pool.ntp.org
1 2 - 0s 0s ---- peer not valid ----
Zum Vergrößern anklicken....

rdate - Die Abfrage funktioniert
rdate -nvp pool.ntp.org
Fri Mar 3 10:40:49 CET 2023
rdate: adjust local clock by 3.243805 seconds
Zum Vergrößern anklicken....

ntpd.conf
listen on 127.0.0.1
listen on 192.168.176.2

query from 192.168.176.2

servers pool.ntp.org
server time.cloudflare.com
sensor *

constraint from "9.9.9.9" # quad9 v4 without DNS
constraint from "2620:fe::fe" # quad9 v6 without DNS
constraints from "www.google.com" # intentionally not 8.8.8.8
Zum Vergrößern anklicken....
 
Gestern und heute habe ich den Daemon neu gestartet. Ich weiß nicht, ob es vorher funktioniert hat.
Ich habe das Problem entdeckt, weil die Abfrage der Clients im Netzwerk nicht funktioniert.
 
PaulAtreides schrieb:
Ich habe das Problem entdeckt, weil die Abfrage der Clients im Netzwerk nicht funktioniert.
Zum Vergrößern anklicken....
Wie ist die Ausgabe von:
Code: 
netstat -na -f inet | grep -i 123
?
BTW: Wenn bzw. so lang "clock unsynced" ist, funktioniert die Abfrage nicht:
rdate: Ignoring NTP server with alarm flag set
rdate: Unable to get a reasonable time estimate
Zum Vergrößern anklicken....
EDIT:

Versuch mal (als temporärer Test) auch mit:
Code: 
listen on *
in der "/etc/ntpd.conf"-Datei.
 
netstat -na -f inet | grep -i 123
udp 0 0 192.168.176.2.7115 217.115.11.162.123
udp 0 0 192.168.176.2.1961 81.169.199.94.123
udp 0 0 192.168.176.2.21270 144.76.0.164.123
udp 0 0 192.168.176.2.38262 185.242.112.53.123
udp 0 0 192.168.176.2.123 .
udp 0 0 127.0.0.1.123 .
Zum Vergrößern anklicken....

Wenn ich immer wieder "ntpctl -s all" abfrage kommt kurzzeitig
162.159.200.1 time.cloudflare.com
1 2 - 225s 300s ---- peer not valid ----
not resolved from pool pool.ntp.org
1 2 - 300s 300s ---- peer not valid ----
not resolved from pool pool.ntp.org
1 2 - 300s 300s ---- peer not valid ----
not resolved from pool pool.ntp.org
1 2 - 300s 300s ---- peer not valid ----
not resolved from pool pool.ntp.org
1 2 - 300s 300s ---- peer not valid ----
Zum Vergrößern anklicken....
 
Falls es zum Debuggen hilft, Minimalconfig am DNS vorbei direkt mit nur einer einzelnen IP in der conf würde ich mal versuchen. Ich bekam eben diese zurück:
Code: 
mr44er@ws01:~ $ host pool.ntp.org
pool.ntp.org has address 90.187.112.137
pool.ntp.org has address 185.183.159.238
pool.ntp.org has address 88.99.76.254
pool.ntp.org has address 194.25.134.196
mr44er@ws01:~ $ host time.cloudflare.com
time.cloudflare.com has address 162.159.200.123
time.cloudflare.com has address 162.159.200.1
time.cloudflare.com has IPv6 address 2606:4700:f1::123
time.cloudflare.com has IPv6 address 2606:4700:f1::1
 
Ok, vermutlich andere Anforderungen, aber bei mir funktioniert es mit den default settings:

Code: 
# ntpctl -s all
5/5 peers valid, constraint offset -1s, clock synced, stratum 3

peer
   wt tl st  next  poll          offset       delay      jitter
162.159.200.1 time.cloudflare.com
    1 10  3  932s  956s        -2.270ms    11.746ms     0.094ms
49.12.125.53 from pool pool.ntp.org
    1 10  2  597s  976s         0.838ms     0.458ms     0.141ms
213.206.165.21 from pool pool.ntp.org
    1 10  2  355s  965s       -25.622ms     8.094ms     0.351ms
188.68.36.203 from pool pool.ntp.org
 *  1 10  2  356s 1011s         0.829ms     2.930ms     0.141ms
176.9.44.212 from pool pool.ntp.org
    1 10  2  958s  965s         0.829ms     0.492ms     0.072ms
Code: 
# rdate -nvp pool.ntp.org
Fri Mar  3 16:49:08 CET 2023
rdate: adjust local clock by -0.025578 seconds
Code: 
# cat /etc/ntpd.conf
servers pool.ntp.org
server time.cloudflare.com
sensor *

constraint from "9.9.9.9"              # quad9 v4 without DNS
constraint from "2620:fe::fe"          # quad9 v6 without DNS
constraints from "www.google.com"      # intentionally not 8.8.8.8
 
Ich würde mal, wie auch schon geschrieben, mit ner minimalen ntpd.conf anfangen. Also nur den ntp Pool verwenden, die Constraints auskommentieren und den Sensor (obwohl du vermutlich eh keinen hast).

Dann mal 2-3 h laufen lassen und gucken. Wenn die Server danach nicht validiert sind eventuell mal gucken ob es am Netzwerk liegt. Also testen ob du per udp auf Port 123 der Server kommst.

Testen könntest du erstmal per netcat

Code: 
printf c%47s | nc -uw1 162.159.200.1 123

Solltest du binary Zeug als Antwort bekommen z.b. Die IP ist vom Cloudflare Timeserver.


Wenn du irgendwann die Schnauze voll hast vom guten alten ntpd, kann ich btw. nur den chronyd empfehlen. Ich hab schon länger alles darauf umgestellt :)
 
Andy_m4 schrieb:
Ja. Dem kann ich mich nur anschließen. chronyd macht ruhig und unauffällig seinen Job. Sowohl als Service als auch im reinen Client-Mode. Wobei ich jetzt auf Schlag gar nicht weiß, ob das für OpenBSD überhaupt verfügbar ist.
Zum Vergrößern anklicken....
hust ich hab leider mal wieder nicht geguckt in welchem Forum ich unterwegs bin :D Das weiß ich leider auch nicht, für FreeBSD ist er verfügbar.
 
host pool.ntp.org
pool.ntp.org has address 176.9.42.91
pool.ntp.org has address 129.70.132.34
pool.ntp.org has address 217.197.91.176
pool.ntp.org has address 144.76.43.40
Zum Vergrößern anklicken....

Ja, Firewall ist aktiv, jedoch habe ich
pf.conf
pass from (self)
Zum Vergrößern anklicken....

Funktioniert auch
printf c%47s | nc -uw1 162.159.200.1 123
Zum Vergrößern anklicken....

Was mir aufgefallen ist. Egal wie oft ich "rdate -nvp pool.ntp.org" aufrufe. Er sagt immer, dass die Zeit um ca. 3.27 Sekunden angepasst wird

rdate: adjust local clock by 3.272235 seconds
rdate: adjust local clock by 3.271026 seconds
rdate: adjust local clock by 3.271142 seconds
Zum Vergrößern anklicken....
 
Mhmm vielleicht ist die lokale Uhr defekt? Eventuell müsste man dann einstellen, dass der Kernel diese ignoriert, da kenne ich mich aber nicht aus bei OpenBSD. Ev. könntest du das ja mit nem Livestick von einem anderen System (z.b. Linux) testen?
 
Nein, ist ein SuperMicro Intel Atom von Thomas Krenn

Man sollte auch das -p aus entfernen .. sonst wird das nix
Also Zeit stimmt, aber ntpd arbeitet immer noch nicht
 
medV2 schrieb:
Mhmm vielleicht ist die lokale Uhr defekt?
Zum Vergrößern anklicken....
Der ntpd funktioniert auch ohne lokale Uhr. Z. B. bei den RaspberryPIs.

EDIT:

@TE: Statt servers (pool) könntest Du auch einzelne server mit der IP, in die ntpd.conf eintragen:
Code: 
server 176.9.42.91
server 129.70.132.34
und nach dem restart von ntpd, mit tcpdump schauen ob Traffic (zu den Zeit-Servern) zum syncen, statt findet.
 
Zuletzt bearbeitet:
Ein paar Überlegungen:

Hast du neben OpenNTPD vielleicht auch ntpd (aus dem ntp package) am laufen? (wäre xntpd als service/rc .d script)

Hast du mal probiert die constraints rauszunehmen bwz. mit einer minimalen Konfiguration zu beginnen, wie medV2 umd mr44er meinten?

Wie lange hast du ntpd am Stück laufen lassen? (ohne mit rdate reinzufunken, etc.)

EDIT: Oh, ich sehe gerade du verwendest ohnehin -p.

PaulAtreides schrieb:
Egal wie oft ich "rdate -nvp pool.ntp.org" aufrufe. Er sagt immer, dass die Zeit um ca. 3.27 Sekunden angepasst wird
Zum Vergrößern anklicken....

Das ist klar, denn -p setzt laut Manual die Zeit nicht.
 
Hast Du evtl. Flags für ntpd gesetzt?
Wie sind die Ausgaben von:
Code: 
cat /etc/rc.conf.local | grep -i ntpd
cat /etc/rc.conf | grep -i ntpd
rcctl check ntpd
ps aux | grep -i ntpd
dmesg -s | grep -i ntpd
ls -la /var/run/ntpd.sock
ls -la /var/db/ntpd.drift
?
 
BTW: Auch bei einem "clock synced" mit ntpd, wird rdate mit "-p" richtigerweise immer (verschiedene) Werte für "adjust local clock by "###" seconds" zeigen. rdate soll ja hier und in diesem Fall, nur als tool zum testen der Verbindung zu den Zeitservern dienen bzw. benutzt werden (und nicht zum setzen/aktualisieren der Zeit).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben