ISDN Modem unter Debian

[filou]

Hallo,

ich habe kein wirkliches Problem, jedoch möchte ich statt eine ISDN Karte in Servern, eine externes ISDN - Modem verwenden.

Jetzt suche ich dazu Erfahrungen, Anregungen..Installationsanleitungen in Verbindung mit Debian Woody.

Das Problem ist, wenn mal eine ISDN Karte abraucht, muss jedesmal der Server ausgeschaltet werden. Das soll verhindert werden. Ich denke, externe Hardware löst dieses Problem, oder ?

mfg

[Diablo]

Also Ich hab noch nie von jemanden gehört dass ihm die ISDN Karte abgeraucht ist. Denke auch dass das nicht sehr oft passiert. Wenn doch, dann dauert der Umbau auch nicht sehr lange.

Würde eher auf eine interne Karte setzen.

Wobei: Gibt es eigentlich ein externes "ISDN Modem"? Wär mir gar nix bekannt...

[Bert]

Es gibt auch keine interen ISDN Modems. Da bei ISDN ja nichts MOduliert/DEModuliert wird.

Mir ist auch noch nie eine ISDN Karte abgeraucht.

[Diablo]

eben, dann müsstest dir einen Externen RAM, externe CPU, Grafikkarte, usw... kaufen. Also um die ISDN Karte würd ich mir die wenigsten Sorgen machen.

[filou]

Ok, ok,ok - schlagt mich

nein im Ernst - ich habe immer häufiger das Problem, das interne ISDN Karten keine Einwahl mehr zulassen. Manchmal ghet es nach einem Neustart wieder, manchmal nicht.

Die wirkliche Ursache habe ich bis jetzt nicht gefunden.

Deshalb kam mir der Gedanke eine externe ISDN Karte zu nehmen. Also AMV Fritz USB..oder so'n Teil. Damit ich mal schnell die ISDN Geschichte tauschen kann ohne den Server anzuschalten.

Der Server rennt halt 24/7 und übernimmt Steueraufgaben. Wenn der down is, kann keiner mehr arbeiten. Deshalb ja eine externe Lösung....

Kann ja auch sein, das ich jedesmal was flasch konfiguriere was nach 300 Tagen uptime dann nimmer geht ... Keine Ahnung.....vielleicht kennt wer Rat, Erfahrungen mit ner PCI V2.0 Fritz Card.

mfg

[Raoul]

Vielleich erzählst Du uns mal, was mit der FritzCard nicht funktioniert?! Wenn sie Dir das nächste mal "nach 300 Tagen" abraucht, guck mal ins Syslog

Ich habe eine FritzCard DSL, die problemlos im Dauerbetrieb ist, allerdings keine 300 Tage am Stück.

Wenn Du isdn4linux paralell zur capi nutzt, solltest Du diesen Patch verwenden.

Raoul

[filou]

Tja, wenn ich das so genau wüsste was nicht funktioniert....

Ich kann mich halt nimmer auf den Server einwählen. Manchmal hilft da ein Serverneustart. Aber nicht immer. Das syslog ist da wenig aussagekräftig - wenn ich mich denn nach nem Neustart wieder einwaählen kann, finde ich nix verdächtiges.

mfg

[Raoul]

Wenn sich der pppd nach einer Zwangstrennung weghängt, sollte etwas wie

"pppd: modem hangup
pppd: connection closed by remote Host": <Errorcode>

im syslog stehen (frei nach Gedächtnis). Was man dagegen tun kann habe ich hier beschrieben. Die Errorcodes kann man außerdem in der Datei CAPI20_Errormessages.txt aus dem AVM Treiberpaket nachschauen.

Wenn sich die Fritzcard weghängt sieht das bei mir so aus (weil's schön ist mal in voller Länge, kann man eigentlich nicht übersehen):

Mar 13 22:18:10 guru kernel: kernel BUG at skbuff.c:316!
Mar 13 22:18:10 guru kernel: invalid operand: 0000
Mar 13 22:18:10 guru kernel: iptable_mangle ipt_MASQUERADE iptable_natipt_TCPMSS ipt_LOG ipt_multiport ipt_REJECT ipt_state ip_conntrackiptable_filter ip_tables ppp_synctty ppp_generic
Mar 13 22:18:10 guru kernel: CPU: 0
Mar 13 22:18:10 guru kernel: EIP: 0060:[<c01f4b9f>] Tainted: P
Mar 13 22:18:10 guru kernel: EFLAGS: 00010082
Mar 13 22:18:10 guru kernel:
Mar 13 22:18:10 guru kernel: EIP is at __kfree_skb [kernel] 0x12f(2.4.22-1.2174.nptl)
Mar 13 22:18:10 guru kernel: eax: 00000045 ebx: 01022c31 ecx:00000001 edx: c2758000
Mar 13 22:18:10 guru kernel: esi: 00010001 edi: c4ac2f40 ebp:c2759cec esp: c2759cb4
Mar 13 22:18:10 guru kernel: ds: 0068 es: 0068 ss: 0068
Mar 13 22:18:10 guru kernel: Process fcdsl_thread (pid: 1623,stackpage=c2759000)
Mar 13 22:18:10 guru kernel: Stack: c027cc80 c4ad0726 c2615e84 c4ad0726c1157480 00000202 c2759cec c4ad0677
Mar 13 22:18:10 guru kernel: c3f96000 00000007 c2615364 00000010c2783004 00000001 c2759d3c c4acf146
Mar 13 22:18:10 guru kernel: c2615364 00000001 00010102 00002c31c2783004 00000000 c2759d3c c4affc9e
Mar 13 22:18:10 guru kernel: Call Trace: [<c4ad0726>] queue_conf[fcdsl] 0xe6 (0xc2759cb8)
Mar 13 22:18:10 guru kernel: [<c4ad0726>] queue_conf [fcdsl] 0xe6(0xc2759cc0)
Mar 13 22:18:10 guru kernel: [<c4ad0677>] queue_conf [fcdsl] 0x37(0xc2759cd0)
Mar 13 22:18:10 guru kernel: [<c4acf146>] msg2capi [fcdsl] 0x3a6(0xc2759cf0)
Mar 13 22:18:10 guru kernel: [<c4affc9e>] CAPI_CMSG_2_MESSAGE_INTERNAL[fcdsl] 0x4e (0xc2759d10)
Mar 13 22:18:10 guru kernel: [<c4ad9502>] CA_PUT_MESSAGE [fcdsl] 0x12(0xc2759d40)
Mar 13 22:18:10 guru kernel: [<c4ae566f>] CAPI_PUT_CMSG_INTERNAL [fcdsl]0xf (0xc2759d60)
Mar 13 22:18:10 guru kernel: [<c4aedc61>] BHandler [fcdsl] 0x3a1(0xc2759d80)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759da4)
Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53(0xc2759dc0)
Mar 13 22:18:10 guru kernel: [<c4b67e5f>] .rodata.str1.1 [fcdsl] 0x1049(0xc2759e88)
Mar 13 22:18:10 guru kernel: [<c4ae0b7c>] CAPI_Dequeue32 [fcdsl] 0x1c(0xc2759e90)
Mar 13 22:18:10 guru kernel: [<c4b96b40>] _Q_CAPI [fcdsl] 0x0(0xc2759e94)
Mar 13 22:18:10 guru kernel: [<c4aed5fa>] CAPI_Handler [fcdsl] 0x3a(0xc2759eb0)
Mar 13 22:18:10 guru kernel: [<c4ae0425>] _CM_Schedule [fcdsl] 0xc5(0xc2759ee0)
Mar 13 22:18:10 guru kernel: [<c4ba1220>] Block_RxBuffer [fcdsl] 0x240(0xc2759eec)
Mar 13 22:18:10 guru kernel: [<c4b96d80>] CMSG.5 [fcdsl] 0x0(0xc2759ef0)
Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53(0xc2759f00)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759f04)
Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53(0xc2759f10)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759f14)
Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53(0xc2759f20)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759f24)
Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53(0xc2759f30)
Mar 13 22:18:10 guru kernel: [<c4ad0d35>] os_gettimeofday [fcdsl] 0x15(0xc2759f40)
Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53(0xc2759f50)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759f54)
Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53(0xc2759f60)
Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0(0xc2759f64)
Mar 13 22:18:10 guru kernel: [<c4b32e36>] timercb_docallouts [fcdsl]0x26 (0xc2759f80)
Mar 13 22:18:10 guru kernel: [<c4ad9431>] EnterCritical [fcdsl] 0x11(0xc2759f90)
Mar 13 22:18:10 guru kernel: [<c4ad9451>] LeaveCritical [fcdsl] 0x11(0xc2759fa0)
Mar 13 22:18:10 guru kernel: [<c4b05cf9>] B2_PPPoETimerPolling [fcdsl]0x19 (0xc2759fb0)
Mar 13 22:18:10 guru kernel: [<c4ad0cba>] os_timer_poll [fcdsl] 0x5a(0xc2759fb8)
Mar 13 22:18:10 guru kernel: [<c4ae053b>] CM_Schedule [fcdsl] 0x3b(0xc2759fd0)
Mar 13 22:18:11 guru kernel: [<c4acf3f0>] sched_thread [fcdsl] 0x0(0xc2759fd8)
Mar 13 22:18:11 guru kernel: [<c4acf48f>] sched_thread [fcdsl] 0x9f(0xc2759fe0)
Mar 13 22:18:11 guru kernel: [<c01071fd>] kernel_thread_helper [kernel]0x5 (0xc2759ff0)
Mar 13 22:18:11 guru kernel: Code: 0f 0b 3c 01 63 ba 27 c0 58 5a 8b 5424 08 e9 ce fe ff ff 8d
Mar 13 22:18:26 guru pppd[3864]: No response to 3 echo-requests
Mar 13 22:18:26 guru pppd[3864]: Serial link appears to be disconnected.
Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase terminate (wasrunning).
Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase network (wasterminate).
Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase terminate (wasnetwork).
Mar 13 22:18:32 guru pppd[3864]: capiplugin: phase dead (was terminate).
Mar 13 22:18:42 guru pppd[3864]: capiplugin: disconnectall failed

Die Fehlermeldung stammt allerdings nicht von einem Debian System sondern von Fedora Core. Dort habe ich seit Anwendung dieses Patches keine Probleme mehr, unter Debian habe ich den Treiber (noch) nicht gepatcht. Außerdem weiß bezweifle ich, daß er mit der Fritz PCI funktioniert.

Anyway: Wenn sich das Ding weghängt, dann richtig: Dann ist ein Neustart fällig, und das wird auch bei einer externen Lösung wie der FritzUSB Karte passieren, weil es den Kernel betrifft. Wenn Du was für eine 100% unternehenskritische Umgebung (von wegen 300 Tage Uptime) suchst, nimm eine ISDN Karte, die mit dem klassischen Hisax Treiber arbeitet oder ein gutes altes analogs Modem.

Gruß

Raoul

P.S.: Es ist mir immer schleierhaft, wie Leute auf so unglaubliche Laufzeiten kommen. Innerhalb der letzten 300 Tage ist doch garantiert mindestens ein sicherheitskritisches Kernelupdate gewesen, nicht wahr

[vajk]

.. hab unter vmware mit gastos w2k sp4 das problem, daß dort die Fritz!card USB erkannt aber der Treiber nicht gestartet wird - hat hierzu jemand eine Idee ?

Liebe Grüße,
Vajk

[Raoul]

Code: Alles auswählen

/etc/ini.d.d/isdnactivecards

start oder

Code: Alles auswählen

capiinit

gemacht? Was sagen die, wir das Modul geladen? Capiinfo?

Raoul

NACHTRAG (falls es einer wissen will ):

Die Fehlermeldung stammt allerdings nicht von einem Debian System sondern von Fedora Core. Dort habe ich seit Anwendung dieses Patches keine Probleme mehr, unter Debian habe ich den Treiber (noch) nicht gepatcht.

Gestern hatte auch das Debian System einen Kernel Oops, deshalb habe ich den Treiber jetzt doch gepatched. Das Problem ist entweder der capidrv oder eine aktuellere Version des pppd, den ich für M$ PPTP (schluck) installiert habe.