Hallo, ich habe ein kleines Problem mit dem isdnlog unter SuSE 9.0 (Update von 8.2) (mit allen aktuellen Patches). Die Hardware ist eine Fritz PCI 2.0 an einer Telefonanlage, die nicht geupdatet wurde. Aus leidlicher Erfahrung habe ich die ISDN-Leitung durchgemessen, sie ist in Ordnung. Als Software ist neben den i4l-Paketen die capisuite installiert. Der Rechner wird als Router betrieben, ausser squid, hylafax und einer Firewall läuft sonst nichts. Nach ca. 2 Tagen Dauerbetrieb wird seit neustem keine kein ein- oder ausgehende Verbindung mit gelogt. Die Datei /var/log/isdn.log behält das alte Datum und die gleiche Größe. Auf der Platte sind noch 4 GByte Platz, ein Plattencheck hat keine Fehler gemeldet. Die Rechte der Log-Datei sind wie bei einer Neuinstallation. Auszug mittels isdnrep : Mon Nov 10 2003 07:30:15 0:02:03 +49657529 -> 019102345 0.0000 EUR 07:51:08 0:01:53 +49657529 -> 019102345 0.0000 EUR 07:59:49 0:05:49 +49657529 -> 019102345 0.0000 EUR 08:40:20 0:05:22 +49657529 -> 019102345 0.0000 EUR 09:00:03 0:03:00 +49657529 -> 019102345 0.0000 EUR 09:24:18 0:05:49 +49657529 -> 019102345 0.0000 EUR 10:44:18 0:02:08 +49657529 -> 019102345 0.0000 EUR 10:53:45 0:01:53 +49657529 -> 019102345 0.0000 EUR 11:00:02 0:04:15 +49657529 -> 019102345 0.0000 EUR 11:25:54 0:00:38 +49657529 <- +492472XXXX 11:26:38 0:01:55 +49657529 -> 019102345 0.0000 EUR 11:30:01 0:00:05 +49657527 <- +491704492XXX 11:31:00 0:01:54 +49657529 -> 019102345 0.0000 EUR danach nichts mehr. Vor dem ersten Auftretten wurden keine Traffic-Werte mehr aufgezeichent. Unter 8.? hatte ich das Problem schon einmal (aber nur 1 - 2 mal im Jahr), da hat ein Neustart das Problem behoben. Nach einem Neustart des Rechners werden zwar die Verbindung aufgezeichet, aber ohne bzw. mit seltsamen Trafficwerten. Siehe Auszug (vorne gekürzt): Thu Nov 13 2003 +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR I= 97.00 B O= 111.00 B +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 <- +4940528XXXXX [...] Nach 2 Tagen wird dann wieder garnichtsmehr geloggt. Ein rcisdn restart endet in einem Kernel-Panik. Und seit dem ersten Auftreten wird beim Aufruf einer externen Seite bei Neuanwahl die Seite nicht dargestellt. Ein zweiter Aufruf geht dann. Hat schon jemand das selbe Problem gehabt und eine Lösung gefunden? Wenn noch weitere Angaben benötigt werden stelle ich die gerne zur Verfügung. Für Eure Hilfe möchte ich mich schon im Voraus bedanken. Ich wünsche Euch noch eine Gute Nacht. Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dyndns.info http://www.trierer-single-treff.de http://www.Wetter-in-Landscheid.de -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB77 C153 7693 056E
* Jörg Frings-Fürst <JFF-Mailing@gmx.net> schrieb:
ich habe ein kleines Problem mit dem isdnlog unter SuSE 9.0 (Update von 8.2) (mit allen aktuellen Patches).
Die Hardware ist eine Fritz PCI 2.0 an einer Telefonanlage, die nicht geupdatet wurde. Aus leidlicher Erfahrung habe ich die ISDN-Leitung durchgemessen, sie ist in Ordnung.
Als Software ist neben den i4l-Paketen die capisuite installiert.
Der Rechner wird als Router betrieben, ausser squid, hylafax und einer Firewall läuft sonst nichts.
Nach ca. 2 Tagen Dauerbetrieb wird seit neustem keine kein ein- oder ausgehende Verbindung mit gelogt. Die Datei /var/log/isdn.log behält das alte Datum und die gleiche Größe.
Auf der Platte sind noch 4 GByte Platz, ein Plattencheck hat keine Fehler gemeldet.
Die Rechte der Log-Datei sind wie bei einer Neuinstallation.
Auszug mittels isdnrep :
Mon Nov 10 2003 07:30:15 0:02:03 +49657529 -> 019102345 0.0000 EUR 07:51:08 0:01:53 +49657529 -> 019102345 0.0000 EUR 07:59:49 0:05:49 +49657529 -> 019102345 0.0000 EUR 08:40:20 0:05:22 +49657529 -> 019102345 0.0000 EUR 09:00:03 0:03:00 +49657529 -> 019102345 0.0000 EUR 09:24:18 0:05:49 +49657529 -> 019102345 0.0000 EUR 10:44:18 0:02:08 +49657529 -> 019102345 0.0000 EUR 10:53:45 0:01:53 +49657529 -> 019102345 0.0000 EUR 11:00:02 0:04:15 +49657529 -> 019102345 0.0000 EUR 11:25:54 0:00:38 +49657529 <- +492472XXXX 11:26:38 0:01:55 +49657529 -> 019102345 0.0000 EUR 11:30:01 0:00:05 +49657527 <- +491704492XXX 11:31:00 0:01:54 +49657529 -> 019102345 0.0000 EUR
danach nichts mehr.
Vor dem ersten Auftretten wurden keine Traffic-Werte mehr aufgezeichent. Unter 8.? hatte ich das Problem schon einmal (aber nur 1 - 2 mal im Jahr), da hat ein Neustart das Problem behoben.
Nach einem Neustart des Rechners werden zwar die Verbindung aufgezeichet, aber ohne bzw. mit seltsamen Trafficwerten. Siehe Auszug (vorne gekürzt):
Thu Nov 13 2003 +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR I= 97.00 B O= 111.00 B +49657529 -> 019102345 0.0000 EUR +49657529 -> 019102345 0.0000 EUR +49657529 <- +4940528XXXXX [...]
Nach 2 Tagen wird dann wieder garnichtsmehr geloggt.
Ein rcisdn restart endet in einem Kernel-Panik.
Und seit dem ersten Auftreten wird beim Aufruf einer externen Seite bei Neuanwahl die Seite nicht dargestellt. Ein zweiter Aufruf geht dann.
"isdnlog stoppt logging nach längerer Zeit" kommt mir als Problem irgendwie bekannt vor, allerdings kann ich mich nicht an eine konkrete Lösung erinnern. Sofern das Problem alleine bei isdnlog liegt, sollte es sich für den Einzelfall durch ein manuelles 'kill -HUP' an isdnlog beheben lassen. Der letzte Absatz legt aber nahe, das die Probleme umfassender, d. h. in den ISDN-Treibern des Kernels zu suchen sein könnten. Die capisuite sollte kein Problem verursachen, da sie über das CAPI zugreift auf die Karte zugreift und die klassischen Schnittstellen in Ruhe läßt. /var/log/messages sollte weitere Informationen liefern. Soviel zur Wettervorhersage ... Konkret kann ich nur für isdnlog Hilfe anbieten und würde eventuell vorhandene Fehler gerne ausräumen. Dazu würde zunächst einmal gerne die vollständige Startmeldung von isdnlog sehen, üblicherweise in /var/log/messages zu finden, was dann z. B. so aussehen kann:
| isdnlog Version 4.67 starting | Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/local/lib/isdn/holiday-de.dat] | Dest V1.01: File '/usr/local/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE | Zone V1.25: Provider 0 File '/usr/local/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 | Rates Version 3.07 [08-Nov-2003 17:41:10] loaded [74 Providers, 771 Zones, 2687 Areas, 41 Services, 586 Comments, 13 eXceptions, 39 Redirects, 2343 Rates from /usr/local/lib/isdn/rate-de.dat] | (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) | isdn.conf:2 active channels, 8 MSN/SI entries | (watching "/dev/isdnctrl0" as HFC/echo mode) | (Data versions: iprofd=0x05 net_cfg=0x05 /dev/isdninfo=0x01) | Everything is fine, isdnlog-4.67 is running in full featured mode. | (HiSax driver detected) | Nov 14 22:34:55 * tei 66 calling ? with ? CHANNEL: BRI, B1 needed
Dann bleibt eigentlich nur noch die Möglichkeit, soviel Informationen wie möglich aufzuzeichnen, um nach neuerlichen Versagen etwas zur Analyse zu haben. Hierzu in der Parameterdatei des isdnlog, üblicherweise /etc/isdn/isdnlog.contr0.options die folgenden Zeilen ergänzen bzw. abändern: stdout=0x7fffffff outfile=+/var/log/isdnlog.debug log=15 flush=yes Nach dem schon erwähnten 'kill -HUP' kopiert isdnlog nun seine Eingangsdaten nach /tmp/isdnctrl0 und schreibt alle verfügbaren Ausgaben inklusive länglicher Debuginformationen nach /var/log/isdnlog.debug. Speicherplatz ist ja reichlich vorhanden. Tritt der Fehler nun wieder auf, beide Dateien sicherstellen und von die jeweils letzten Zeilen hier veröffentlichen. /tmp/isdnctrl0 kann dabei Rufnummern enthalten, als Ascii-Ziffern hexadezimal kodiert (30 und 39). Sollte das Problem auf andere Art abgestellt worden sein, würde ich das ebenfalls gerne lesen. 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 *
Dieses Problem kannte ich mit der AVM-Fritz-Karte ebenfalls. Die Karte hatte sich unter 8.x "einfach so" nach einer gewissen Zeit einfach "abgehängt". Deshalb bin ich nun auf die Sedlbauer SpeedFax+ umgestiegen. Kontrollier doch mal mit dmesg die Karte, wenn sie funzt bzw. im Vergleich wenn isdnlog nichts mehr aufzeichnet. Bei mir war die AVM dann ganz einfach "verschwunden".
Hallo Tobias, vielen Dank für Deine Hilfe. Leider war ich erst heute wieder an dem Rechner. Am Sonntag, 16. November 2003 00:30 schrieb Tobias Becker:
* Jörg Frings-Fürst <JFF-Mailing@gmx.net> schrieb:
ich habe ein kleines Problem mit dem isdnlog unter SuSE 9.0 (Update von 8.2) (mit allen aktuellen Patches).
[...]
"isdnlog stoppt logging nach längerer Zeit" kommt mir als Problem irgendwie bekannt vor, allerdings kann ich mich nicht an eine konkrete Lösung erinnern. Sofern das Problem alleine bei isdnlog liegt, sollte es sich für den Einzelfall durch ein manuelles 'kill -HUP' an isdnlog beheben lassen. Der letzte Absatz legt aber nahe, das die Probleme umfassender, d. h. in den ISDN-Treibern des Kernels zu suchen sein könnten. Die capisuite sollte kein Problem verursachen, da sie über das CAPI zugreift auf die Karte zugreift und die klassischen Schnittstellen in Ruhe läßt. /var/log/messages sollte weitere Informationen liefern. Soviel zur Wettervorhersage ...
Konkret kann ich nur für isdnlog Hilfe anbieten und würde eventuell vorhandene Fehler gerne ausräumen. Dazu würde zunächst einmal gerne die vollständige Startmeldung von isdnlog sehen, üblicherweise in
/var/log/messages zu finden, was dann z. B. so aussehen kann:
Hier die Einträge von mir : |isdnlog: isdnlog Version 4.65 starting |isdnlog: Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from / usr/lib/isdn/holiday-de.dat] |isdnlog: Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH |isdnlog: Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 |isdnlog: Rates Version 3.06 [07-Aug-2003 22:35:40] loaded [70 Providers, 738 Zones, 2667 Areas, 42 Services, 509 Comments, 13 eXceptions, 35 Redirects, 2091 Rates from /usr/lib/isdn/rate-de.dat] |isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) |isdnlog: isdn.conf:2 active channels, 2 MSN/SI entries |isdnlog: (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) |isdnlog: Everything is fine, isdnlog-4.65 is running in full featured mode. |isdnlog: (AVM B1 driver detected (D2)) [...]
Dann bleibt eigentlich nur noch die Möglichkeit, soviel Informationen wie möglich aufzuzeichnen, um nach neuerlichen Versagen etwas zur Analyse zu haben. Hierzu in der Parameterdatei des isdnlog, üblicherweise /etc/isdn/isdnlog.contr0.options die folgenden Zeilen ergänzen bzw. abändern:
stdout=0x7fffffff outfile=+/var/log/isdnlog.debug log=15 flush=yes
[...] Die Einträge habe ich gemacht. Jetzt muß nur noch der Fehler nochmal auftauchen. Wenn werde ich Auszüge davon mailen. Nochmals vielen Dank für Deine Mühen. Gruß Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dyndns.info http://www.trierer-single-treff.de http://www.Wetter-in-Landscheid.de -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB77 C153 7693 056E
* Jörg Frings-Fürst <JFF-Mailing@gmx.net> schrieb:
Hier die Einträge von mir : |isdnlog: isdnlog Version 4.65 starting |isdnlog: Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from / usr/lib/isdn/holiday-de.dat] |isdnlog: Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH |isdnlog: Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 |isdnlog: Rates Version 3.06 [07-Aug-2003 22:35:40] loaded [70 Providers, 738 Zones, 2667 Areas, 42 Services, 509 Comments, 13 eXceptions, 35 Redirects, 2091 Rates from /usr/lib/isdn/rate-de.dat] |isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) |isdnlog: isdn.conf:2 active channels, 2 MSN/SI entries |isdnlog: (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) |isdnlog: Everything is fine, isdnlog-4.65 is running in full featured mode. |isdnlog: (AVM B1 driver detected (D2))
Das ist soweit in Ordnung. Für ein besseres Verständnis der isdnlog-Geschichte meinerseits wäre es interresant zu wissen, welche isdnlog Version vor dem Update unter SuSE 8.2 lief, als der Fehler deutlich seltener auftrat.
[...] Die Einträge habe ich gemacht. Jetzt muß nur noch der Fehler nochmal auftauchen.
Anhand der mir in der Zwischenzeit zugesandten Logs konnte ich das Problem als bekannt identifizieren. Die Aufzeichnung stoppt, nachdem ein kommender Anruf zwar am internen S0-Bus signalisiert, dort ab nicht angenommen wird (20.49 Uhr, unbekannt an -27). Dieser "unbeantwortete ankommende Anruf" blockiert für die folgenden Verbindungen im isdnlog einen B-Kanal. Hierbei handelt es sich im Prinzip um das selbe Problem, das hier im August unter dem Subject "isdnlog & Handy" diskutiert wurde, siehe <hz.H53B17gF2mF@avalon.psi.talypso.de> bzw. http://lists.suse.com/archive/suse-isdn/2003-Aug/0104.html und vorhergehende Artikel. Die Lösung besteht darin, der Parameterdatei des isdnlog, /etc/isdn/isdnlog.contr0.options o. ä., den Eintrag dual=0x100 hinzufügen. Soweit ich es abschätzen kann, sollte im vorliegenden Fall der vorhandene isdnlog-4.65 ausreichen, da im Gegensatz zum zitierten Fall keine CALL PROCEEDING Nachricht auftaucht. Ist isdnlog an einer Telefonanlage angeschlossen, die wiederum über einen Anlagenanschluß am Telefonnetz angeschlossen ist, ist es überlegenswert, in /etc/isdn/isdn.conf als AREACODE nicht nur die eigene Vorwahl sondern zusätzlich die Kopfrufnummer des Anlagenanschlusses mitanzugeben, damit in der isdn.log vollständige Rufnummern erscheinen. Ich hoffe, zumindest der logging-bezogene Teil des Problems erledigt sich hiermit und würde in jedem Fall gerne über die Wirkung informiert werden. 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 *
Am Sonntag, 23. November 2003 16:07 schrieb Tobias Becker:
* Jörg Frings-Fürst <JFF-Mailing@gmx.net> schrieb:
Hier die Einträge von mir : [...]
Hierbei handelt es sich im Prinzip um das selbe Problem, das hier im August unter dem Subject "isdnlog & Handy" diskutiert wurde, siehe <hz.H53B17gF2mF@avalon.psi.talypso.de> bzw. http://lists.suse.com/archive/suse-isdn/2003-Aug/0104.html und vorhergehende Artikel.
Die Lösung besteht darin, der Parameterdatei des isdnlog, /etc/isdn/isdnlog.contr0.options o. ä., den Eintrag dual=0x100 hinzufügen. Soweit ich es abschätzen kann, sollte im vorliegenden Fall der vorhandene isdnlog-4.65 ausreichen, da im Gegensatz zum zitierten Fall keine CALL PROCEEDING Nachricht auftaucht.
Ist isdnlog an einer Telefonanlage angeschlossen, die wiederum über einen Anlagenanschluß am Telefonnetz angeschlossen ist, ist es überlegenswert, in /etc/isdn/isdn.conf als AREACODE nicht nur die eigene Vorwahl sondern zusätzlich die Kopfrufnummer des Anlagenanschlusses mitanzugeben, damit in der isdn.log vollständige Rufnummern erscheinen.
Ich hoffe, zumindest der logging-bezogene Teil des Problems erledigt sich hiermit und würde in jedem Fall gerne über die Wirkung informiert werden.
Gruß Tobias
Hallo Tobias, nochmals vielen Dank für Deine Hilfe. Den Eintrag dual=0x100 habe ich jetzt gesetzt. Zu der unter SuSE 8.2 installierten Version kann ich dir leider nichts genaues sagen. Installiert war dort die Version von den CD's inkl. aller evtl. vorhandenen Patches. Gruß Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dyndns.info http://www.trierer-single-treff.de http://www.Wetter-in-Landscheid.de -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB77 C153 7693 056E
Am Freitag, 14. November 2003 01:13 schrieb Jörg Frings-Fürst:
Hallo,
ich habe ein kleines Problem mit dem isdnlog unter SuSE 9.0 (Update von 8.2) (mit allen aktuellen Patches).
[....] Hallo, zuerst einmal möchte ich mich bei allen, besonders beim Tobias, für die Hilfe bedanken. Mit den vorgeschlagenen Änderungen läuft ISDNLog jetzt einwandfrei. Gruß Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dyndns.info http://www.trierer-single-treff.de http://www.Wetter-in-Landscheid.de -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB77 C153 7693 056E
participants (3)
-
Jörg Frings-Fürst -
Kurt Fleischmann -
Tobias Becker