Hallo Tobias Becker, vielen Dank für die Anteilnahme an meinem Zeit-Problem! On Sat, 5 Jun 2004, Tobias Becker wrote:

* Sigward Funke schrieb:

...

Jun 3 17:35:39 dolly isdnlog: Everything is fine, isdnlog-4.59 is running in full featured mode. Jun 3 17:35:53 dolly isdnlog: (HiSax driver detected) ^^^^^^^^^^^^^^^^^^^^^^^ Die letzte Zeile ist die erste Antwort auf eine ausgehende Verbindung.

Da sollten eigentlich Meldungen über den Verbindungsaufbau stehen, sofern Du diese nicht ausdrücklich wegkonfiguriert hast.

Gut, zwischen die isdnlog-Meldungen mischen sich tatsächlich noch zahlreiche Kernel-Meldungen, die ich jedoch für unverdächtig halte. Später finde ich bisher unbekannte Meldungen mit "No HW description found" - hilft das vielleicht weiter? Noch zur Erläuterung: Ich habe fünf ISDN-Devices konfiguriert (icll, igunz, ineub, itann und iwerd), die beim Starten des ISDN-Systems alle erstmal eine Verbindung aufbauen wollen, was aber nur für die ersten beiden klappt (logisch, wenn nur eine ISDN-Karte vorhanden ist). Hier ein lückenloser Auszug aus /var/log/messages: Jun 3 17:35:39 dolly isdnlog: Everything is fine, isdnlog-4.59 is running in full featured mode. Jun 3 17:35:53 dolly kernel: icll: dialing 1 003435xxxxxx... Jun 3 17:35:53 dolly isdnlog: (HiSax driver detected) Jun 3 17:35:53 dolly isdnlog: Jun 03 17:35:53 * tei 66 calling +49 3435/xxxxxx, Oschatz with +49 341/97xMSNx, Leipzig RING (Data) Jun 3 17:35:53 dolly kernel: igunz: dialing 1 0037464xxxxxx... Jun 3 17:35:53 dolly isdnlog: Jun 03 17:35:53 * tei 66 calling +49 37464/xxxxxx, Schöneck with +49 341/97xMSNx, Leipzig RING (Data) Jun 3 17:35:53 dolly kernel: isdn_net: itann: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:35:54 dolly kernel: isdn_net: iwerd: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:35:54 dolly kernel: isdn_net: ineub: No channel, signalling dst_link_failure Protocol != ETH_P_IP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Das sind altbekannte Fehlermeldungen, vermutlich weil für itann, iwerd, ineub keine B-Kanäle frei ist. Jun 3 17:35:56 dolly kernel: isdn_net: icll connected Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling ? with ? CHARGING I 0.12 Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? COLP 11843 Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? CONNECT Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? No area info for provider 33_0 (18), destination xMSNx Jun 3 17:35:56 dolly kernel: isdn_net: igunz connected Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling ? with ? CHARGING I 0.12 Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? COLP 11843 Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? CONNECT Jun 3 17:35:56 dolly isdnlog: Jun 03 17:35:56 tei 66 calling xMSNx with ? No area info for provider 33_0 (18), destination xMSNx Jun 3 17:35:57 dolly kernel: isdn_net: itann: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:35:58 dolly kernel: isdn_net: iwerd: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:35:58 dolly kernel: isdn_net: ineub: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:36:00 dolly /USR/SBIN/CRON[14523]: (sysop) CMD (/home/sysop/bin/check_seiscomp check > /dev/null 2>&1) Jun 3 17:36:01 dolly /etc/hotplug/net.agent[14294]: No HW description found ... exiting ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Diese Fehlermeldung ist neu - könnte sie was mit isdnlog und der Zeitsynchronisierung zu tun haben? Jun 3 17:36:01 dolly kernel: isdn_net: itann: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:36:01 dolly /etc/hotplug/net.agent[14335]: No HW description found ... exiting Jun 3 17:36:02 dolly /etc/hotplug/net.agent[14376]: No HW description found ... exiting Jun 3 17:36:02 dolly kernel: isdn_net: iwerd: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:36:02 dolly /etc/hotplug/net.agent[14417]: No HW description found ... exiting Jun 3 17:36:02 dolly kernel: isdn_net: ineub: No channel, signalling dst_link_failure Protocol != ETH_P_IP Jun 3 17:36:02 dolly /etc/hotplug/net.agent[14458]: No HW description found ... exiting Jun 3 17:36:02 dolly kernel: icll: no IPv6 routers present Jun 3 17:36:02 dolly kernel: igunz: no IPv6 routers present Jun 3 17:36:02 dolly kernel: itann: no IPv6 routers present Jun 3 17:36:03 dolly kernel: iwerd: no IPv6 routers present Jun 3 17:36:03 dolly kernel: ineub: no IPv6 routers present Jun 3 17:36:06 dolly isdnlog: Jun 03 17:36:06 tei 66 calling xMSNx with ? Normal call clearing (User) Jun 3 17:36:06 dolly kernel: isdn_net: local hangup icll Jun 3 17:36:06 dolly kernel: icll: Chargesum is 0 Jun 3 17:36:06 dolly kernel: isdn: fcpcipnp0,ch0 cause: E0010 Jun 3 17:36:06 dolly isdnlog: Jun 03 17:36:06 tei 66 calling xMSNx with ? Normal call clearing (User) Jun 3 17:36:06 dolly isdnlog: Jun 03 17:36:06 tei 66 calling xMSNx with ? HANGUP ( 0:00:10) Jun 3 17:36:07 dolly isdnlog: Jun 03 17:36:07 tei 66 calling xMSNx with ? Normal call clearing (User) Jun 3 17:36:07 dolly kernel: isdn_net: local hangup igunz Jun 3 17:36:07 dolly kernel: igunz: Chargesum is 0 Jun 3 17:36:07 dolly kernel: isdn: fcpcipnp0,ch1 cause: E0010 Jun 3 17:36:07 dolly isdnlog: Jun 03 17:36:07 tei 66 calling xMSNx with ? Normal call clearing (User) Jun 3 17:36:07 dolly isdnlog: Jun 03 17:36:07 tei 66 calling xMSNx with ? HANGUP ( 0:00:11) Soweit der etwas längliche Auszug aus /var/log/messages. Beim Googlen nach "No HW description found" und isdn bin ich auch nicht viel schlauer geworden. Immerhin habe ich den Tip für ein i4l-Update gefunden - das nehme ich mir als Nächstes vor. Online ist die Version 2002.7.31 zu haben, installiert ist aktuell 2002.3.25-3.

Listet ein Aufruf von isdnrep die bereits am selben Tag getätigten Verbindungen auf?

Ja, sieht plausibel aus.

Falls nicht, ist mit gewisser Wahrscheinlichkeit die D-Kanal-Ausgabe nicht aktiviert, "hisaxctrl contr0 1 4" sollte dann helfen.

Hat sich ja wohl erübrigt. Nochmals vielen Dank, immerhin habe ich mit "No HW description found" eine neue Spur, auch wenn das Problem noch nicht gelöst ist. Sigward Funke -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15

Hallo Karsten Keil, On Mon, 7 Jun 2004, Karsten Keil wrote:

On Mon, Jun 07, 2004 at 12:41:30PM +0200, Sigward Funke wrote:

...

Gut, zwischen die isdnlog-Meldungen mischen sich tatsächlich noch zahlreiche Kernel-Meldungen, die ich jedoch für unverdächtig halte. Später finde ich bisher unbekannte Meldungen mit "No HW description found" - hilft das vielleicht weiter?

Hat nichts damit zu tun, bei jedem Netzwerk Device Statuschange wird ein Hotplugevent ausgeloest (kann man zu verschiedenen Zwecken nutzen, alternativ zu /etc/ppp/ip-up). Für dieses Event und diese HW gibt es keine Konfiguration, das ist der normal Fall.

Gut, wieder was dazugelernt. [...]

Damit das time setzen ueberhaupt funktionieren kann, muss die Anlage in der CONNECT Message auch die Zeit schicken, da das ein optionales Element ist, kann es sein das die Anlage das weglaesst.

mit log=3 in der isdnlog option Datei kannst Du alle messages der Karte nochmal nach /dev/isdnctrl0 schreiben lassen (zusaetzlich flush=yes empfohlen). Da kann ich oder andere Q931 kundige sehen ob die Zeit mitgeschickt wird oder nicht.

Nach Änderung der Konfiguration in dolly:/etc/isdn/isdnlog.options.contr0 findet sich in /tmp/isdnctrl0 folgendes Protokoll: Protokolliert wurde (meiner Ansicht nach) der Start des ISDN-Systems, erste automatische Verbindungen und eine (mehrfach wieder aufgenommene) manuelle Verbindung. Letztere war auf alle Fälle erfolgreich. Damit das Log etwas kürzer wird, habe ich die Zeilen nach der Zeitangabe geteilt und alle wiederholten Zeiten entfernt. Mon Jun 07 18:03:49 2004 53:31.21 debugging flags card 1 set to 4 Mon Jun 07 18:03:56 2004 53:38.12 tei State ST_TEI_NOP Event EV_IDREQ 53:38.12 tei assign request ri 39409 HEX: FC FF 03 0F 99 F1 01 FF 53:38.12 Card1 -> PH_DATA_REQ: UI[0]C (sapi 63, tei 127) 53:38.12 tei ChangeState ST_TEI_IDREQ HEX: FE FF 03 0F 99 F1 02 85 53:38.14 tei State ST_TEI_IDREQ Event EV_ASSIGN 53:38.14 tei identity assign ri 39409 tei 66 53:38.14 tei ChangeState ST_TEI_NOP HEX: 00 85 7F 53:38.14 Card1 -> PH_DATA_REQ: SABME[1]C (sapi 0, tei 66) HEX: 00 85 73 HEX: 00 85 00 00 08 01 01 05 A1 04 02 88 90 6C 07 01 80 31 31 38 34 33 70 0D 81 30 30 33 34 33 35 39 32 30 30 31 37 7C 02 88 90 53:38.15 Card1 -> PH_DATA_REQ: I[0](ns 0, nr 0)C (sapi 0, tei 66) HEX: 00 85 01 02 HEX: 00 85 02 00 08 01 02 05 A1 04 02 88 90 6C 07 01 80 31 31 38 34 33 70 0D 81 30 30 33 37 34 36 34 33 33 34 37 30 7C 02 88 90 53:38.23 Card1 -> PH_DATA_REQ: I[0](ns 1, nr 0)C (sapi 0, tei 66) HEX: 00 85 01 04 HEX: 02 85 00 04 08 01 81 02 18 01 89 HEX: 02 85 01 02 53:38.79 Card1 -> PH_DATA_REQ: RR[0](nr 1)R (sapi 0, tei 66) HEX: 02 85 02 04 08 01 82 02 18 01 8A HEX: 02 85 01 04 53:38.87 Card1 -> PH_DATA_REQ: RR[0](nr 2)R (sapi 0, tei 66) Mon Jun 07 18:03:58 2004 HEX: 02 85 04 04 08 01 81 07 28 14 43 48 41 52 47 49 4E 47 20 49 20 20 20 20 20 20 30 2E 31 32 4C 07 71 83 31 31 38 34 33 7C 02 88 90 HEX: 02 85 01 06 53:40.35 Card1 -> PH_DATA_REQ: RR[0](nr 3)R (sapi 0, tei 66) Mon Jun 07 18:03:59 2004 HEX: 02 85 06 04 08 01 82 07 28 14 43 48 41 52 47 49 4E 47 20 49 20 20 20 20 20 20 30 2E 31 32 4C 07 71 83 31 31 38 34 33 7C 02 88 90 HEX: 02 85 01 08 53:41.15 Card1 -> PH_DATA_REQ: RR[0](nr 4)R (sapi 0, tei 66) Mon Jun 07 18:04:09 2004 HEX: 00 85 04 08 08 01 01 45 08 02 80 90 53:51.12 Card1 -> PH_DATA_REQ: I[0](ns 2, nr 4)C (sapi 0, tei 66) HEX: 00 85 01 06 HEX: 02 85 08 06 08 01 81 4D 08 02 80 90 HEX: 00 85 06 0A 08 01 01 5A 53:51.34 Card1 -> PH_DATA_REQ: I[0](ns 3, nr 5)C (sapi 0, tei 66) HEX: 00 85 01 08 Mon Jun 07 18:04:10 2004 HEX: 00 85 08 0A 08 01 02 45 08 02 80 90 53:52.12 Card1 -> PH_DATA_REQ: I[0](ns 4, nr 5)C (sapi 0, tei 66) HEX: 00 85 01 0A HEX: 02 85 0A 0A 08 01 82 4D 08 02 80 90 HEX: 00 85 0A 0C 08 01 02 5A 53:52.36 Card1 -> PH_DATA_REQ: I[0](ns 5, nr 6)C (sapi 0, tei 66) HEX: 00 85 01 0C HEX: 02 85 01 0D HEX: 02 85 01 0D Mon Jun 07 18:04:20 2004 54:02.39 Card1 -> PH_DATA_REQ: RR[1](nr 6)R (sapi 0, tei 66) HEX: 02 85 53 HEX: 02 85 73 54:02.46 Card1 -> PH_DATA_REQ: UA[1]R (sapi 0, tei 66) Mon Jun 07 18:06:19 2004 HEX: 00 85 7F 56:01.94 Card1 -> PH_DATA_REQ: SABME[1]C (sapi 0, tei 66) HEX: 00 85 73 HEX: 00 85 00 00 08 01 03 05 A1 04 02 88 90 6C 07 01 80 31 31 38 34 33 70 0E 81 30 30 33 37 34 36 35 34 30 39 38 32 31 7C 02 88 90 56:01.95 Card1 -> PH_DATA_REQ: I[0](ns 0, nr 0)C (sapi 0, tei 66) HEX: 00 85 01 02 Mon Jun 07 18:06:20 2004 HEX: 02 85 00 02 08 01 83 02 18 01 89 HEX: 02 85 01 02 56:02.56 Card1 -> PH_DATA_REQ: RR[0](nr 1)R (sapi 0, tei 66) Mon Jun 07 18:06:22 2004 HEX: 02 85 02 02 08 01 83 07 28 14 43 48 41 52 47 49 4E 47 20 49 20 20 20 20 20 20 30 2E 31 32 4C 07 71 83 31 31 38 34 33 7C 02 88 90 HEX: 02 85 01 04 56:05.05 Card1 -> PH_DATA_REQ: RR[0](nr 2)R (sapi 0, tei 66) Mon Jun 07 18:06:28 2004 HEX: 00 85 02 04 08 01 03 45 08 02 80 90 56:10.94 Card1 -> PH_DATA_REQ: I[0](ns 1, nr 2)C (sapi 0, tei 66) HEX: 00 85 01 04 Mon Jun 07 18:06:29 2004 HEX: 02 85 04 04 08 01 83 4D 08 02 80 90 HEX: 00 85 04 06 08 01 03 5A 56:11.17 Card1 -> PH_DATA_REQ: I[0](ns 2, nr 3)C (sapi 0, tei 66) HEX: 00 85 01 06 Mon Jun 07 18:06:30 2004 HEX: 00 85 06 06 08 01 04 05 A1 04 02 88 90 6C 07 01 80 31 31 38 34 33 70 0E 81 30 30 33 37 34 36 35 34 30 39 38 32 31 7C 02 88 90 56:12.42 Card1 -> PH_DATA_REQ: I[0](ns 3, nr 3)C (sapi 0, tei 66) HEX: 00 85 01 08 HEX: 02 85 06 08 08 01 84 02 18 01 89 HEX: 02 85 01 08 56:13.05 Card1 -> PH_DATA_REQ: RR[0](nr 4)R (sapi 0, tei 66) Mon Jun 07 18:06:33 2004 HEX: 02 85 08 08 08 01 84 07 28 14 43 48 41 52 47 49 4E 47 20 49 20 20 20 20 20 20 30 2E 31 32 4C 07 71 83 31 31 38 34 33 7C 02 88 90 HEX: 02 85 01 0A 56:15.35 Card1 -> PH_DATA_REQ: RR[0](nr 5)R (sapi 0, tei 66) Mon Jun 07 18:06:43 2004 HEX: 00 85 01 0B 56:25.35 Card1 -> PH_DATA_REQ: RR[1](nr 5)C (sapi 0, tei 66) HEX: 00 85 01 09 Mon Jun 07 18:06:45 2004 HEX: 00 85 08 0A 08 01 04 45 08 02 80 90 56:27.42 Card1 -> PH_DATA_REQ: I[0](ns 4, nr 5)C (sapi 0, tei 66) HEX: 00 85 01 0A HEX: 02 85 0A 0A 08 01 84 4D 08 02 80 90 HEX: 00 85 0A 0C 08 01 04 5A 56:27.64 Card1 -> PH_DATA_REQ: I[0](ns 5, nr 6)C (sapi 0, tei 66) HEX: 00 85 01 0C Mon Jun 07 18:06:55 2004 HEX: 02 85 01 0D HEX: 02 85 01 0D 56:37.67 Card1 -> PH_DATA_REQ: RR[1](nr 6)R (sapi 0, tei 66) HEX: 02 85 53 HEX: 02 85 73 56:37.78 Card1 -> PH_DATA_REQ: UA[1]R (sapi 0, tei 66) Ich bin ja gespannt, ob in diesen Zeilen was Brauchbares zu finden ist! Mit isdnrep finde ich in dieser Zeit folgende Verbindungen, was auch meinen Erwartungen entspricht: 18:03:58 0:00:10 ? -> xMSNx 0.0000 EUR 18:03:59 0:00:10 ? -> xMSNx 0.0000 EUR 18:06:22 0:00:07 +4934197xMSNx -> xMSNx 0.0000 EUR 18:06:33 0:00:12 +4934197xMSNx -> xMSNx 0.0000 EUR 18:12:03 0:01:23 +4934197xMSNx -> xMSNx 0.0000 EUR 18:22:03 0:00:41 +4934197xMSNx -> xMSNx 0.0000 EUR Gruß Sigward Funke -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15

Hallo Tobias Becker, vielen Dank für die Unterstützung! On Mon, 7 Jun 2004, Tobias Becker wrote:

Ich hab mir einmal die erste CONNECT-Meldung herausgegriffen und der Einfachheit halber an den ISDN-Webdecoder (http://www.engelschall.com/~martin/webdecoder/webdecoder.cgi) verfüttert. Dies ist das Ergebnis:

[...]

(Die % stammen von mir.) Die Zeit wird -- wie schon in Erwägung gezogen -- nicht mit übertragen.

Schade! Wie wäre es an einem "normalen" ISDN-Anschluss der Telekom? Sollte dort die Zeit innerhalb der CONNECT-Meldung in jedem Fall übertragen werden oder könnte das auch dort eine optionale Leistung sein? Wird die gesuchte Datum/Zeit-Information eigentlich nur in der CONNECT-Meldung übertragen? Dann könnte nur der anrufende Rechner synchronisiert werden. Ich hätte die Zeit besonders dringend im angerufenen Rechner - gibt es da nicht noch eine Meldung CONNECT ACKNOWLEDGE? An einer "kleinen" ISDN-Nebenstellenanlage wird das Ganze vermutlich auch nicht einfacher? Obiger Test (von mir gelöscht) kam an der "großen" Telefonanlage der Uni zustande, die zunächst _keine_ ISDN-Anlage ist. Mittels eines sogen. Multimedia-Adapters soll aber ein vollwertiger ISDN-Aschluss entstehen. Immerhin kann ich alle fünf Linux-Rechner, die in der Ferne stehen, reibungslos per ISDN anwählen. Nur die Zeitinformation bekomme ich nicht heraus.

Das würde z. B. so aussehen:

...

| 02 000000-- Sapi = 0 | ------1- C/R: Command | -------0 Extension Bit = with extension | 93 1001001- TEI = 73 | -------1 Extension Bit = no extension | 04 0000010- N(S) = 2 | -------0 I-Frame | 18 0001100- N(R) = 12 | -------0 P/F = 0 | 08 00001000 ProtocolDiscriminator DSS1 | 01 00000001 Length of CallReference = 1 | 82 1------- CallRef-Flag: Destination Side | -0000010 CallReference = 2 | 07 00000111 MSG-Type: CONNECT | 1E 00011110 I-Element: Progress Indicator | 02 00000010 Length = 2 | 82 1------- Extension Bit = no extension | -00----- Coding Standard: CCITT | ---0---- Spare | ----0010 Location: public network serving local user | 82 1------- Extension Bit = no extension | -0000010 Progress Description: destination address is non-ISDN | 29 00101001 I-Element: Date/Time | 05 00000101 Length = 5 | 03 00000011 Year: 03 | 02 00000010 Month: 02 | 17 00010111 Day: 23 | 0A 00001010 Hour: 10 | 22 00100010 Minute: 34

Heißt das, dass die Uhrzeit nur auf die Minute genau gestellt werden kann?

...

| 4C 01001100 I-Element: Connected Number | 02 00000010 Length = 2 | 00 0------- Extension Bit = with extension | -000---- Type of Number: unknown | ----0000 Numbering Plan: unknown | A3 1------- Extension Bit = no extension | -01----- Presentation Indicator: presentation restricted | ---000-- Spare | ------11 Screening Indicator: network provided

Ist die Reihenfolge der I-Elemente eingentlich festgelegt? Oder: Muss das I-Element "Date/Time" vor "Connected Number" kommen? Nun habe ich aber erst mal genug gefragt. Vielen Dank für die Geduld! Sigward Funke -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15

Hallo Tobias, nun weiß ich ziemlich genau Bescheid - vielen Dank, auch an Karsten Keil. Offensichtlich scheitert mein Plan an prinzipiellen Hürden! On Wed, 9 Jun 2004, Tobias Becker wrote:

* Sigward Funke schrieb:

...

Wird die gesuchte Datum/Zeit-Information eigentlich nur in der CONNECT-Meldung übertragen?

Das entsprechende Informationselement ist nur für diese Meldung und nur in der Richtung network -> user, also nur zum anrufenden Teilnehmer, im Standard (ETS 300 403-1 als Ergänzung zu ITU Q.931) vorgesehen. Für den angerufenen Rechner ist mir keine vergleichbare Lösung im üblichen ISDN bekannt.

An meiner gegenwärtigen Installation ist es eine wichtige Einzelheit, dass die Rechner im Gelände bisher keine Verbindungen aufbauen, damit dort keine Gebühren anfallen. Für die gewünschte Zeitsynchronisierung müßte ich also die Feldrechner irgendwo anrufen lassen.

Eine, zugegebenermaßen aufwendigere, Alternative könnte in SNTP (Simple Network Time Protocol, RFC 2030) über bestehende IP-Verbindungen darstellen.

Daran habe ich auch schon gedacht. Da ich aber RAW-IP für den Verbindungsaufbau nutze und nur private IP-Nummern verwende, kann der Rechner im Gelände nicht so leicht einen Zeitserver erreichen.

Technisch dürfte die Anlage nicht allzuweit von ISDN entfernt sein, digitale Endgeräte (Systemtelefone) werden allerdings in der Regel nur zwei- statt vieradrig angeschaltet. Der Adapter dürfte in etwa das Pendant zum NTBA am normalen ISDN-Anschluss sein.

Das sagen die Fernmeldetechniker der Uni auch.

[...]

...

Heißt das, dass die Uhrzeit nur auf die Minute genau gestellt werden kann?

Das hängt von der Vermittlungsstelle ab, bei Length = 6 würden am Ende die Sekunden folgen, die Dt. Telekom macht davon nach meinen Beobachtungen keinen Gebrauch.

Wenn es ohne großen Aufwand funktionieren würde, könnte ich damit leben.

[...]

Gruß Sigward -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15

Hallo Karsten Keil, vielen Dank (auch an Tobias Becker), nun weiß ich, dass ich eine andere Lösung suchen muss. On Wed, 9 Jun 2004, Karsten Keil wrote:

On Wed, Jun 09, 2004 at 05:29:15PM +0200, Sigward Funke wrote:

[...]

...

Datum/Zeit-Information eigentlich nur in der CONNECT-Meldung übertragen? Dann könnte nur der anrufende Rechner synchronisiert werden. Ich hätte die Zeit besonders dringend im angerufenen Rechner - gibt es da nicht noch eine Meldung CONNECT ACKNOWLEDGE?

Da gibt es das Element garnicht. Es ist nur beim CONNECT vorgesehen, wahrscheinlich mit dem Hintergrund die gebührenpflichtigen Beginn zu dokumentieren.

Irgendwie plausibel, aber schade für mich.

...

An einer "kleinen" ISDN-Nebenstellenanlage wird das Ganze vermutlich auch nicht einfacher?

Meistens schon, die sind oft naeher an der ETSI und leiten meist Messages einfach durch.

Dann müßte ich mich von meinem Grundsatz trennen, dass die Rechner im Gelände nur angerufen werden und nicht selbst wählen dürfen. Das wirft meine bisherige Gebührenabrechnung über den Haufen.

Besser einen Zentralen Zeitserver aufsetzen und im ip-up script syncronisieren, ist bedeutend genauer.

Das ist vermutlich das Mittel der Wahl: Auf meinem Datenzentrumsrechner (permanent im Internet) setze ich einen Zeitserver auf. Dann muss ich nur noch den Rechnern im Gelände beibringen, dass sie sich bei bestehender Verbindung (über RAW-IP, Verbindung wird vom Datenzentrumsrechner aufgebaut, nur private IP-Nummern) mit dem Zeitserver auf dem Datenzentrumsrechner synchronisieren. Leider habe ich wegen RAW-IP kein ip-up script. Vielleicht hat ja jemand eine Idee, wo ich ein passendes Kochrezept finde?

Funkuhren für Bastler mit den man das machen kann gibt es für wenige Euros.

Daran habe ich auch schon gedacht. Bisher wollte ich mir aber keine zusätzliche Hardware anschaffen.

...

Heißt das, dass die Uhrzeit nur auf die Minute genau gestellt werden kann?

Genau. Das Element selbst kennt zwar auch Sekunden, aber die sind auch optional und ich habe soetwas noch nicht gesehen.

Wenn alles andere reibungslos klappen würde, könnte ich vielleicht damit leben. Gruß Sigward Funke -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15