* Jörg Frings-Fürst
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 *