Christoph Emsenhuber
5cc62b29c1
Der Core hatte keinen eigenen NTP-Client bei use-local-clock=no. Ein Server ohne Synchronisation liefert Stratum 16, das jeder Client verwirft -- die Anfragen kamen an und wurden trotzdem nicht brauchbar beantwortet. Der Standort hatte an keiner Stelle eine funktionierende Zeitsynchronisation. Notiert ist auch, dass /system ntp gar keine Compliance-Rule hat -- derselbe blinde Fleck, den TP26 fuer /ip firewall filter geschlossen hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
10 lines
616 B
Plaintext
10 lines
616 B
Plaintext
# NTP-Client auf dem AP neu anstossen.
|
|
#
|
|
# Beide APs zeigen seit jeher auf 10.40.99.1 und standen deshalb dauerhaft auf
|
|
# `status: waiting`. Ein Client, der lange erfolglos war, verlaengert seine
|
|
# Wartezeit — er merkt also nicht von selbst zeitnah, dass der Core seit
|
|
# 2026-08-18 tatsaechlich Zeit liefert. Aus/ein setzt den Zustand zurueck.
|
|
:do { /system ntp client set enabled=no } on-error={ :log info "tp19ntp: ap-off warf" }
|
|
:do { /system ntp client set enabled=yes servers=10.40.99.1 } on-error={ :log info "tp19ntp: ap-on warf" }
|
|
:log info ("tp19ntp: ap-client status=" . [/system ntp client get status])
|