Openntpd setzt die Zeit nicht richtig

Meine client.c sieht aber mal ne ganze Ecke anders aus:

Code:
        T4 = getoffset();
        if ((size = recvmsg(p->query->fd, &somsg, 0)) == -1) {
                if (errno == EHOSTUNREACH || errno == EHOSTDOWN ||
                    errno == ENETUNREACH || errno == ENETDOWN ||
                    errno == ECONNREFUSED || errno == EADDRNOTAVAIL ||
                    errno == ENOPROTOOPT || errno == ENOENT) {
                        client_log_error(p, "recvmsg", errno);
                        set_next(p, error_interval());
                        return (0);
                } else
                        fatal("recvfrom");
        }

        if (somsg.msg_flags & MSG_TRUNC) {
                client_log_error(p, "recvmsg packet", EMSGSIZE);
                set_next(p, error_interval());
                return (0);
        }

        if (somsg.msg_flags & MSG_CTRUNC) {
                client_log_error(p, "recvmsg control data", E2BIG);
                set_next(p, error_interval());
                return (0);
        }

        for (cmsg = CMSG_FIRSTHDR(&somsg); cmsg != NULL;
            cmsg = CMSG_NXTHDR(&somsg, cmsg)) {
                if (cmsg->cmsg_level == SOL_SOCKET &&
                    cmsg->cmsg_type == SCM_TIMESTAMP) {
                        memcpy(&tv, CMSG_DATA(cmsg), sizeof(tv));
                        T4 += tv.tv_sec + JAN_1970 + 1.0e-6 * tv.tv_usec;
                        break;
                }
        }

        if (T4 < JAN_1970) {
                client_log_error(p, "recvmsg control format", EBADF);
                set_next(p, error_interval());
                return (0);
        }

Liegt da evtl. das Problem?
 
habs jetzt mal eingefügt und neu kompiliert - mal schaun.

wenn auch das nicht hilft. stoppe mal openntp, schalte alle komponenten deiner box aus, welche die zeit aktualisieren (chrony, multid) und dann starte openntpd aus der console mit
Code:
ntpd -s -v -f /mod/etc/ntpd.conf

Code:
 ntpd -s -v -f /var/tmp/flash/openntpd/ntpd.conf
sollte es aber glaube ich eher heissen, denn das andere conf file gibts nicht und da steht meine config drin. Erzeugt aber 0 output...

Edit:

Die zeilen sehen aber immer noch anders aus als bei TIK.

Im übrigen im "alten" Log gefunden ohne T4 anpassung nur mit der Änderung in der config.h

Code:
Aug 15 13:55:08 fritz daemon.info ntpd[7122]: adjusting local clock by -2563.965875s
Aug 15 13:55:08 fritz daemon.crit ntpd[7122]: adjtime failed: Invalid argument
Aug 15 13:58:19 fritz daemon.info ntpd[7122]: adjusting local clock by -2564.524743s
Aug 15 13:58:19 fritz daemon.crit ntpd[7122]: adjtime failed: Invalid argument
Aug 15 11:58:58 fritz daemon.info ntpd[7120]: peer 192.53.103.108 now valid
 
Zuletzt bearbeitet:
Ich denke nicht, dass adjtime für so große Änderungen gedacht ist. Aus "man adjtime":
adjtime() is intended to be used to make small adjustments to the system time. Most systems impose a limit on the adjustment that can be specified in delta. In the glibc implementation, delta must be less than or equal to (INT_MAX / 1000000 - 2) and greater than or equal to (INT_MIN / 1000000 + 2) (respectively 2145 and -2145 seconds on x86).
 
Das war ja auch nach 3 oder 4 Tagen uptime... Die Uhr geht innerhalb von 10 Minuten nach dem openntpd start (und damit dem ersten sync) 2,1 Sekunden falsch - aber es wird vom openntpd immer nur angezeigt wieviel zeitunterschied ist - die uhr aber nicht korrigiert. Und dann war der Unterschied einfach zu groß

Edit:
Also nach 20 Stunden uptime geht die uhr schon gut falsch:

Code:
Aug 16 18:09:13 fritz daemon.debug ntpd[6216]: reply from 192.53.103.104: offset -254.832129 delay 0.015960, next query 31s
 
Zuletzt bearbeitet:
Also nach 20 Stunden uptime geht die uhr schon gut falsch
heisst das jetzt, das deine uhr auch ohne ntpd extrem driftet? wenn ja, dann könnte ich es so erklären:
openntpd korrigiert die RTC frequenz erst, wenn sich die zeit (mittels adjtime()) stabilisiert hat. das passiert bei dir nie... dein clock drift scheint für adjtime() zu gross zu sein, um hier selbst kurzfristig stabilität zu bekommen.

das problem könntest du dann (temporär) lösen, indem du manuell ein driftfile erstellst.
 
Zuletzt bearbeitet:
Hmm, aber sollte ntp das driftfile nicht von alleine anlegen?
in der config eins anzugeben hat kein erfolg gebracht
 
das problem könntest du dann (temporär) lösen, indem du manuell ein driftfile erstellst.

du kannst in der openntpd config kein driftfile angeben. default ist /var/db/...

liesst du überhaupt die beiträge?

Ohja, lese ich. Und warum sagst du dann, dass ich das Problem temporär lösen könnte indem ich manuell ein driftfile erstelle und dann pampst, dass man es nicht kann?

Dann sollte openntp wieder auf die alte Version zurückgestuft werden. Damit hatte ich keine Probleme...
 
Du vielleicht nicht aber andere. Du kannst das Openntpd-"Update" auch lokal bei dir rückgänig machen.

Gruß
Oliver
 
Oliver: Das stimmt, aber wenn ich das richtig gelesen und im Kopf habe ist das update auf die neue Version doch nicht aus einem Bug raus entstanden sondern als bump der u.a. noch patches vermisst?
 
Ohja, lese ich. Und warum sagst du dann, dass ich das Problem temporär lösen könnte indem ich manuell ein driftfile erstelle und dann pampst, dass man es nicht kann?

das du in der ntpd.conf keine driftfile-geschichten konfigurieren kannst, heisst doch nicht, das der ntpd kein driftfile benutzt und du keins selbst anlegen kannst. und mit temporär meinte ich, das problem zu erörtern, indem du für deine clock-drift ein passendes driftfile anlegst.
nach einem reboot ist aber kein driftfile mehr vorhanden, von daher wäre es eine temporäre lösung...

und im übrigen:
wenn jemand mit einem trunk arbeitet, erwarte ich auch, dass er sich bei einem problem ein klein wenig hereinarbeitet. dazu gehört eben auch das aufmerksame lesen des threads. ich habe keine zeit und lust jedesmal "romane" zu schreiben, vorallem für sachen, die bereits geschrieben stehen...

dann fangen wir doch einfach mal ganz von vorn an:
  • alle zeit-sanchronisationsdienste ausschalten
  • "ps -ef" und dann den output hier posten
  • die zeit manuell stellen, die box 24h laufen lassen und dann die differenz posten. sekundengenau reicht hier...
 
- Wie bereits erwähnt, ich habe den Thread mehr als aufmerksam gelesen.
- "ps -ef" geht auf der box nicht da das busybox ps die optionen e und f nicht kennt aber den passenden output eigentlich bei nomalem ps schon auswirft.

Ich werd nochmal neuflashen ohne openntpd und dann mal schaun wie es aussieht. Wenns läuft bleibts halt draussen, scheint ja sonst bei den anderen Leuten zu laufen.

Topic is damit von meiner Seite aus erledigt, an der Stelle hab ich keine Lust mehr weiter zu forschen warum das openntpd nicht richtig funktioniert seit dem bump. Das Paket von TIK ist ja nun für mehrere Platformen gedacht oder zumindest lauffähig getestet. Mein Problem entspricht übrigens: http://freetz.org/ticket/1374 - da tritts wohl auch schon mit dem alten auf, ich vermute aber auch, dass in einer alten FW Version noch der AVM Client fleissig weiter die Zeit gesetzt hat was mittlerweile dann wohl nicht mehr ist und daher das Problem mit openntpd erst auffällt.
 
Ich werd nochmal neuflashen ohne openntpd und dann mal schaun wie es aussieht.

was soll das bringen? den dienst stoppen reicht doch völlig. geh doch mal ein wenig strukturiert vor, sonst forscht man halt ewig...

wie genau geht nun deine uhr?
bitte manuell messen und nicht mit einem nicht funktionierenden ntpd.
 
sie geht genau so ungenau wie mit nicht funktionierendem ntpd - unglaublich ungenau. Ich habe jetzt als Übergangslösung einen cron gebaut der ntpd alle 5 minuten neustartet da sonst auch die nachtschaltung etc... komplett aus dem tritt kommen. der multid ntp-client setzt die Zeit übrigens auch nicht auf der box, die driftet genauso weg.

Innerhalb von 2 Minuten ungefähr eine halbe Sekunde, in 5 Minuten etwas mehr als 1 Sekunde und in 10 minuten knapp 2,5 Sekunden. Entspricht den werten die von openntpd auch im log gepostet werden
 
du hast neu gebootet bzw. openntpd wurde vor dem messen noch nicht gestartet? das wäre wichtig...
ansonsten geht deine RTC um ca. 4166ppm falsch, das ist echt viel! zum vergleich meine 3170 -> 11ppm

leg mal ein driftfile (textdatei /var/db/ntpd.drift) mit folgendem inhalt an
Code:
4.166e-03
probier mal, ob das erfolg bringt. wenn deine uhr jetzt doppelt so falsch geht, musst du ein minus davor schreiben
 
Ohne openntpd und multid (bzw multid -t) geht meine Uhr weniger falsch... (ok, steht zwar auf 1970 und 01:00 - aber von da gemessen gab es in 12 minuten ca. eine sekunde abweichung) ein riesen Unterschied zu den ~2,5 Sekunden vorher.

Ich bastel mal das driftfile und schau mal wie es dann aussieht

Edit:
Egal ob - oder (+) - der Unterschied bleibt genauso wie ohne driftfile - ~2,5 Sekunden in 10 minuten
 
Zuletzt bearbeitet:
Egal ob - oder (+) - der Unterschied bleibt genauso wie ohne driftfile - ~2,5 Sekunden in 10 minuten

das kann nur sein, wenn ntpd dein driftfile nicht findet, du den ntpd mit zusatzoptionen compiliert hast (--disable-adjfreq etc.) oder ein fehler aufgetreten ist.
mit den genannten drift-offset muss deine uhr anders gehn...
openntpd loggt fehler beim einlesen des driftfiles nicht im syslog, sondern nach stdout/err. schau mal, ob du was im startlog oder direkt beim restart des dienstes findest...
 
keine zusatzoptionen beim kompilieren verwendet, ganz normal aus dem Trunk - nur mit deinen 2 Code Änderungen, ansonsten Standard.

Auf der konsole wirft er auch nicht mehr aus - auch mit -v nicht. Schau heute abend von zuhause aus nochmal was die Box so von sich gibt
 
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.