OpenNTPD auf ds-0.2.9-p8 vs. AVM-NTP für IP-Client

RalfFriedl schrieb:
kriegaex empfiehlt immer wieder mal einen Linux/Unix Einsteigerkurs. Ich habe den Link gerade nicht greifbar, aber wenn Du mal sowas siehst, solltest Du es Dir mal durchlesen.

Ich bin dabei mir diese Seite durchzulesen, aber das hier ist im Moment noch viel zu komplex, um es "mal eben so" hinzubekommen.


RalfFriedl schrieb:
Rufe im neuen ds-mod aus dem Basis-Verzeichnis "make openntpd-precompiled" auf. Das sollte die vorhin erstellt statische ntpd Datei und alles andere nach packages/openntpd-3.9p1 kopieren.
Kopiere dann das Verzeichnis packages/openntpd-3.9p1 vom neuen ds-mod nach addon/openntpd-3.9p1 im alten ds-mod und füge dann eine Zeile "openntpd-3.9p1" in der Datei addon/static.pkg ein. Dann sollte das komplette Paket in den alten ds-mod kommen.

Dies habe ich nun gemacht, die ntpd ist nun auch im flash vorhanden und ausführbar. Jedoch gibt es trotz dem Eintrag in die "static.pkg" keine Anzeige von OpenNTPD im ds-mod.
 
level20peon schrieb:
Dies habe ich nun gemacht, die ntpd ist nun auch im flash vorhanden und ausführbar. Jedoch gibt es trotz dem Eintrag in die "static.pkg" keine Anzeige von OpenNTPD im ds-mod.
Ich weiß nicht genau, was Du damit meinst, aber wenn OpenNTP im Flash drin ist, was willst Du mehr.

Funktioniert es jetzt?
 
Ich weiß nicht, ob es den anderen Lesern gefällt, daß Ihr hier OT über den DS-Mod redet. Wenn Ihr möchtet, kann ich die letzten Beiträge in einen Thread im DS-Mod-Forum verschieben. Soll ich?

Edit: Inzwischen befindet sich der gesamte Thread im DS-Mod-Forum, weil ich ihn nicht aufspalten wollte. Hoffentlich geht das in Ordnung.
 
Zuletzt bearbeitet:
RalfFriedl schrieb:
Der multid von AVM, der auch den NTP-Client enthält, denkt sich wohl, wenn er die Internet-Verbindung nicht selbst aufbaut, kann er auch keine NTP Synchronisation vornehmen.
Kann ich so nicht bestätigen. Ich betreibe meine FBF 7170 (FW ...37+ds-mod) auch als Client im LAN (hinter einer zweiten FRITZ!Box SL WLAN, die als NAT-Router fungiert). Aber bei mir wird die NTP-Einstellung in ar7.cfg offenbar vom multid honoriert; folgende Meldungen kommen beim Start des multid:

[...]
Aug 19 14:31:30 fritz7170 user.info multid[2076]: sending SNTP request to server 172.16.3.8 (172.16.3.8 )
[Anm: 172.16.3.8 ist mein eigener NTP-Server, den ich in ar7.cfg eingetragen habe]
Aug 19 14:31:30 fritz7170 user.info multid[2076]: The transfer time is assumed to be 0.007000 seconds
Aug 19 14:31:30 fritz7170 user.info multid[2076]: The NTP time is 19.8.2007 12:31:30.480000 UTC
Aug 19 14:31:30 fritz7170 user.info multid[2076]: system time is 0.053160 seconds behind
Aug 19 14:31:30 fritz7170 user.info multid[2076]: adjusting time forward 0.053160 seconds
[...]


@level20peon:

Hast Du den Hostnamen oder die IP-Adresse des NTP-Servers in ar7.cfg eingetragen? Denn einen Hostnamen muß die Box ja erst einmal auflösen können...
 
Genau genommen geht es hier von Anfang an darum, einer Box eine gültige Zeit zu verpassen und dazu openntpd auf den alten ds-mod anzupassen.

Vielleicht besser vorne ein Titel in der Art: "Wie bekomme ich OpenNTPD auf ds-0.2.9-p8, damit eine Box ohne Internetzugang auch eine gültige Zeit bekommt".

Oder meinst Du von "FRITZ!Box Fon: Modifikationen" nach "ds-mod"? Das würde natürlich besser passen. Kannst Du etwas hier herausnehmen?
 
Zuletzt bearbeitet:
RalfFriedl schrieb:
Ich weiß nicht genau, was Du damit meinst, aber wenn OpenNTP im Flash drin ist, was willst Du mehr.

Funktioniert es jetzt?

Nach dem Wiki Eintrag "Addon Paket installieren" Ich dachte, dass die statischen Pakete nun auch im ds-mod angezeigt werden. Auch per Aufruf von "http://IP_DER_BOX:81/cgi-bin/pkgconf.cgi?pkg=openntpd" ist das Paket nicht erreichbar. Wenn es normal ist, dass sie nicht angezeigt werden muss ich das OpenNTPD ja nun irgendwie extern starten.

Ich habe testweise einmal

Code:
echo "ntp:x:123:123::/mod/home/ntp:/bin/false" >> /var/tmp/passwd
mkdir -p /mod/home/ntp
chown root /mod/home/ntp
chmod 700 /mod/home/ntp
/var/mod/etc/default.openntpd/openntpd_conf
test -f /tmp/flash/openntpd_conf && /tmp/flash/openntpd_conf

eingegeben und dann versucht ntpd per

Code:
ntpd -d -s -f /mod/etc/ntpd.conf

zu starten. Die "ntpd.conf" ist aber nicht vorhanden. Also habe ich es mit "/etc/default.openntpd/openntpd.conf" und "/tmp/flash/openntpd_conf/openntpd.conf" versucht, auch ohne Erfolg. Ich blicke durch dieses Wirrwarr an Verzeichnissen nicht mehr durch glaube ich :noidea:


kriegaex schrieb:
Ich weiß nicht, ob es den anderen Lesern gefällt, daß Ihr hier OT über den DS-Mod redet. Wenn Ihr möchtet, kann ich die letzten Beiträge in einen Thread im DS-Mod-Forum verschieben. Soll ich?

Hallo kriegaex, das kannst du gerne machen, wenn du magst. Ich wusste beim Stellen meiner ersten Frage nicht so genau in welche Richtung das Ganze gehen würde.


gfuer schrieb:
Kann ich so nicht bestätigen. Ich betreibe meine FBF 7170 (FW ...37+ds-mod) auch als Client im LAN [...]

@level20peon:

Hast Du den Hostnamen oder die IP-Adresse des NTP-Servers in ar7.cfg eingetragen? Denn einen Hostnamen muß die Box ja erst einmal auflösen können...

Ich habe die IP-Adresse des lokalen NTP-Servers angegeben, die Box muss also nichts weiter auflösen.
 
Ich habe nicht 100%ig mitgelesen, aber ich nehme mal an, es sollte kein Problem sein, OpenNTPD für ds-0.2.9.-p8 zu bauen, wenn make toolchain vorher erfolgreich durchgelaufen ist, also die Toolchain in Ordnung ist.
 
@gfuer
Mein multid tut das nicht, auch nicht mit IP-Adresse. Ist aber der von der Telekom Firmware des W900V, mag sein, daß der schon etwas älter ist.

@level20peon
Dann erstelle erstmal die Konfigurationsdatei von Hand und schau, ob es damit geht.
Code:
# Konfigurationsdatei
echo "servers 192.168.X.Y" > /var/ntpd.conf
# Start
ntpd -d -s -f /var/ntpd.conf

@kriegaex
Vermutlich ist das Makefile nich 100% kompatibel zum alten ds-mod. Hat ja auch bisher niemand ausprobiert.
 
Ich habe die Konfigurationsdatei erstellt und ntpd erfolgreich gestartet. Jedoch synchronisiert der Dienst die Zeit nicht.

Auszug aus dem log:
(auf 192.168.0.17 läuft der OpenNTPD Server)
Code:
ntp engine ready
reply from 192.168.0.17: negative delay -0.000167
no reply in received in time, skipping initial time setting
reply from 192.168.0.17: offset 156035475.576286 delay 0.009825, next query 9s
reply from 192.168.0.17: negative delay -0.000176
reply from 192.168.0.17: offset 156035475.558589 delay 0.009826, next query 5s
reply from 192.168.0.17: negative delay -0.000176
reply from 192.168.0.17: negative delay -0.000176
reply from 192.168.0.17: offset 156035475.514776 delay 0.009824, next query 8s
reply from 192.168.0.17: negative delay -0.000177
reply from 192.168.0.17: negative delay -0.000177
peer 192.168.0.17 now valid
reply from 192.168.0.17: offset 156035475.393928 delay 0.009823, next query 5s
reply from 192.168.0.17: negative delay -0.000178

Ich habe den Dienst nun schon eine ganze Zeit lang laufen, da ich dachte, dass er vielleicht erst nach einer bestimmten Zeit synchronisiert, wie er es auf meiner anderen Box macht (siehe OpenNTPD thread), jedoch hat er die Zeit auch nach über einer Stunde noch nicht gesetzt, die Box befindet sich immer noch im Jahre 2002.
 
Ich vermute, es hat damit zu tun:
level20peon schrieb:
Code:
ntp engine ready
reply from 192.168.0.17: [B]negative delay[/B] -0.000167
[B]no reply in received in time, skipping initial time setting[/B]
reply from 192.168.0.17: offset 156035475.576286 delay 0.009825, next query 9s
Mir ist aber nicht klar, wie ein negatives Delay zustande kommen soll. Da müßte die Antwort ja empfangen werden, bevor die Anfrage gesendet wird.
 
Da ich keinen Quantentunnel als Netzwerk benutze, habe ich auch keine Ahnung wie dieser delay entsteht :D.

Also scheinbar gibt es keine Chance dass OpenNTPD bei mir vernünftig funktioniert, es scheint mich einfach nicht zu mögen (Es läuft auf der anderen Box ja auch nicht 100%ig).

Falls es also ausweglos ist, diesen Weg zu gehen, fällt jemandem zufällig ein, wie ich meinen Vorschlag weiter oben umsetzen könnte ?

Ausführung auf BOX_1 per cron:
Code:
date > /var/tmp/time.tmp
-wget -q -O - http://userassword@IP_BOX_2:81/cgi-bin/rudi_shellcmd.cgi?script=date /var/tmp/time.tmp (Zeit aus der /var/tmp/time.tmp übertragen)
rm /var/tmp/time.tmp
 
Schonmal die einfache Methode probiert?
Code:
/var/mod/root $ rdate -s time.fu-berlin.de
MfG Oliver

edit: Ups, hab ich überlesen. ;-)
 
Zuletzt bearbeitet:
@olistudent: Wie ich oben erwähnte kann diese Box nicht auf das Internet zugreifen. Das rdate funktioniert mit dem lokalen OpenNTPD Server leider nicht.
 
rdate versucht auf Port 37, time, zuzugreifen. Evtl. kann man den inetd in der Box 1 so konfigurieren, daß er diesen Dienst bereitstellt.
 
Negativer Delay - evtl. wieder mal eine Soft-Float-Seltsamkeit bzw. ein Rundungsfehler bei der Fließkomma-Emulation. Oliver, haben wir da alles glatt gezogen? Ich stecke in dem Thema nicht drin, aber irgendwo hakt es bestimmt noch, denn ich sehe ja auch in 15.2 keine Energiemonitor-Anzeigen, von denen ich nach wie vor annehme, daß sie damit auch zu tun haben.

Edit: Vielleicht ist der negative Delay auch anders zustande gekommen, das schließe ich nicht aus. Obiges ist Spekulation bzw. "educated guess", also schon begründet.
 
Also ich habe keinen negativen Delay und verwende vermutlich die gleiche Fließkomma-Emulation.

Unabhängig davon bin ich sehr interessiert an der Fließkomma-Emulation und deren eventuellen Problemen.
 
RalfFriedl schrieb:
rdate versucht auf Port 37, time, zuzugreifen. Evtl. kann man den inetd in der Box 1 so konfigurieren, daß er diesen Dienst bereitstellt.

Würde das überhaupt funktionieren, das time-protocol ist mit ntp doch gar nicht kompatibel oder ?



PS: Nach fast drei Stunden zeigte das log folgenden Eintrag:

Code:
adjusting local clock by 156035475.318948s
interval 0.000 skew 0.000 total skew 0.000
adjtime failed: invalid argument

Es scheint also noch mehr nicht zu funktionieren, als dass die Zeiten auf diese komische Weise divergieren.
 
Das time-Protokoll hat mit ntp nichts zu tun.
Der inetd der busybox kann jedoch so konfiguriert werden, daß er das time-Protokoll unterstützt.

Der Fehler mit adjtime ist sehr seltsam. Versuch mal, einen ds-mod ganz frisch anzufangen, vielleicht ist bei Dir etwas durcheinander gekommen.
 
RalfFriedl schrieb:
Das time-Protokoll hat mit ntp nichts zu tun.
Der inetd der busybox kann jedoch so konfiguriert werden, daß er das time-Protokoll unterstützt.

OK, du bist der Experte :D.


RalfFriedl schrieb:
Der Fehler mit adjtime ist sehr seltsam. Versuch mal, einen ds-mod ganz frisch anzufangen, vielleicht ist bei Dir etwas durcheinander gekommen.

Das habe ich ja gemacht. Ich habe sogar eine Firmware-recovery gemacht, bevor ich das Paket wieder aufgespielt habe.
Vielleicht hilft folgendes weiter:

Wenn ich manuell einmal per "date 082109592007" die Zeit einstelle erscheint
Code:
/ # telefon: set initial telefon time from linux time to 9:59 21.08. 2007!

Das klingt wenn ich in Windows-Begriffen denke, als wenn ein Dienst vorher nicht gestartet war, oder liege ich da falsch ?
 
Das bedeutet, daß der telefon Dienst gerne eine richtige Zeit hätte. Er weiß aber, daß das Datum 2000 nicht stimmen kann und daher ungültig ist. Er prüft aber regelmäßig die aktuelle Systemzeit, und wenn sie über einen bestimmten Wert geht, betrachtet er sie Systemzeit als gültig und zeigt das mit der genannten Meldung an.
Wenn Dich der genau Wert interessiert, kannst Du es mit dem date-Kommando ausprobieren.

Eine andere Möglichkeit, wie der telefon Dienst an die aktuelle Zeit kommen könnte ist über ein abgehendes ISDN-Gespräch. Oder es das tatsächlich tut, habe ich nicht ausprobiert.

Der telefon Dienst verhindert übrigens, daß man die Zeit zurückstellen kann.
 
Kostenlos!

Statistik des Forums

Themen
248,879
Beiträge
2,303,818
Mitglieder
378,547
Neuestes Mitglied
Kraehe82