Freetz 1.1.4 & OpenNTPD: ntpd synchronisiert nicht automatisch

TIK

Neuer User
Mitglied seit
14 Mrz 2011
Beiträge
64
Punkte für Reaktionen
0
Punkte
6
eigentlich hab ich 2 probleme mit dem ntpd:
  1. nach dem (neu)start der box synchronisiert er die zeit nicht automatisch. wenn ich den daemon dann manuell restarte, wird die zeit auf der box sofort synchronisiert. logs gibts keine im fehlerfall...
  2. clients können sich nicht mit dem ntp-server auf der box synchronisieren (WinXP, Suse, Ubuntu). an den clients liegt es nicht, mit xntp als server auf der Suse-kiste läuft alles wie es soll.
    jetzt kommt das kuriose:
    mit ntpdate oder ntpq unter linux bekomm ich keine antwort von der fritzbox. mit den "NTP Server Tool" unter windows aber schon (siehe anhang). windows synchronisiert die zeit aber trotzdem nicht und quittiert dies mit einem fehler.
bei beiden sachen bin ich ratlos. hat jemand eine idee?
Fritzbox 3170, Freetz 1.1.4 mit Firmware 49.04.58
 

Anhänge

  • ntp_query.jpg
    ntp_query.jpg
    37.1 KB · Aufrufe: 47
Ich meine es gab da ein Problem, wenn der ntpd gestartet ist bevor die Internetverbindung da ist. Du kannst als workaround ein restart über die rc.custom probieren. Im trunk kann man das über external services lösen.

Gruß
Oliver
 
Ich meine es gab da ein Problem, wenn der ntpd gestartet ist bevor die Internetverbindung da ist.
aha danke. hast du noch eine idee zum debuggen von problem 2? ohne eine lösung dafür macht der ntpd wenig sinn...

sieht wohl so aus, als ob ich dochmal den trunk probieren sollte oder als alternative ne Alien-firmware mit chronyd. fungiert der dort auch als server oder nur als client?
 
chronyd kann auch server. Aber den gibts nur für die x2xx und x3xx Boxen.

Ich kenn mich mit ntpd nicht aus, daher kann ich da nichts zu sagen.

Gruß
Oliver
 
beides mal "oh, schade".. trotzdem dank dir!
 
ich hab mich mal in das thema "reingelesen". punkt 2 war mein fehler:
ntpdate auf den linux-rechnern liefert doch ein reply
Server dropped: Leap not in sync
es ist also genau das verhalten, was von anderen usern schon beschrieben wurde: lange sync-zeit, dann gehts

letztendlich sind die von mir erwähnten probleme gar keine sondern eigenheiten von OpenNTPD.
gefällt mir so nicht. ich werd da mal hand anlegen...
 
das benutze ich. habe mir mal den source angeschaut. die OpenNTPD philosophie ist:
sobald der prozess von der shell entkoppelt wird und als daemon läuft, wird die zeit nur "schleichend" mittels adjtime() korrigiert. das kann dauern... ausserdem setzt die option -s die zeit nur auf +/-3min genau.

was ich möchte:
die fritzbox soll nach einem powerloss möglichst zeitnah eine einheitliche zeit dem privaten netz zur verfügung stellen. die philosophie der "schleichenden" zeitanpassung teile ich nicht ;)

wirft man die schleichende synchronisierung der uhr über board ist die zeit bereits nach 80s "in sync" und die clients erhalten eine stabile zeit (getestet mit stratum1 server ptbtime1.ptb.de).
 
Zuletzt bearbeitet:
wie ich schon erwähnt hatte, wollte ich mir das ganze mal anschaun. ist ein wenig mehr draus geworden...
habe jetzt mal noch ein readme fertig gemacht, damit es auch für andere sinnvoll nutzbar ist.

patch.readme:
Code:
openntpd-3.9p1 extension patch
******************************

Preface:
The OpenNTPD philosophy is to slightly adjust the local clock until it's synced (see adjtime()). This method is intended to be used to make small adjustments to the system time.
The only exception is option '-s'. OpenNTPD is allowed to make huge adjustments to the system time (see settimeofday()) at startup.

Syncing the clock:
OpenNTPD maintains a trust level for each peer. On every successful query the level is increased. After 8 queries a peer is ready to sync the clock. If all valid peers are ready the clock gets adjusted.


New features:

Command line option '-w'
Waiting for the first response from any NTP server and set time similar to option '-s'. Use either '-S', '-s' or '-w'.
Note: This option violates OpenNTPD philosophy because time is set from daemonized state using settimeofday().

Config option 'sync at'
This option is intended for dialup connections to sync with NTP servers on time.
Note1: If last query exceeds 30 minutes OpenNTPD will query this particular NTP server until it is ready to sync the clock. Normally this procedure takes about 150s.
Note2: This option violates OpenNTPD philosophy because time is immediately set using settimeofday().

Config option 'sync at randomize'
Are there problems when simultaneously query all NTP servers, this option can be used. A randomized offset (max. 90s) is added to each 'sync at'.

Config option 'sync every'
This option replaces the original behavior of adjusting the time. OpenNTPD usually queries all NTP servers every 5 minutes. Now a custom query interval is supported. A randomized offset (max. 90s) is added.
Note1: If last query exceeds 30 minutes OpenNTPD will query this particular NTP server until it is ready to sync the clock. Normally this procedure takes about 150s.
Note2: Similar to original behaviour intervals will drift. You cannot assume that all NTP servers sync at nearly the same time.
Note3: This option violates OpenNTPD philosophy because time is immediately set using settimeofday().

Config option 'error retry'
This option is intended for speeding up the retry on network error and for limiting the error retry on dialup connections. A randomized offset (max. 90s) is added to each delay. The original behavior is to retry every 10 minutes.


Bug fixes:

- Some network errors do not decrease trust level. Such a peer will block the clock sync.
- Errors if command line option '-s' specified:
  * All log messages from child process get lost.
  * If current time is future a peer may not sync as expected. This peer will block the clock sync.

so find ich den zeit server (fast) perfekt...
 

Anhänge

  • openntpd-3.9p1_ext_patch.tgz
    12.1 KB · Aufrufe: 18
  • openntpd-3.9p1_ext_patch_freetz.tgz
    10.5 KB · Aufrufe: 9
Zuletzt bearbeitet:
Kann man openntpd nach deinem Patch noch mit den gleichen Optionen wie vorher betreiben? Ändert sich dann was am Verhalten? Kannst du mal bitte "size ntpd" mit und ohne deinen Patch posten.

Gruß
Oliver
 
Kann man openntpd nach deinem Patch noch mit den gleichen Optionen wie vorher betreiben? Ändert sich dann was am Verhalten?
bis auf die bug fixes und die etwas bessere darstellung von offsets im log ("23d 11h 8m 34.234s" statt "2027314.234000s" ) ist das verhalten ohne die zusätzlichen optionen identisch.

zum laufzeitverhalten:
die option "sync at" hat theoretischen einfluss auf die performance. definiert man hier z.b. 10000 zeiten in der config, wird bei jedem sync mit einem NTP server eine liste mit 10000 einträgen im worst-case 1x komplett durchlaufen. das passiert aber höchsten alle 5s je server und ist damit wohl auch auf dem schmalen prozessor nicht spürbar. man spürt hier eher was beim parsen einer solch grossen unrealistischen config.

zur binary grösse:
Code:
   text	   data	    bss	    dec	    hex	filename
  51895	   1140	   2384	  55419	   d87b	ntpd
  58098	   1216	   2400	  61714	   f112	ntpd.patched
das ganze unter Freetz 1.1.4. hab gesehn, das das original binary im trunk nochmal 10k kleiner ist.
da ich mit der toolchain kein compression ratio bei sqashfs angezeigt bekomme, hab ich die binaries mal mit UPX gepackt, um ein gefühl zu bekommen.
Code:
ntpd_upx          27352
ntpd_upx.patched  30304
eher vernachlässigbar, finde ich...
 
Zuletzt bearbeitet:
irgendwie scheint's beim Portable OpenNTPD nicht mehr weiter zu gehn, was die portierung angeht. jetzt ich habe mir mal die aktuelle version von openNTPD angeschaut und muss sagen, da sind schone einige sinnvolle änderungen drin. auch hier hat sich in letzter zeit nicht mehr viel getan, somit der richtige zeitpunkt für eine portierung:
  • wo kommt euer openntpd-3.9p1 source her? in der offiziellen 3.9p1 ist das einlesen des driftfiles nicht enthalten und auch nicht der spezielle linux-port zum korrigieren der RTC frequenz.
  • nutzt überhaupt jemand noch den ntpd auf Freetz?
 
Die driftfiles kommen über einen Patch.
ah, danke! ich hatte gestern lange weile und hab mal den ntpd auf den aktuellen OpenBSD CVS stand (4.9) gepatcht. das korrigieren der RTC frequenz sowie die modifikationen vom obigen patch fehlen noch...
 

Anhänge

  • log.zip
    12.7 KB · Aufrufe: 3
Magst du dein Patch mit uns teilen?

Gruß
Oliver
 
ja klar. ich mag nur keine halbfertige sachen ;)
stehe grad noch mit den BSD leuten in kontakt wegen bugs bzw. ungereimtheiten, lade aber heut abend mal ne version hier hoch...
 
anbei die noch nicht fertige version. sie entspricht OpenNTPD4.9 (plus bugfixes) ohne sensor-support. doku, beispiel-config und configure-script sind noch auf dem stand von 3.9p1. nach dem configure-lauf sind deshalb für Freetz noch modifikationen an der config.h vorzunehmen:
Code:
/* Define to 1 if you have the `clock_gettime' function. */
#define HAVE_CLOCK_GETTIME 1

/* Define to 1 if you have the `clock_settime' function. */
#define HAVE_CLOCK_SETTIME 1

/* Define to 1 if you have the `CLOCK_MONOTONIC' define. */
#define HAVE_CLOCK_MONOTONIC 1

/* Signal for status report (default is SIGINFO if available) */
#define NTPD_SIG_REPORT SIGUSR1

die im Freetz-SVN vorhandenen patches für 3.9p1 sind überflüssig

edit: um missverständnisse zu vermeiden, wurde die testversion im anhang entfernt. die "finale" gibts hier
 
Zuletzt bearbeitet:
Ich hab deinen Patch probiert und es kompiliert immerhin schonmal.

Driftfile ist drin. Aber warum wird der adjtimex Patch nicht mehr benötigt?

Ich hab noch probiert das configure script zu erweitern:
Code:
--- configure   2006-05-14 07:31:37.000000000 +0200
+++ configure   2011-06-22 09:43:16.000000000 +0200
@@ -3965,6 +3965,9 @@
        asprintf \
        bzero \
        clock_getres \
+       clock_gettime \
+       clock_settime \
+       clock_monotonic \
        daemon \
        errx \
        getifaddrs \
@@ -9369,6 +9372,10 @@
.
 fi
.
+# Comment?
+cat >>confdefs.h <<_ACEOF
+#define NTPD_SIG_REPORT SIGUSR1
+_ACEOF
.
.
 # Check whether --with-privsep-user or --without-privsep-user was given.
clock_monotonic lässt sich so leider nicht checken, da fehlt wohl ein include. Die anderen 2 Checks funktionieren. SIG_REPORT müsste man noch sauberer implementieren.

Gruß
Oliver
 
Driftfile ist drin. Aber warum wird der adjtimex Patch nicht mehr benötigt?
ich glaub seit v4.0 beherrscht OpenNTPD das korrigieren der RTC frequenz. im bsd-compat code der portable 3.9 wurde bereits adjtimex() genutzt. d.h. die frequenz korrektur ist jetzt auf allen platformen verfügbar, die adjtimex() unterstützen. für die restlichen müsste das noch implementiert werden. der Linux-port ist deshalb überflüssig...

Ich hab noch probiert das configure script zu erweitern:
danke! da Linux nicht "mein zuhause" ist und ich mich noch nicht näher mit dem autoconf-mechanismus befasst habe, benötige ich später nochmal deine/eure hilfe

SIG_REPORT müsste man noch sauberer implementieren.
das mit dem SIGUSR1 war nur so ein vorschlag. den SIGINFO-mechanismus gibts ja so nicht überall. mein vorschlag hier:
das signal dem configure-script als parameter reinreichen und es per default "undefined" lassen
 
hier mal noch die grösse der aktuellen version:
Code:
   text	   data	    bss	    dec	    hex	filename
  63409	   1272	   2460	  67141	  10645	ntpd

eine sache fehlt aber noch:
im NTP protokoll gibts eine RefID. diese 32bit-ID soll einen server eindeutig kennzeichnen, um loopbacks zu vermeiden. bei einem IPV4 server ist das normalerweise die ip adresse, bei IPV6 servern muss man sich was einfallen lassen...
OpenNTPD nutzt hier einfach den MD5 hash der V6 adresse.
ich kann nicht zwangsweise davon ausgehn, das open-ssl in jeder compiler-umgebung vorhanden ist. es sollte daher für den fallback ein MD5-code mit embedded werden. beim "stöbern" in Freetz ist mir aufgefallen, das hier einige applikationen unterschiedliche varianten mitbringen.

hat hier jemand schon mal erfahrungen gesammelt, welche implementierung von der code-grösse optimal ist? performance ist unwichtig...

hier der code-schnipsel, um den es sich handelt:
Code:
MD5_CTX		context;
u_int8_t	digest[MD5_DIGEST_LENGTH];

MD5Init(&context);
MD5Update(&context, ((struct sockaddr_in6 *)&p->addr->ss)->
		sin6_addr.s6_addr, sizeof(struct in6_addr));
MD5Final(digest, &context);
memcpy((char *)&p->reply[p->shift].status.send_refid, digest,
		sizeof(u_int32_t));
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.