Hallo Liste, ich habe hier SuSE 7.3 und folgendes Problem: Nach einer Verbindung zum Internet, klappt nach dem Abbau der Verbindung eine erneute Verbindung nicht mehr. Erst wenn ich i4l neugestartet habe funzt eine neue Einwahl. Was könnte ich hier falsch gemacht oder vergessen haben. Die default route ist richtig gesetzt. Irgendwelche Ideen?? Danke Arne
an Arne Dieckmann 's Tastatur wurde am Montag, 7. Januar 2002 21:46 folgendes notiert:
Hallo Liste,
ich habe hier SuSE 7.3 und folgendes Problem:
Nach einer Verbindung zum Internet, klappt nach dem Abbau der Verbindung eine erneute Verbindung nicht mehr. Erst wenn ich i4l neugestartet habe funzt eine neue Einwahl. Was könnte ich hier falsch gemacht oder vergessen haben. Die default route ist richtig gesetzt.
Dieses Problem habe ich bei automatischer Einwahl (Router). Wenn ich die Verbindung manuell starte, klappts, und sie steht dem LAN wieder zur Verfügung. Hagen -- /HagK/ - hagk@hagk.de Bitte zuerst lesen: http://rfc.net/rfc1855.html (Netiquette) http://www.afaik.de/usenet/faq/zitieren/zitieren-3.php3
Hallo, ich habe unter SuSE 7.3 die Capi4Linux-Treiber für eine PCI-Fritz!Card erfolgreich installiert. Mit lsmod werden alle Treiber wie erforderlich angezeigt. capi 18112 0 capidrv 24272 4 capifs 3424 1 [capi] capiutil 22400 0 [capidrv kernelcapi] isdn 118448 3 [capidrv] kernelcapi 29744 4 [capidrv fcpci capi] Ferner habe auf Grund der AVM-Faq (www.avm.de/de/Service/FAQs/LinuxCAPI4LINUX/3049.php3) darauf aufbauend die i4l-Funktionalität erfolgreich installiert. Dies passierte durch Einbau des folgenden Shellcodes in die Datei /etc/init.d/i4l_hardware und zwar im Abschnitt, welcher kommentarmäßig mit AVM-B1 überschrieben ist. modprobe -v capidrv if test $? -ne 0; then echo "Initialization of the AVM-B1-I4L-Interface failed!" modprobe -r capi exit 1 fi Dann erscheint nach dem erneuten lsmod auch capidrv in der Ausgabe bzw. mein Booten erhalte ich die folgenden ok aussehenden Meldungen: Jan 7 12:02:01 rpflg1 kernel: CAPI-driver Rev 1.21.6.7: loaded Jan 7 12:02:01 rpflg1 kernel: capifs: Rev 1.14.6.7 Jan 7 12:02:01 rpflg1 kernel: capi20: started up with major 68 Jan 7 12:02:01 rpflg1 kernel: kcapi: capi20 attached Jan 7 12:02:01 rpflg1 kernel: capi20: Rev 1.44.6.13: started up with major 68 (middleware+capifs) Jan 7 12:02:01 rpflg1 kernel: fcpci: AVM FRITZ!Card PCI driver, revision 0.1 Jan 7 12:02:01 rpflg1 kernel: fcpci: Loading... Jan 7 12:02:01 rpflg1 kernel: fcpci: Driver 'fcpci' attached to stack Jan 7 12:02:01 rpflg1 kernel: kcapi: driver fcpci attached Jan 7 12:02:01 rpflg1 kernel: fcpci: Auto-attaching... Jan 7 12:02:01 rpflg1 kernel: PCI: Found IRQ 10 for device 00:0a.0 Jan 7 12:02:01 rpflg1 kernel: fcpci: Stack version 3.09-10 Jan 7 12:02:01 rpflg1 kernel: kcapi: Controller 1: fritz-pci attached Jan 7 12:02:01 rpflg1 kernel: kcapi: card 1 "fritz-pci" ready. Jan 7 12:02:01 rpflg1 kernel: fcpci: Loaded. Jan 7 12:02:01 rpflg1 kernel: kcapi: notify up contr 1 Jan 7 12:02:01 rpflg1 kernel: capi: controller 1 up Jan 7 12:02:01 rpflg1 kernel: CSLIP: code copyright 1989 Regents of the University of California Jan 7 12:02:01 rpflg1 kernel: ISDN subsystem Rev: 1.114.6.14/1.94.6.7/1.140.6.8/1.85.6.6/1.21.6.1/1.5.6.3 loaded Jan 7 12:02:01 rpflg1 kernel: kcapi: capidrv attached Jan 7 12:02:01 rpflg1 kernel: kcapi: appl 1 up Jan 7 12:02:01 rpflg1 kernel: capidrv-1: now up (2 B channels) Jan 7 12:02:01 rpflg1 kernel: capidrv-1: D2 trace enabled Jan 7 12:02:01 rpflg1 kernel: capidrv: Rev 1.39.6.6: loaded Jan 7 12:02:01 rpflg1 kernel: ip_tables: (c)2000 Netfilter core team Jan 7 12:02:01 rpflg1 kernel: ip_conntrack (3071 buckets, 24568 max) Jan 7 12:02:01 rpflg1 kernel: isdn: Verbose-Level is 3 ++++++++++++++ So weit so gut +++++++++++++++++ Versuche ich nun mittels einer Fritz!Card von einem NT 4.0/SP6-Rechner aus auf die Linuxbox von firmeninternen Telefon auf die Durchwahl des Linux-Einwahlservers zuzugreifen, dann erhalte ich in /var/log/messages folgende Meldungen. Der ippp-Daemon scheint sich zumelden nimmt aber den Anruf nicht an! Jan 7 13:26:49 rpflg1 kernel: capidrv-1: incoming call ,7,0,28 Jan 7 13:26:49 rpflg1 kernel: isdn_net: Incoming call without OAD, assuming '0' Jan 7 13:26:49 rpflg1 kernel: isdn_net: call from 0,7,0 -> 28 Jan 7 13:26:49 rpflg1 kernel: isdn_net: call from 0 -> 0 28 ignored Jan 7 13:26:49 rpflg1 kernel: isdn_tty: Incoming call without OAD, assuming '0' Jan 7 13:26:49 rpflg1 kernel: isdn_tty: call from 0 -> 28 ignored Jan 7 13:26:49 rpflg1 kernel: capidrv-1: incoming call ,7,0,28 ignored Praktisch gleich sieht es aus, wenn ich mich von ausserhalb von einer W2K-Box aus ebenfalls mit einer Fritz!Card V2.0 und RAS/PPP einzuwählen versuche: Jan 7 22:54:44 rpflg1 kernel: capidrv-1: incoming call 0nummerVonAusserhalb,7,0,28 Jan 7 22:54:44 rpflg1 kernel: isdn_net: call from 0nummerVonAusserhalb,7,0 -> 28 Jan 7 22:54:44 rpflg1 kernel: isdn_net: call from 0nummerVonAusserhalb -> 0 28 ignored Jan 7 22:54:44 rpflg1 kernel: isdn_tty: call from 0nummerVonAusserhalb -> 28 ignored Jan 7 22:54:44 rpflg1 kernel: capidrv-1: incoming call 0nummerVonAusserhalb,7,0,28 ignored Jan 7 22:54:48 rpflg1 kernel: capidrv-1: incoming call 0nummerVonAusserhalb,7,0,28 Jan 7 22:54:48 rpflg1 kernel: isdn_net: call from 0nummerVonAusserhalb,7,0 -> 28 Jan 7 22:54:48 rpflg1 kernel: isdn_net: call from 0nummerVonAusserhalb -> 0 28 ignored Jan 7 22:54:48 rpflg1 kernel: isdn_tty: call from 0nummerVonAusserhalb -> 28 ignored Jan 7 22:54:48 rpflg1 kernel: capidrv-1: incoming call 0nummerVonAusserhalb,7,0,28 ignored Das ist doch nicht nur mir so passiert!??? Danke Georg
Hallo Liste, hallo Arne Dieckmann, zu deiner Mail:
Hallo Liste,
ich habe hier SuSE 7.3 und folgendes Problem:
Nach einer Verbindung zum Internet, klappt nach dem Abbau der Verbindung eine erneute Verbindung nicht mehr. Erst wenn ich i4l neugestartet habe funzt eine neue Einwahl. Was könnte ich hier falsch gemacht oder vergessen haben. Die default route ist richtig gesetzt.
ich hatte dasselbe Problem allerdings mit SuSE 7.2 dazu schrieb ich vor einiger Zeit unter dem Titel: [suse-isdn] anderer Provider - Einwahl 1x und nie wieder -----------zitat------------- ... Ich hab jetzt die Ursache (auf meinem System wenigstens :o)) ) gefunden: Im Script /etc/ip-up ist in Zeile 109 der Aufruf zur Wiederherstellung der Routen mit der "$INTERFACE" variablen versehen. /etc/init.d/route start $INTERFACE ^^^^^^^^^ Ich konnte dem Route-Script nicht entnehmen ob es einen Wert überhaupt abfragen kann (mangels Fachwissen =:o(( ) - aber selbst wenn: es käme es mit dem Eintrag in der /etc/route.conf in's Gehege jedenfalls: seit ich's auskommentiert hab' bin ich hin und weg, die gut das funktioniert. So sieht also die Zeile bei mir aus: /etc/init.d/route start #$INTERFACE .......... -----------zitat-ende------------ hdh fs
participants (4)
-
Arne Dieckmann
-
Friedrich Strohmaier
-
Georg E. Paulusberger
-
Hagen Kühnel