Hallo! Kommt ein Anruf aufs Telefon und wird danach eine Verbindung ins Inet aufgebaut, erhalte ich keine Einträge mehr im isdn.log. Es werden dann nur noch Anrufe aufs Telefon aufgezeichnet. Das ganze scheint nur aufzutreten, wenn es sich um einen Handyanruf handelt. Nach einem kill -HUP ist alles wieder in Ordnung bis zum nächsten Handyanruf. Was für ein Problem habe ich hier? Ist eine SuSE7.3. -- Andreas Meyer | http://home.wtal.de/MeineHomepage where is the sig?
* Andreas Meyer
Kommt ein Anruf aufs Telefon und wird danach eine Verbindung ins Inet aufgebaut, erhalte ich keine Einträge mehr im isdn.log. Es werden dann nur noch Anrufe aufs Telefon aufgezeichnet. Das ganze scheint nur aufzutreten, wenn es sich um einen Handyanruf handelt. Nach einem kill -HUP ist alles wieder in Ordnung bis zum nächsten Handyanruf.
Was für ein Problem habe ich hier? Ist eine SuSE7.3.
Ohne nähere Angaben kann ich nichts dazu sagen. Üblicherweise ist isdnlog so konfiguriert, dass nicht nur die Verbindungsdaten in isdn.log festgehalten werden, sondern zudem Ausgaben im Syslog oder in einer anderen Logdatei erfolgen. Diese Ausgaben sind zur weiteren Fehlereingrenzung von Interesse, möglichst beginnend mit der Startmeldung des isdnlog nach `kill -HUP ...', die in etwa so aussehen sollte:
| isdnlog Version 4.65 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 | [...]
Nummern und Namen können unkenntlich gemacht werden, dabei bitte die Ziffernzahl möglichst nicht verändern. Zwei weitere Fragen zur vorhandenen Konfiguration: Soll der Handyanruf eine Interneteinwahl auslösen? Welche Anrufe auf welche Telefone werden nach dem Handyanruf noch aufgezeichnet? 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 *
Tobias Becker
* Andreas Meyer
schrieb: Kommt ein Anruf aufs Telefon und wird danach eine Verbindung ins Inet aufgebaut, erhalte ich keine Einträge mehr im isdn.log. Es werden dann nur noch Anrufe aufs Telefon aufgezeichnet. Das ganze scheint nur aufzutreten, wenn es sich um einen Handyanruf handelt. Nach einem kill -HUP ist alles wieder in Ordnung bis zum nächsten Handyanruf.
Was für ein Problem habe ich hier? Ist eine SuSE7.3.
Ohne nähere Angaben kann ich nichts dazu sagen.
Üblicherweise ist isdnlog so konfiguriert, dass nicht nur die Verbindungsdaten in isdn.log festgehalten werden, sondern zudem Ausgaben im Syslog oder in einer anderen Logdatei erfolgen. Diese Ausgaben sind zur weiteren Fehlereingrenzung von Interesse, möglichst beginnend mit der Startmeldung des isdnlog nach `kill -HUP ...', die in etwa so aussehen sollte:
| isdnlog Version 4.65 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 | [...]
daemon.log: isdnlog Version 4.52 starting Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat] Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH Rates Version 1.10-Germany [02-Jun-2000 14:09:56] loaded [1 Providers, 2 Zones, 2 Areas, 47 Services, 3 ComAug 5 04:43:01 heaven7 isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) isdn.conf:2 active channels, 8 MSN/SI entries (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) isdnlog: Everything is fine, isdnlog-4.52 is running in full featured mode. isdnlog: (HiSax driver detected) Es folgt der Handyanruf daemon.log: isdnlog: Aug 05 04:46:49 * Call to tei 127 from Handy on ISDN-Telefon RING (Speech) isdnlog: Aug 05 04:46:49 * Call to tei 127 from Handy on ISDN-Telefon HLC: CCITT, Telefonie isdnlog: Aug 05 04:46:57 * Call to tei 72 from Handy on ISDN-Telefon HANGUP isdnlog: Aug 05 04:46:57 * Call to tei 102 from Handy on ISDN-Telefon HANGUP dann erfolgt Einwahl Internet: isdnlog: Aug 05 04:53:39 * tei 72 calling Q-Dial with ISDN-Router RING (Data) isdnlog: Aug 05 04:53:40 * tei 127 calling ? with ? Time:Tue Aug 5 04:53:00 2003 ntpdate[1677]: adjust time server 192.53.103.103 offset -0.006710 sec ntpd[1682]: ntpd 4.1.0 Fri Sep 21 14:42:26 GMT 2001 (1) ntpd[1682]: precision = 7 usec ntpd[1682]: kernel time discipline status 0040 ntpd[1682]: frequency initialized 8.129 from /etc/ntp.drift erneuter Handyanruf: isdnlog: Aug 05 05:04:40 * Call to tei 127 from Handy on ISDN-Telefon RING (Speech) isdnlog: Aug 05 05:04:40 * Call to tei 127 from Handy on ISDN-Telefon HLC: CCITT, Telefonie isdnlog: Aug 05 05:04:46 * Call to tei 72 from Handy on ISDN-Telefon HANGUP isdnlog: Aug 05 05:04:46 * Call to tei 102 from Handy on ISDN-Telefon HANGUP Anruf von Telefon am a/b-Wandler auf ISDN-Telefon: isdnlog: Aug 05 05:10:33 * Call to tei 127 from ? on ISDN-Telefon RING (3.1 kHz audio) isdnlog: Aug 05 05:10:40 * Call to tei 72 from Handy on ISDN-Telefon HANGUP isdnlog: Aug 05 05:10:40 * Call to tei 102 from Handy on ISDN-Telefon HANGUP isdnlog: Aug 05 05:11:29 Call to tei 127 from ? on ISDN-Telefon HANGUP (Timeout) erneute Einwahl ins Internet: isdnlog: Aug 05 05:18:49 * tei 72 calling Q-Dial with ISDN-Router RING (Data) isdnlog: Aug 05 05:18:50 * tei 127 calling ? with ? Time:Tue Aug 5 05:18:00 2003 ntpdate[1889]: adjust time server 192.53.103.103 offset -0.001702 sec ntpd[1893]: ntpd 4.1.0 Fri Sep 21 14:42:26 GMT 2001 (1) ntpd[1893]: precision = 10 usec ntpd[1893]: kernel time discipline status 0040 ntpd[1893]: frequency initialized 8.129 from /etc/ntp.drift firewall.log: kernel: isdn_net: call from 1757052847,1,0 -> 144310 heaven7 kernel: isdn_net: call from 1757052847 -> 0 144310 ignored heaven7 kernel: isdn_tty: call from 1757052847, -> RING on ttyI3 heaven7 kernel: isdn: HiSax,ch0 cause: E0010 dann erfolgt Einwahl Internet: kernel: ippp7: dialing 1 01931521... kernel: isdn_net: ippp7 connected kernel: isdn_net: local hangup ippp7 kernel: ippp7: Chargesum is 0 kernel: ippp, open, slot: 7, minor: 7, state: 0000 kernel: ippp_ccp: allocated reset data structure c3e54800 kernel: ippp_ccp: freeing reset data structure c3e54000 erneuter Handanruf: kernel: isdn_net: call from 1757052847,1,0 -> 144310 kernel: isdn_net: call from 1757052847 -> 0 144310 ignored kernel: isdn_tty: call from 1757052847, -> RING on ttyI3 kernel: isdn: HiSax,ch0 cause: E0010 Anruf von Telefon am a/b-Wandler auf ISDN-Telefon: kernel: isdn_net: Incoming call without OAD, assuming '0' kernel: isdn_net: call from 0,1,0 -> 144310 kernel: isdn_net: call from 0 -> 0 144310 ignored kernel: isdn_tty: Incoming call without OAD, assuming '0' kernel: isdn_tty: call from 0, -> RING on ttyI3 kernel: isdn: HiSax,ch0 cause: E0010 erneute Einwahl ins Internet: kernel: ippp7: dialing 1 01931521... kernel: isdn_net: ippp7 connected kernel: isdn_net: local hangup ippp7 kernel: ippp7: Chargesum is 0 kernel: ippp, open, slot: 9, minor: 7, state: 0000 kernel: ippp_ccp: allocated reset data structure c2de6000 kernel: ippp_ccp: freeing reset data structure c3e54800 dazugehörendes isdn.log: Aug 5 04:46:49 2003|+491757052847 |+496341144310 | 0| 0|1060051609| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| Aug 5 04:46:49 2003|+491757052847 |+496341144310 | 0| 0|1060051609| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| dann erfolgt Einwahl Internet: log bleibt leer erneuter Handyanruf: Aug 5 05:04:40 2003|+491757052847 |+496341144310 | 0| 0|1060052680| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| Aug 5 05:04:40 2003|+491757052847 |+496341144310 | 0| 0|1060052680| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| Anruf von Telefon am a/b-Wandler auf ISDN-Telefon: Aug 5 05:10:27 2003|+491757052847 |+496341144310 | 0| 0|1060053027| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| Aug 5 05:10:27 2003|+491757052847 |+496341144310 | 0| 0|1060053027| \ -1|I| 16| 0| 0|3.2|1|1|1|EUR|0| 80| -1| Aug 5 05:10:33 2003| |+496341144310 |-1060053033| 418173|1060053033| \ -1|I| -1| 0| 0|3.2|1|0|1|EUR|0| 80| -1| Hier wird die Handynummer noch zweimal aufgeführt, obwohl der Anruf vom a/b-Wandler-Telefon kam! erneute Einwahl ins Internet: log bleibt leer /var/log/messages: Aug 5 04:53:41 heaven7 ipppd[555]: Local number: 648100, Remote number: 01931521, Type: outgoing Aug 5 04:53:41 heaven7 ipppd[555]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 7, linkunit: 0, fd: 9 Aug 5 04:53:41 heaven7 ipppd[555]: Remote message: Login Succeeded Aug 5 04:53:41 heaven7 ipppd[555]: MPPP negotiation, He: No We: No Aug 5 04:53:41 heaven7 ipppd[555]: local IP address 212.202.68.81 Aug 5 04:53:41 heaven7 ipppd[555]: remote IP address 212.202.63.16 Aug 5 04:54:49 heaven7 ipppd[555]: Modem hangup Aug 5 04:54:49 heaven7 ipppd[555]: Connection terminated. Aug 5 04:54:49 heaven7 ipppd[555]: taking down PHASE_DEAD link 0, linkunit: 0 Aug 5 04:54:49 heaven7 ipppd[555]: closing fd 9 from unit 0 Aug 5 04:54:49 heaven7 ipppd[555]: link 0 closed , linkunit: 0 Aug 5 04:54:49 heaven7 ipppd[555]: reinit_unit: 0 Aug 5 04:54:49 heaven7 ipppd[555]: Connect[0]: /dev/ippp7, fd: 9 erneute Einwahl ins Internet: Aug 5 05:18:49 heaven7 sshd[1823]: Accepted publickey for ROOT from 192.168.1.3 port 1121 ssh2 Aug 5 05:18:50 heaven7 ipppd[555]: Local number: 648100, Remote number: 01931521, Type: outgoing Aug 5 05:18:50 heaven7 ipppd[555]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 7, linkunit: 0, fd: 9 Aug 5 05:18:51 heaven7 ipppd[555]: Remote message: Login Succeeded Aug 5 05:18:51 heaven7 ipppd[555]: MPPP negotiation, He: No We: No Aug 5 05:18:51 heaven7 ipppd[555]: local IP address 212.202.66.64 Aug 5 05:18:51 heaven7 ipppd[555]: remote IP address 212.202.63.6 Aug 5 05:19:47 heaven7 ipppd[555]: Modem hangup Aug 5 05:19:47 heaven7 ipppd[555]: Connection terminated. Aug 5 05:19:47 heaven7 ipppd[555]: taking down PHASE_DEAD link 0, linkunit: 0 Aug 5 05:19:47 heaven7 ipppd[555]: closing fd 9 from unit 0 Aug 5 05:19:47 heaven7 ipppd[555]: link 0 closed , linkunit: 0 Aug 5 05:19:47 heaven7 ipppd[555]: reinit_unit: 0 Aug 5 05:19:47 heaven7 ipppd[555]: Connect[0]: /dev/ippp7, fd: 9
Nummern und Namen können unkenntlich gemacht werden, dabei bitte die Ziffernzahl möglichst nicht verändern.
Zwei weitere Fragen zur vorhandenen Konfiguration:
Soll der Handyanruf eine Interneteinwahl auslösen?
Nicht in diesem Fall.
Welche Anrufe auf welche Telefone werden nach dem Handyanruf noch aufgezeichnet?
Es werden nur noch Anrufe auf die Telefone aufgezeichnet. Allerdings wird auch beim Anruf vom a/b-Wandler auf das ISDN-Telefon die Handynummer aufgeführt, obwohl das Teil nicht im Spiel war. Rufe ich nach einem kill -HUP des isdnlog vom a/b-Wandler auf das ISDN-Telefon an, wird brav aufgezeichnet. Sobald wieder ein Handyanruf dazu kommt, ists vorbei, sprich es werden nur noch die Telefonrufe aufgezeichnet. Ich muß Handyanrufe verbieten! :-) -- Andreas Meyer | http://home.wtal.de/MeineHomepage Hey, Shaun! You highjacked my thread. :-)
* Andreas Meyer
daemon.log: isdnlog Version 4.52 starting Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat] Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH Rates Version 1.10-Germany [02-Jun-2000 14:09:56] loaded [1 Providers, 2 Zones, 2 Areas, 47 Services, 3 ComAug 5 04:43:01 heaven7 isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) isdn.conf:2 active channels, 8 MSN/SI entries (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) isdnlog: Everything is fine, isdnlog-4.52 is running in full featured mode. isdnlog: (HiSax driver detected)
Es folgt der Handyanruf daemon.log: isdnlog: Aug 05 04:46:49 * Call to tei 127 from Handy on ISDN-Telefon RING (Speech) isdnlog: Aug 05 04:46:49 * Call to tei 127 from Handy on ISDN-Telefon HLC: CCITT, Telefonie isdnlog: Aug 05 04:46:57 * Call to tei 72 from Handy on ISDN-Telefon HANGUP isdnlog: Aug 05 04:46:57 * Call to tei 102 from Handy on ISDN-Telefon HANGUP dann erfolgt Einwahl Internet: isdnlog: Aug 05 04:53:39 * tei 72 calling Q-Dial with ISDN-Router RING (Data) isdnlog: Aug 05 04:53:40 * tei 127 calling ? with ? Time:Tue Aug 5 04:53:00 2003 [...]
Diese Zeilen sind aufschlußreich. Der Handyanruf bleibt unbeantwortet, d. h. es kommt keine Verbindung zustande. Bei der Verfolgung der nächsten gehenden Verbindung (Interneteinwahl) treten dann bereits Fehler auf, erkennbar wird hier die Zeitmitteilung der Vermittlungsstelle nicht der zuvor richtig erkannten Verbindung zugeordnet. Die Ursache liegt wahrscheinlich in dem vorhergehenden _unbeantworten_ kommenden Anruf, dass es sich hierbei um ein Handy handelt, sollte nicht von Belang sein. In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig. (Die Parameterdatei ist nicht /etc/isdn/isdn.conf, sondern die Datei, welche isdnlog mit -f übergeben wird, üblicherweise /etc/isdn/isdnlog.isdnctrl0.options.) Wird auf die Parameterdatei verzichtet, ist dem isdnlog-Aufruf `-20x0100' hinzuzufügen. Hiermit wird ein bislang nur im Dualmode erprobter Workaround aktiviert, der das Problem beheben sollte. Der Dualmode selbst wird hierdurch nicht aktiviert. Bitte in jeden Fall bekanntgeben, wie das Resultat aussieht oder wo neue Probleme auftauchen. 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 *
Tobias Becker
dann erfolgt Einwahl Internet: isdnlog: Aug 05 04:53:39 * tei 72 calling Q-Dial with ISDN-Router RING (Data) isdnlog: Aug 05 04:53:40 * tei 127 calling ? with ? Time:Tue Aug 5 04:53:00 2003 [...]
Diese Zeilen sind aufschlußreich. Der Handyanruf bleibt unbeantwortet, d. h. es kommt keine Verbindung zustande. Bei der Verfolgung der nächsten gehenden Verbindung (Interneteinwahl) treten dann bereits Fehler auf, erkennbar wird hier die Zeitmitteilung der Vermittlungsstelle nicht der zuvor richtig erkannten Verbindung zugeordnet.
Die Ursache liegt wahrscheinlich in dem vorhergehenden _unbeantworten_ kommenden Anruf, dass es sich hierbei um ein Handy handelt, sollte nicht von Belang sein.
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
(Die Parameterdatei ist nicht /etc/isdn/isdn.conf, sondern die Datei, welche isdnlog mit -f übergeben wird, üblicherweise /etc/isdn/isdnlog.isdnctrl0.options.) Wird auf die Parameterdatei verzichtet, ist dem isdnlog-Aufruf `-20x0100' hinzuzufügen. Hiermit wird ein bislang nur im Dualmode erprobter Workaround aktiviert, der das Problem beheben sollte. Der Dualmode selbst wird hierdurch nicht aktiviert.
Bitte in jeden Fall bekanntgeben, wie das Resultat aussieht oder wo neue Probleme auftauchen.
Alles klar, sehr schön! Ich bin drei Tage außer Haus (France ist auch ganz schön; 30m tiefen Brunnen inspizieren). Sobald ich zurück bin, werde ich mich mit deinen Anweisungen beschäftigen. Melde mich dann. Ich bedanke mich für deine Aufmerksamkeit! -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage "When it absolutely, positively has to be destroyed overnight." - Marine bumper sticker
Tobias Becker
isdnlog: Aug 05 04:53:39 * tei 72 calling Q-Dial with ISDN-Router RING (Data) isdnlog: Aug 05 04:53:40 * tei 127 calling ? with ? Time:Tue Aug 5 04:53:00 2003 [...]
Diese Zeilen sind aufschlußreich. Der Handyanruf bleibt unbeantwortet, d. h. es kommt keine Verbindung zustande. Bei der Verfolgung der nächsten gehenden Verbindung (Interneteinwahl) treten dann bereits Fehler auf, erkennbar wird hier die Zeitmitteilung der Vermittlungsstelle nicht der zuvor richtig erkannten Verbindung zugeordnet.
Die Ursache liegt wahrscheinlich in dem vorhergehenden _unbeantworten_ kommenden Anruf, dass es sich hierbei um ein Handy handelt, sollte nicht von Belang sein.
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
Nun muß ich mich leider als völliger CVS-DAU outen. Ich bin auf http://www.isdn4linux.de/cgi-bin/cvsweb.cgi/isdn4k-utils/isdnlog/ und lade dann die einzelnen files in ein eigenes lokales Verzeichnis und versuche zu übersetzen? Hm, warum geht das nicht per ftp? Der Browser arbeitet ja nicht rekursiv. Wie könnte ich alle files rekursiv abgreifen? Mit wget? oje...
(Die Parameterdatei ist nicht /etc/isdn/isdn.conf, sondern die Datei, welche isdnlog mit -f übergeben wird, üblicherweise /etc/isdn/isdnlog.isdnctrl0.options.) Wird auf die Parameterdatei verzichtet, ist dem isdnlog-Aufruf `-20x0100' hinzuzufügen. Hiermit wird ein bislang nur im Dualmode erprobter Workaround aktiviert, der das Problem beheben sollte. Der Dualmode selbst wird hierdurch nicht aktiviert.
Bitte in jeden Fall bekanntgeben, wie das Resultat aussieht oder wo neue Probleme auftauchen.
Wenn ich bis dahin komme... -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage Remark of the day : Tact is the art of making a point without making an enemy.
Andreas Meyer wrote:
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
Nun muß ich mich leider als völliger CVS-DAU outen. Ich bin auf http://www.isdn4linux.de/cgi-bin/cvsweb.cgi/isdn4k-utils/isdnlog/ und lade dann die einzelnen files in ein eigenes lokales Verzeichnis und versuche zu übersetzen?
Hm, warum geht das nicht per ftp? Der Browser arbeitet ja nicht rekursiv. Wie könnte ich alle files rekursiv abgreifen? Mit wget? oje...
Das würde auf die Dauer sicher sehr langweilig werden. Nein, das Tool heisst "cvs". Schau mal dort in die FAQ, dort gibt es ne Anleitung wie das geht. http://www.isdn4linux.de/faq/i4lfaq-2.html#distrib -- Gruß, Andreas
Andreas Winkelmann
Hm, warum geht das nicht per ftp? Der Browser arbeitet ja nicht rekursiv. Wie könnte ich alle files rekursiv abgreifen? Mit wget? oje...
Das würde auf die Dauer sicher sehr langweilig werden. Nein, das Tool heisst "cvs". Schau mal dort in die FAQ, dort gibt es ne Anleitung wie das geht.
Gut! Dann kriegt cvs halt ein Loch in der firewall gestanzt. -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage Windows has detected that a gnat has farted near your computer. Press any key to reboot.
Andreas Winkelmann
Das würde auf die Dauer sicher sehr langweilig werden. Nein, das Tool heisst "cvs". Schau mal dort in die FAQ, dort gibt es ne Anleitung wie das geht.
root@gamma:/home/andreas/cvs > cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev login Logging in to :pserver:guest@cvs.isdn4linux.de:2401/i4ldev CVS password: cvs login: failed to open /root/.cvspass for reading: Datei oder Verzeichnis nicht gefunden cvs [login aborted]: fatal error: exiting Dann habe ich .cvspass mit Inhalt readonly angelegt: root@gamma:/home/andreas/cvs > cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev login Logging in to :pserver:guest@cvs.isdn4linux.de:2401/i4ldev CVS password: cvs login: warning: skipping invalid entry in password file at line 1 Wie sieht denn das Format der .cvspass aus? root@gamma:/home/andreas/cvs > man cvs |grep cvspass root@gamma:/home/andreas/cvs > apropos cvspass cvspass: nichts passendes. -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage I'd like to conclude with a positive statement, but I can't remember any. Would two negative ones do? -- Woody Allen
Hi Andreas,
Das würde auf die Dauer sicher sehr langweilig werden. Nein, das Tool heisst "cvs". Schau mal dort in die FAQ, dort gibt es ne Anleitung wie das geht.
root@gamma:/home/andreas/cvs > cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev login Logging in to :pserver:guest@cvs.isdn4linux.de:2401/i4ldev CVS password: cvs login: failed to open /root/.cvspass for reading: Datei oder Verzeichnis nicht gefunden cvs [login aborted]: fatal error: exiting
Dann habe ich .cvspass mit Inhalt readonly angelegt:
mach doch einfach mal ein "rm -f ~/.cvspass;touch ~/.cvspass" und dann nochmal das cvs login ;) das cvs ist etwas doof, wenn es die datei findet. beim zweiten anlauf müsste es eigentlich auch ohne das touch gehen, aber mit geht's auf alle fälle =) -- Viele Grüsse, Kilian
Kilian Krause
cvs login: failed to open /root/.cvspass for reading: Datei oder Verzeichnis nicht gefunden cvs [login aborted]: fatal error: exiting
Dann habe ich .cvspass mit Inhalt readonly angelegt:
mach doch einfach mal ein "rm -f ~/.cvspass;touch ~/.cvspass" und dann nochmal das cvs login ;)
das cvs ist etwas doof, wenn es die datei findet. beim zweiten anlauf müsste es eigentlich auch ohne das touch gehen, aber mit geht's auf alle fälle =)
aha, das funktioniert. Das geht ja schnarchlangsam mit diesen cvs bis das alles vor Ort ist. -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage "I'm not under the alcofluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get."
Hallo!
Tobias Becker
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
(Die Parameterdatei ist nicht /etc/isdn/isdn.conf, sondern die Datei, welche isdnlog mit -f übergeben wird, üblicherweise /etc/isdn/isdnlog.isdnctrl0.options.) Wird auf die Parameterdatei verzichtet, ist dem isdnlog-Aufruf `-20x0100' hinzuzufügen. Hiermit wird ein bislang nur im Dualmode erprobter Workaround aktiviert, der das Problem beheben sollte. Der Dualmode selbst wird hierdurch nicht aktiviert.
Bitte in jeden Fall bekanntgeben, wie das Resultat aussieht oder wo neue Probleme auftauchen.
Zwei Dinge beim "make config" sind mir aufgefallen: Running configure in capiinfo ... ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /home/sourcen/cvs/isdn4k-utils/capiinfo/missing: Unknown `--run' option Try `/home/sourcen/cvs/isdn4k-utils/capiinfo/missing --help' for more information configure: WARNING: `missing' script is too old or missing checking for gawk... gawk checking whether make sets ${MAKE}... yes` ... und: Running configure in FAQ ... loading cache ./config.cache checking for a BSD compatible install... /usr/bin/install -c checking for tar... /bin/tar checking for zip... /usr/bin/zip checking for gzip... /usr/bin/gzip checking for sgml2html... ./configure: test: too many arguments sgml2html-not-found-or-installed checking for sgml2txt... ./configure: test: too many arguments sgml2txt-not-found-or-installed configure: error: sgml2html not found please install it. make[2]: Entering directory `/home/sourcen/cvs/isdn4k-utils' WARNING! Configure in FAQ failed, disabling package make[2]: Leaving directory `/home/sourcen/cvs/isdn4k-utils' make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils' und dann beim make-Lauf am Ende: ... gcc -shared capi20.lo capifunc.lo convert.lo -Wl,-soname -Wl,libcapi20.so.2 \ -o .libs/libcapi20.so.2.0.6 (cd .libs && rm -f libcapi20.so.2 && ln -s libcapi20.so.2.0.6 libcapi20.so.2) (cd .libs && rm -f libcapi20.so && ln -s libcapi20.so.2.0.6 libcapi20.so) ar cru .libs/libcapi20.a capi20.o capifunc.o convert.o ranlib .libs/libcapi20.a creating libcapi20.la (cd .libs && rm -f libcapi20.la && ln -s ../libcapi20.la libcapi20.la) make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capi20' make[1]: Entering directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' cd . && aclocal-1.6 /bin/sh: aclocal-1.6: command not found make[1]: *** [aclocal.m4] Error 127 make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' make: *** [subtargets] Error 2 Was wäre zu tun? -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage
* Andreas Meyer
Zwei Dinge beim "make config" sind mir aufgefallen:
Running configure in capiinfo ... ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /home/sourcen/cvs/isdn4k-utils/capiinfo/missing: Unknown `--run' option Try `/home/sourcen/cvs/isdn4k-utils/capiinfo/missing --help' for more information configure: WARNING: `missing' script is too old or missing checking for gawk... gawk checking whether make sets ${MAKE}... yes` ...
Hier liegt eventuell ein Versionskonflikt mit autoconf vor. capiinfo/configure wurde mit `GNU Autoconf 2.53' erstellt. Solltest Du ein älteres autoconf installiert haben (siehe `autoconf --version'), hilft vielleicht ein Neuerstellen von configure aus configure.in mittels autoconf-Aufruf in diesem Verzeichnis weiter. autoconf & Co. haben allerdings für mich bislang wenig von ihrem Zauber verloren, insofern ist das Vorstehende mit hinreichend viel Vorsicht zu genießen.
Running configure in FAQ ...
loading cache ./config.cache checking for a BSD compatible install... /usr/bin/install -c checking for tar... /bin/tar checking for zip... /usr/bin/zip checking for gzip... /usr/bin/gzip checking for sgml2html... ./configure: test: too many arguments sgml2html-not-found-or-installed checking for sgml2txt... ./configure: test: too many arguments sgml2txt-not-found-or-installed configure: error: sgml2html not found please install it. make[2]: Entering directory `/home/sourcen/cvs/isdn4k-utils'
WARNING! Configure in FAQ failed, disabling package
Naheliegend wäre, erst einmal zu schauen, ob sgml2html auf dem System vorhanden ist. Falls ja, sollte `locate sgml2html' unter anderem /usr/bin/sgml2html o. ä. finden. Falls nicht, was die Ausgaben von configure erwarten lassen, ist das Erstellen der FAQ nicht möglich, was aber den weiteren Übersetzungsvorgang nicht weiter beeinflußt.
und dann beim make-Lauf am Ende:
... gcc -shared capi20.lo capifunc.lo convert.lo -Wl,-soname -Wl,libcapi20.so.2 \ -o .libs/libcapi20.so.2.0.6 (cd .libs && rm -f libcapi20.so.2 && ln -s libcapi20.so.2.0.6 libcapi20.so.2) (cd .libs && rm -f libcapi20.so && ln -s libcapi20.so.2.0.6 libcapi20.so) ar cru .libs/libcapi20.a capi20.o capifunc.o convert.o ranlib .libs/libcapi20.a creating libcapi20.la (cd .libs && rm -f libcapi20.la && ln -s ../libcapi20.la libcapi20.la) make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capi20' make[1]: Entering directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' cd . && aclocal-1.6 /bin/sh: aclocal-1.6: command not found make[1]: *** [aclocal.m4] Error 127 make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' make: *** [subtargets] Error 2
aclocal gehört ins autoconf/automake Umfeld, daher sollte zunächst der Fehler im selben Verzeichnis bei make config behoben werden.
Was wäre zu tun?
Da es primär ja um eine Neuübersetzung von isdnlog geht, können alle anderen Programme in der Menüauswahl bei `make config' deaktiviert werden. Alles was isdnlog zum Laufen benötigt ist auf Deinem System bereits vorhanden, schließlich funktioniert er ja, nur halt in einer älteren Version. Insbesondere durch Ausschalten von `Card configuration tools' ---> `avmcapictrl / capiinit' wird auch capiinfo nicht mehr konfiguriert oder übersetzt. Eine weitere Möglichkeit, sich auf isdnlog zu konzentrieren, besteht darin, nach `make config' ins Unterverzeichnis isdnlog zu wechseln und in diesem dann `make all' und `make install' auszuführen. 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
Running configure in capiinfo ... ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /home/sourcen/cvs/isdn4k-utils/capiinfo/missing: Unknown `--run' option Try `/home/sourcen/cvs/isdn4k-utils/capiinfo/missing --help' for more information configure: WARNING: `missing' script is too old or missing checking for gawk... gawk checking whether make sets ${MAKE}... yes` ...
Hier liegt eventuell ein Versionskonflikt mit autoconf vor. capiinfo/configure wurde mit `GNU Autoconf 2.53' erstellt. Solltest Du ein älteres autoconf installiert haben (siehe `autoconf --version'), hilft vielleicht ein Neuerstellen von configure aus configure.in mittels autoconf-Aufruf in diesem Verzeichnis weiter. autoconf & Co. haben allerdings für mich bislang wenig von ihrem Zauber verloren, insofern ist das Vorstehende mit hinreichend viel Vorsicht zu genießen.
Ich habe die neuesten autoconf-2.57.tar.gz und automake-1.7.6.tar.gz übersetzt und installiert und neu verlinkt. Zur Not kann ich das alles rückgängig machen. Die Kiste darf ja nicht ausfallen.
Running configure in FAQ ...
loading cache ./config.cache checking for a BSD compatible install... /usr/bin/install -c checking for tar... /bin/tar checking for zip... /usr/bin/zip checking for gzip... /usr/bin/gzip checking for sgml2html... ./configure: test: too many arguments sgml2html-not-found-or-installed checking for sgml2txt... ./configure: test: too many arguments sgml2txt-not-found-or-installed configure: error: sgml2html not found please install it. make[2]: Entering directory `/home/sourcen/cvs/isdn4k-utils'
WARNING! Configure in FAQ failed, disabling package
Naheliegend wäre, erst einmal zu schauen, ob sgml2html auf dem System vorhanden ist. Falls ja, sollte `locate sgml2html' unter anderem /usr/bin/sgml2html o. ä. finden. Falls nicht, was die Ausgaben von configure erwarten lassen, ist das Erstellen der FAQ nicht möglich, was aber den weiteren Übersetzungsvorgang nicht weiter beeinflußt.
Ist gelöst; ich habe diese sgml-tools installiert.
und dann beim make-Lauf am Ende:
... gcc -shared capi20.lo capifunc.lo convert.lo -Wl,-soname -Wl,libcapi20.so.2 \ -o .libs/libcapi20.so.2.0.6 (cd .libs && rm -f libcapi20.so.2 && ln -s libcapi20.so.2.0.6 libcapi20.so.2) (cd .libs && rm -f libcapi20.so && ln -s libcapi20.so.2.0.6 libcapi20.so) ar cru .libs/libcapi20.a capi20.o capifunc.o convert.o ranlib .libs/libcapi20.a creating libcapi20.la (cd .libs && rm -f libcapi20.la && ln -s ../libcapi20.la libcapi20.la) make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capi20' make[1]: Entering directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' cd . && aclocal-1.6 /bin/sh: aclocal-1.6: command not found make[1]: *** [aclocal.m4] Error 127 make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' make: *** [subtargets] Error 2
aclocal gehört ins autoconf/automake Umfeld, daher sollte zunächst der Fehler im selben Verzeichnis bei make config behoben werden.
Was wäre zu tun?
Da es primär ja um eine Neuübersetzung von isdnlog geht, können alle anderen Programme in der Menüauswahl bei `make config' deaktiviert werden. Alles was isdnlog zum Laufen benötigt ist auf Deinem System bereits vorhanden, schließlich funktioniert er ja, nur halt in einer älteren Version. Insbesondere durch Ausschalten von `Card configuration tools' ---> `avmcapictrl / capiinit' wird auch capiinfo nicht mehr konfiguriert oder übersetzt. Eine weitere Möglichkeit, sich auf isdnlog zu konzentrieren, besteht darin, nach `make config' ins Unterverzeichnis isdnlog zu wechseln und in diesem dann `make all' und `make install' auszuführen.
bingo. Habe im Unterverzeichnis isdnlog ein make all und make install durchgeführt, verlief ohne Fehlermeldung. Ich stürze mich da morgen nochmal rein und mache die Einträge in /etc/isdn/isdnlog.isdnctrl0.options. Eines war mir beim make-Lauf im Top-Verzeichnis noch aufgefallen: Running configure in ipppd ... checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for daemon in -lbsd... no configure: WARNING: Could not find libbsd ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checking for main in -lcrypt... yes checking for des_ecb_encrypt in -ldes... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for sys/types.h... yes checking for sys/stat.h... yes hm, installiert ist /usr/lib/libbsd-compat.a und: make[1]: Entering directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' cd . && aclocal-1.6 /bin/sh: aclocal-1.6: command not found make[1]: *** [aclocal.m4] Error 127 make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' make: *** [subtargets] Error 2 Warum wird auf aclocal-1.6 zugegriffen? Es ist eine # /usr/local/bin/aclocal --version aclocal (GNU automake) 1.7.6 installiert, verlinkt nach /usr/bin. Gruß, melde mich morgen! -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage Du bist der Herr Deiner Worte bis Du sie ausgesprochen hast! Hast Du sie ausgesprochen, beherrschen sie Dich! - irisches Sprichwort -
* Andreas Meyer
[...] Eines war mir beim make-Lauf im Top-Verzeichnis noch aufgefallen: Running configure in ipppd ...
checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for daemon in -lbsd... no configure: WARNING: Could not find libbsd ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checking for main in -lcrypt... yes checking for des_ecb_encrypt in -ldes... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for sys/types.h... yes checking for sys/stat.h... yes
hm, installiert ist /usr/lib/libbsd-compat.a
Das gehört zwar beides nicht zu meiner Baustelle, folgendes ist mir aber dazu eingefallen: Bei mir gibt es neben /usr/lib/libbsd-compat.a auch /usr/lib/libbsd.a, beide aus dem Paket glibc-devel-2.1.3. (Mein System ist ein Redhat 6.1 auf einem 486er)
und:
make[1]: Entering directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' cd . && aclocal-1.6 /bin/sh: aclocal-1.6: command not found make[1]: *** [aclocal.m4] Error 127 make[1]: Leaving directory `/home/sourcen/cvs/isdn4k-utils/capiinfo' make: *** [subtargets] Error 2
Warum wird auf aclocal-1.6 zugegriffen? Es ist eine # /usr/local/bin/aclocal --version aclocal (GNU automake) 1.7.6 installiert, verlinkt nach /usr/bin.
aclocal-1.6 scheint öfters explizit angefordert zu werden, Google brachte den Hinweis aus einer Mailingliste zu openldap, einen entsprechenden Link aclocal-1.6 -> aclocal zu setzen. 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 *
Tobias Becker
Die Ursache liegt wahrscheinlich in dem vorhergehenden _unbeantworten_ kommenden Anruf, dass es sich hierbei um ein Handy handelt, sollte nicht von Belang sein.
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
well allright. Ich habe das neue isdnlog am Laufen. Es wird wie gewohnt aufgezeichnet. Dann habe ich in der /etc/isdn/isdnlog.isdnctrl0.options den Eintrag dual=0x100 hinzugefügt und ein kill -HUP `cat /var/run/isdnlog.isdnctrl0.pid` ausgeführt. isdnlog wird leider nicht neu gestartet. Ein nochmaliges kill -HUP ... bringt: cat: /var/run/isdnlog.isdnctrl0.pid: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec] Das pid-file ist nicht vorhanden. Kommentiere ich dual=0x100 wieder aus und führe ein rci4l_hardware aus, wird das pid-file wieder erstellt. -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet?
* Andreas Meyer
Tobias Becker
schrieb: Die Ursache liegt wahrscheinlich in dem vorhergehenden _unbeantworten_ kommenden Anruf, dass es sich hierbei um ein Handy handelt, sollte nicht von Belang sein.
In diesem Fall ist eine Lösung mit dem aktuellen isdnlog-4.65 möglich, dessen Quellen via anonymen CVS-Zugriff von isdn4linux.de als Teil isdn4k-utils erhältlich sind. Nach Konfiguration, Übersetzen und Installation ist noch der Eintrag dual=0x100 in der isdnlog-Parameterdatei notwendig.
well allright. Ich habe das neue isdnlog am Laufen. Es wird wie gewohnt aufgezeichnet. Dann habe ich in der /etc/isdn/isdnlog.isdnctrl0.options den Eintrag dual=0x100 hinzugefügt und ein kill -HUP `cat /var/run/isdnlog.isdnctrl0.pid` ausgeführt. isdnlog wird leider nicht neu gestartet. Ein nochmaliges kill -HUP ... bringt: cat: /var/run/isdnlog.isdnctrl0.pid: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
Das pid-file ist nicht vorhanden. Kommentiere ich dual=0x100 wieder aus und führe ein rci4l_hardware aus, wird das pid-file wieder erstellt.
Das ist alles merkwürdig. Aber immer der Reihe nach. Wird in allen vorgenannten Fällen wirklich der neue isdnlog (neu) gestartet? Darüber sollte die isdnlog-Versionnummer in /var/log/daemon Aufschluss geben. Eventuell finden sich hier zudem Fehlermeldungen, die Hinweise liefern, wieso der Neustart nach Änderung der Parameterdatei scheitert. Als nächstes wäre zu testen, ob `kill -HUP ...' mit neuen isdnlog und unveränderter, alter Parameterdatei funktioniert. `ps ax' o. ä. zeigt jeweils an, ob der isdnlog wirklich noch läuft. Als vorläufig letztes bliebe dann noch, die Parameterdatei zu ändern, und isdnlog mittels rci4l_hardware komplett neu zu starten. Das alles sollte zumindest einen Anhaltspunkt liefern, was genau schiefläuft. 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 *
Tobias Becker
Dann habe ich in der /etc/isdn/isdnlog.isdnctrl0.options den Eintrag dual=0x100 hinzugefügt und ein kill -HUP `cat /var/run/isdnlog.isdnctrl0.pid` ausgeführt. isdnlog wird leider nicht neu gestartet. Ein nochmaliges kill -HUP ... bringt: cat: /var/run/isdnlog.isdnctrl0.pid: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
Das pid-file ist nicht vorhanden. Kommentiere ich dual=0x100 wieder aus und führe ein rci4l_hardware aus, wird das pid-file wieder erstellt.
Das ist alles merkwürdig. Aber immer der Reihe nach. Wird in allen vorgenannten Fällen wirklich der neue isdnlog (neu) gestartet? Darüber sollte die isdnlog-Versionnummer in /var/log/daemon Aufschluss geben. Eventuell finden sich hier zudem Fehlermeldungen, die Hinweise liefern, wieso der Neustart nach Änderung der Parameterdatei scheitert.
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
Als nächstes wäre zu testen, ob `kill -HUP ...' mit neuen isdnlog und unveränderter, alter Parameterdatei funktioniert. `ps ax' o. ä. zeigt jeweils an, ob der isdnlog wirklich noch läuft.
Als vorläufig letztes bliebe dann noch, die Parameterdatei zu ändern, und isdnlog mittels rci4l_hardware komplett neu zu starten.
Isdnlog wird mit und ohne dual=0x100 gestartet jetzt. 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. -- Andreas Meyer | http://www.anup.de | http://home.wtal.de/MeineHomepage "...a gang of Dadaist punks had broken into his car and installed an expensive stereo." _Good News From Outer Space_
* 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 *
* Andreas Meyer
[...] isdnlog: isdnlog Version 4.65 starting [...]
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. [...]
Um diese Angelegenheit jetzt auch auf dieser Liste zum Abschluß zu bringen: Für ein korrektes Logging der oben beschriebenen Verbindungen ist eine Änderung am Quelltext erforderlich, die im CVS auf isdn4linux.de bereit steht und unter http://www.isdn4linux.de/cgi-bin/cvsweb.cgi/isdn4k-utils/isdnlog/isdnlog/processor.c.diff?r1=1.124&r2=1.125 einsehbar ist. Der durch dual=0x100 aktivierte Workaround berücksichtige bislang nicht den Fall, dass wie bei Verbindung 4 die komplette Zielrufnummer bereits in der SETUP Nachricht des Endgeräts, hier die ISDN-Karte, angegeben sein kann (Blockwahl), worauf die Vermittlungsstelle nicht mit SETUP_ACKNOWLEDGE sondern mit CALL_PROCEEDING antwortet und in dieser Nachricht den verwendeten B-Kanal bestätigt. Notwendig wird der Workaround durch die Verbindung 3. Für den eingehenden Anruf wird ein B-Kanal bereitgestellt. Da keine Verbindung zustande kommt, erkennt isdnlog nicht, dass dieser B-Kanal wieder zur Verfügung steht, sondern führt ihn weiter als belegt. Käme eine Verbindung zustande, würde der Kanal mit Verbindungsende wieder freigegeben. Bei unbeantworteten Anrufen erfolgt die Freigabe nicht, da isdnlog nicht mitprotokolliert, ob alle Endgeräte die den Ruf signalisieren, damit aufgehört haben. Die verursachende Eigenschaft bei Verbindung 3 war nicht, dass es sich hier um einen Handy handelt, sondern dass es sich um einen unbeantworteten eingehenden Anruf handelt, dessen Quelle nicht am selben ISDN-Anschluß liegt. Soweit meine Beurteilung dieses Falls. 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 *
participants (4)
-
Andreas Meyer
-
Andreas Winkelmann
-
Kilian Krause
-
Tobias Becker