Hallo Liste, nutzt jemand die time-Option von isdnlog? Ich habe unter /etc/isdn/isdnlog.options.contr0 "time=0" manuell auf "time=1" gesetzt und die Rechneruhr wird trotzdem _nicht_ gestellt. Der Rechner wählt im 10-Minutentakt per RawIP erfolgreich einen anderen Linux-Rechner an; die restliche Kommunikation (Dateitransfer ...) klappt unverändert. Noch ein paar Angaben zum System: SuSE 8.0 und i4l 2002.3.25-3. Hardware Fritz!PCI v2.0 ISDN (rev 01). Muss ich bei der Telekom den Zeitdienst separat bestellen? Könnte die Nebenstellenanlage ein Problem verursachen? Gibt es weitere Parameter, die ich konfigurieren sollte? Nach dem Neustart des ISDN-Systems finde ich in /var/log/messages folgende Meldungen von isdnlog: Jun 3 17:35:39 dolly isdnlog: isdnlog Version 4.59 starting Jun 3 17:35:39 dolly isdnlog: Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat] Jun 3 17:35:39 dolly isdnlog: Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH Jun 3 17:35:39 dolly isdnlog: Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 Jun 3 17:35:39 dolly isdnlog: Rates Version 2.02 [29-Jun-2002 12:27:46] loaded [55 Providers, 413 Zones, 2009 Areas, 42 Services, 333 Comments, 0 eXceptions, 6 Redirects, 1302 Rates from /usr/lib/isdn/rate-de.dat] Jun 3 17:35:39 dolly isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) Jun 3 17:35:39 dolly isdnlog: isdn.conf:2 active channels, 2 MSN/SI entries Jun 3 17:35:39 dolly isdnlog: (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) 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. Warum kommt nicht einmal eine Fehlermeldung hinsichtlich der Zeitsynchronisation? Hoffentlich habe ich alle wichtigen Angaben beisammen! Ich bin für jeden Hinweis dankbar! 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
* Sigward Funke <sfunke@server1.rz.uni-leipzig.de> schrieb:
Da sollten eigentlich Meldungen über den Verbindungsaufbau stehen, sofern Du diese nicht ausdrücklich wegkonfiguriert hast. Listet ein Aufruf von isdnrep die bereits am selben Tag getätigten Verbindungen auf? Falls nicht, ist mit gewisser Wahrscheinlichkeit die D-Kanal-Ausgabe nicht aktiviert, "hisaxctrl contr0 1 4" sollte dann helfen. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *
Hallo Tobias Becker, vielen Dank für die Anteilnahme an meinem Zeit-Problem! On Sat, 5 Jun 2004, Tobias Becker 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? 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, On Mon, Jun 07, 2004 at 12:41:30PM +0200, Sigward Funke wrote:
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. 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. -- Karsten Keil SuSE Labs ISDN development
Hallo Karsten Keil, On Mon, 7 Jun 2004, Karsten Keil wrote:
Gut, wieder was dazugelernt. [...]
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
* Sigward Funke <sfunke@server1.rz.uni-leipzig.de> schrieb:
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. Das würde z. B. so aussehen:
Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *
Hallo Tobias Becker, vielen Dank für die Unterstützung! On Mon, 7 Jun 2004, Tobias Becker wrote:
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.
Heißt das, dass die Uhrzeit nur auf die Minute genau gestellt werden kann?
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
* Sigward Funke <sfunke@server1.rz.uni-leipzig.de> schrieb:
On Mon, 7 Jun 2004, Tobias Becker wrote:
Das läßt sich vielleicht mittels http://www.telekom.de/agb klären. Beim unten beobachteten Anschluß taucht aber kein entsprechendes Leistungsmerkmal in den Anschlußunterlagen auf, so daß man auf eine Standardleistung schließen könnte.
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. Eine, zugegebenermaßen aufwendigere, Alternative könnte in SNTP (Simple Network Time Protocol, RFC 2030) über bestehende IP-Verbindungen darstellen.
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. Der Hersteller/Verkäufer/Vermieter der Anlage sollte feststellen können, ob die Zeitübertragung an den anrufenden Rechner konfigurierbar ist oder nicht.
Das hängt ovon der Vermittlungsstelle ab, bei Length = 6 würden am Ende die Sekunden folgen, die Dt. Telekom macht davon nach meinen Beobachtungen keinen Gebrauch.
Ist die Reihenfolge der I-Elemente eingentlich festgelegt? Oder: Muss das I-Element "Date/Time" vor "Connected Number" kommen?
Sie müssen in aufsteigender Reihenfolge stehen, d. h. Date/Time (0x29) vor Connected Numer (0x4C). Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *
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:
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.
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.
Das sagen die Fernmeldetechniker der Uni auch.
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
On Wed, Jun 09, 2004 at 05:29:15PM +0200, Sigward Funke wrote:
Lt. ETSI und Q931 ist es halt kein "Mandatory Infomation Element", somit optional. Bisher haben aber alle Vermittlungsstellen die ich kenne, es übertragen, da damit auch die ISDN Telefone mit Zeit/Datum versorgt werden.
Da gibt es das Element garnicht. Es ist nur beim CONNECT vorgesehen, wahrscheinlich mit dem Hintergrund die gebührenpflichtigen Beginn zu dokumentieren.
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.
Besser einen Zentralen Zeitserver aufsetzen und im ip-up script syncronisieren, ist bedeutend genauer. Funkuhren für Bastler mit den man das machen kann gibt es für wenige Euros. Die ISDN Zeit wird nur mit Minuten uebertragen, damit hat man automatisch einen Fehler von bis zu 60 Sekunden.
Genau. Das Element selbst kennt zwar auch Sekunden, aber die sind auch optional und ich habe soetwas noch nicht gesehen.
Ja, der numerische Wert des IE legt die Reihenfolge fest, es gibt einige wenige Spezial IEs die eine Ausnahme sind.
-- Karsten Keil SuSE Labs ISDN development
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:
Irgendwie plausibel, aber schade für mich.
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.
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
Hallo, On Thu, Jun 10, 2004 at 11:03:55AM +0200, Sigward Funke wrote: ...
Haengt davon ab was so nach einem Verbindungsaufbau gemacht wird. Entweder der zentrale Server der die Rechner abfraegt startet einfach noch eine Zeitsyncronisation oder Du verwendest isdnlog um ein script zu starten sobald eine Verbindung hergestellt wurde.
Wenn der zentrale Rechner permanent Internet hat, ist das kein Problem, dann brauchst Du keine Funkuhr.
-- Karsten Keil SuSE Labs ISDN development
participants (3)
-
Karsten Keil
-
Sigward Funke
-
Tobias Becker