* Andreas Meyer
oha, ein 'whereis isdnlog' ergab unter anderem /sbin/isdnlog und /usr/sbin/isdnlog. Ich habe das /usr/sbin/isdnlog (mit dem älten Datum) zur Seite geschoben und /sbin/isdnlog nach /usr/sbin/isdnlog verlinkt.
kill -HUP `cat /var/run/isdnlog.isdnctrl0.pid` ergibt im daemon.log:
isdnlog: restarting /usr/sbin/isdnlog isdnlog: exit now -9 isdnlog: File /var/run/isdnlog.isdnctrl0.pid removed! isdnlog: File /var/lock/LCK..isdnctrl0 removed! 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) DE 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 [71 Providers, \ 740 Zones, 2669 Areas, 42 Services, 512 Comments, 13 eXceptions, \ 35 Redirects, 2095 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, 8 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: (HiSax driver detected)
pidfile und Prozess sind vorhanden.
# ps aux |grep isdn root 15039 5.2 2.5 2768 1560 ? S 17:56 0:00 /usr/sbin/isdnlog \ -f /etc/isdn/isdnlog.isdnctrl0.options /dev/isdnctrl0
Das sieht doch schon mal gut aus.
[...] Isdnlog wird mit und ohne dual=0x100 gestartet jetzt.
Wie es sein soll.
1. Anruf ISDN-Telefon -> a/b-Wandler: wird geloggt 2. anschließender Anruf Internet : wird geloggt 3. Anruf Handy -> ISDN-Telefon : wird geloggt 4. anschließender Anruf Internet : wird nicht geloggt 5. Anruf ISDN-Telefon -> a/b-Wandler: wird geloggt 6. anschließender Anruf Internet : wird geloggt
Also das Internet-logging wird nach dem Handyanruf unterbrochen. Es funktioniert wieder, sobald dann wieder ein Anruf auf ein Telefon von einem "normalen" Telefon stattgefunden hat.
Aug 12 18:00:58 2003|+496341648100 |01931521 | 44| 4391|1060704058| \ -1|O| 16| 38062| 13148|3.2|7|0|1|EUR|0.0129|199|200| Aug 12 18:02:29 2003|+496341144310 |+49634187482 | 0| 0|1060704149| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1| Aug 12 18:02:29 2003|+496341144310 |+49634187482 | 0| 0|1060704149| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1| Aug 12 18:02:25 2003| | | 0| 0|1060704145| \ -1|O| -1| 0| 0|3.2|0|0|1|EUR|0| -1| -1| Aug 12 18:03:48 2003|+496341648100 |01931521 | 43| 4294|1060704228| \ -1|O| 16| 14686| 9899|3.2|7|0|1|EUR|0.0126133|199|200| Aug 12 18:06:12 2003|+491757052847 |+496341144310 | 0| 0|1060704372| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1| Aug 12 18:06:12 2003|+491757052847 |+496341144310 | 0| 0|1060704372| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1|
----- hier dazwischen fehlt der zweite Internetanruf
Aug 12 18:09:26 2003|+496341144310 |+49634187482 | 0| 0|1060704566| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1| Aug 12 18:09:26 2003|+496341144310 |+49634187482 | 0| 0|1060704566| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0|199| -1| Aug 12 18:09:24 2003| | | 0| 0|1060704564| \ -1|O| -1| 0| 0|3.2|0|0|1|EUR|0| -1| -1| Aug 12 18:10:01 2003|+496341648100 |01931521 | 33| 3299|1060704601| \ -1|O| 16| 13494| 9763|3.2|7|0|1|EUR|0.00974667|199|200|
hm, Problem besteht also nach wie vor. Habs nochmal nach einem 'rci4l_hardware restart' versucht, leider auch ohne Erfolg.
Damit steht immerhin mit ziemlicher Sicherheit fest, dass bei Dir eine besondere, bislang nicht behandelte Besonderheit vorliegt, die isdnlog aus dem Tritt bringt. Um nun Näheres herauszufinden und nach Möglichkeit eine Lösung anzubieten, muss ich den oben geschilderten Ablauf mit der `übersehenen' Interneteinwahl nach Handyanruf Schritt für Schritt im isdnlog durchgehen. Hierfür benötige eine sogenannte Replaydatei, die eine Kopie der Eingangsdaten enthält und einen wiederholten Durchlauf der Ereignisse ermöglicht. Um diese Replaydatei zu erstellen, fügst Du die Zeile `log=15' in die Parameterdatei ein, startest isdnlog neu und führst noch einmal die oben zitierte Anrufserie durch. Nach einem weiteren `kill -HUP ...' an isdnlog, sollte die Replaydatei /tmp/isdnctrl0 erstellt sein. Diese Datei, zusammen mit den isdnlog-Meldungen aus /var/log/daemon und den Dateien isdn.conf und isdnlog.isdnctrl0.options aus /etc/isdn müßtest Du mir dann per Mail zuschicken. Die Replaydatei sollte in etwa so aussehen:
| Tue Aug 12 18:35:07 2003 HEX: 02 9B 01 07 | Tue Aug 12 18:35:07 2003 HEX: 02 9B 06 16 08 01 82 4D | Tue Aug 12 18:35:08 2003 HEX: 00 9B 14 06 08 01 02 45 08 02 80 90 | Tue Aug 12 18:35:08 2003 HEX: 02 9B 01 08 | Tue Aug 12 18:35:17 2003 HEX: 00 9B 16 08 08 01 02 5A | Tue Aug 12 18:35:27 2003 HEX: 02 9B 01 09 | Tue Aug 12 18:35:38 2003 HEX: 02 9B 01 09 | Tue Aug 12 18:36:58 2003 60:11.25 Card1 hfcpci_l1hw unknown pr 1b
Wenn Du magst, kannst Du sie auch einmal selbst an isdnlog verfüttern, eine mögliche Befehlszeile dafür lautet `isdnlog -m0x7fffffff -r <Replaydatei>'. Sobald ich nach Erhalt und Analyse weitere Erkenntnisse gewonnen habe, melde ich mich dann hier wieder. An dieser Stelle schon einmal herzlichen Dank für Deine bisherige Beharrlichkeit, dieses Problem aus der Welt zu räumen. 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 *