Hallo, ok, noch einmal ausführlicher. Bitte, wenn jemand hier auch nur in etwa Ahnung von DSL hat, meldet euch! Ist wirklich nervig...:-( Kurzbeschreibung des Problems: Beim Versuch, SuSE Linux 8.0 (2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i586 unknown) mit der FritzCard DSL und dem von AVM bereitgestellten Paket zu benutzen, funktioniert der Verbindungsaufbau zwar, aber nach fünf Minuten bis einer Stunde (unregelmäßig) hängt der pppd sich auf. Der pppd läßt sich mit "kill -9" abschießen, aber ein erneuter Verbindungsaufbau funktioniert dann nicht mehr, da die Verbindung nicht sauber abgebaut wurde. Die relevanten Kernelmodule lassen sich mit rmmod nicht mehr entfernen ("in use") und ps aux zeigt einen "dsl_thread" an, der sich mit dem KILL-Befehl NICHT beenden läßt. Fragen: 1. Weiß jemand, wie sich das "Aufhängen" vermeiden läßt? 2. Falls nicht: Was klammert sich bei "pppd call t-dsl" denn so sehr in den Speicher, daß pppd keine zweite Verbindung mehr bekommt? Wenn ich das Aufhängen schon nicht wegkriege, dann würde ich wenigstens gerne wissen, mit welcher Befehlsabfolge ich den Speicher wieder freikriege, um einen Neustart zu vermeiden. Auführlichere Beschreibung mit Logs: Ich habe von SuSE 7.0 auf SuSE 8.0 geupdatet, um die FritzCard-DSL zum Laufen zu bekommen. Das hat mit den AVM-Treibern auch funktioniert. Einziges Problem: Aus mir unerfindlichen Gründen bricht die Verbindung ab oder genauer: die Verbindung scheint erhalten zu bleiben, aber es gehen keine Pakete mehr raus. pppd sagt konkret: No response to 10 echo-requests Serial link appears to be disconnected. capiplugin: phase terminate (was running). cbcp_lowerdown capiplugin: phase network (was terminate). Script /etc/ppp/ip-down started (pid 4272) capiplugin: phase terminate (was network). sent [LCP TermReq id=0x2 "Peer not responding"] sent [LCP TermReq id=0x3 "Peer not responding"] capiplugin: phase dead (was terminate). controller 2: listen_change_state 0 -> 1 ncci_change_state:0x10102 4 -> 6 event=12 contr 2: listenconf Info=0x0000 (No additional information) infomask=0x144 cipmask=0x0 capimask2=0x0 controller 2: listen_change_state 1 -> 0 capiplugin: disconnectall failed Die Echo-Requests habe ich von 3 (Standard) auf 10 erhöht. Danach bricht pppd aber nicht ab, sondern verharrt, als würde er auf irgendetwas warten. Also drücke ich CTRL und C, was zu folgender Meldung führt: tcflush failed: Bad file descriptor ioctl(TIOCSETD, N_TTY): Bad file descriptor ioctl(TIOCNXCL): Bad file descriptor(9) controller 2: listen_change_state 0 -> 1 ncci_change_state:0x10102 6 -> 7 event=10 ncci_change_state:0x10102 7 -> 0 event=13 plci_change_state:0x102 3 -> 7 event=8 contr 2: listenconf Info=0x0000 (No additional information) infomask=0x144 cipmask=0x0 capimask2=0x0 controller 2: listen_change_state 1 -> 0 plci_change_state:0x102 7 -> 8 event=9 plci_change_state:0x102 8 -> 0 event=11 capiplugin: disconnect(local): "" -> "" outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x3312) - No additional information capiplugin: exit Dann verabschiedet sich pppd endlich ganz. Ein erneuter Verbindungsaufbau ist nicht möglich: plci_change_state:0x102 1 -> 2 event=3 plci_change_state:0x102 2 -> 3 event=6 ncci_change_state:0x102 0 -> 1 event=1 ncci_change_state:0x10102 1 -> 3 event=3 ncci_change_state:0x10102 3 -> 7 event=10 ncci_change_state:0x10102 7 -> 0 event=13 plci_change_state:0x102 3 -> 7 event=8 plci_change_state:0x102 7 -> 8 event=9 plci_change_state:0x102 8 -> 0 event=11 capiplugin: disconnect(remote): "" -> "" outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x0000) - No additional information capiplugin: couldn't make connection controller 2: listen_change_state 0 -> 1 contr 2: listenconf Info=0x0000 (No additional information) infomask=0x144 cipmask=0x0 capimask2=0x0 controller 2: listen_change_state 1 -> 0 capiplugin: exit Woran könnte das liegen? Ist ziemlich nervig, wenn man den Computer arbeiten lassen will, aber vor dem Monitor immer darauf achten muß, daß er nicht abkackt. Außerdem stehe ich ein bißchen auf dem Schlauch: Warum funktioniert der erneute Verbindungsaufbau dann nicht mehr? Provisorisch fahre ich dann immer wieder runter und starte neu, alte Angewohntheit aus Windows-Zeiten, aber man kann bestimmt was Vernünftigeres machen, nicht wahr? ;-) Mein System: eine alte Kiste, AMD-266, 64MB RAM, auf den ISA-Steckplätzen noch eine alte Soundkarte (Soundblaster AWE64, war früher echt ein super Teil:)), restliche Karten sind PCI. Hier die Liste: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo VP1/VPX] (rev 23) Flags: bus master, 66Mhz, medium devsel, latency 32 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 25) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at 6000 [size=16] 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS) Flags: medium devsel, IRQ 11 I/O ports at 6200 [size=32] 00:0a.0 Multimedia controller: Philips Semiconductors: Unknown device 5402 (rev 82) Subsystem: AVM Audiovisuelles MKTG & Computer System GmbH: Unknown device 0f00 Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at e0000000 (32-bit, non-prefetchable) [size=8M] Memory at e1800000 (32-bit, non-prefetchable) [size=2M] 00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG [Mystique] (rev 03) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. MGA-1084SG Mystique Flags: bus master, VGA palette snoop, stepping, medium devsel, latency 32, IRQ 9 Memory at e0800000 (32-bit, prefetchable) [size=8M] Memory at e1a00000 (32-bit, non-prefetchable) [size=16K] Memory at e1000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at <unassigned> [disabled] [size=64K] Falls ihr noch Infos braucht, um weiterzuhelfen, immer her mit euren Fragen. Ich wäre froh, wenn DSL und Linux irgendwann mal vernünftig zusammenarbeiten würden. Ich habe noch ein Problem, dafür gibt es bestimmt eine andere Liste, aber möglicherweise kann mich jemand auf Hilfe-Ressourcen hinweisen: Seit dem Update arbeitet sendmail nicht mehr. Bei meinen vorherigen Konfigurationen (unter SuSE 6.0, 6.3, 6.4. und 7.0) hat /etc/mail/genericstable meine Userkennung durch meine E-Mail-Adresse für den Versand über den GMX-Mailserver ersetzt. Obwohl meine Konfiguration exakt mit den Tips in der SuSE-Support-DB (stark_*.html) übereinstimmt, "überspringt" er die Ersetzung immer, mit der Folge, daß der Mailserver den User foo@local natürlich ablehnt. Vorschläge? Vielen Dank für eure Hilfe. Ich bin gespannt, was an Tips kommt und hoffe, es hilft mir weiter.:) Tschüs, Benjamin.