Howto: ISDN Fritz PCI 2.0 unter debian
Diese Anleitung beschreibt, wie eine AVM Fritz PCI 2.0 ISDN Karte unter debian unter Verwendung von CAPI4Linux in Betrieb genommen werden kann. Angewandt wurde diese Vorgehensweise unter Woody (debian 3.0) mit Kernel 2.4.18 sowie Sarge mit Kernel 2.4.20.

Von Gert Brinkmann

Inhalt

    1. Fritz Treiber beschaffen und entpacken
    2. Kernel für CAPI vorbereiten
        2.1. Anderen Kernel installieren
        2.2. Alternativ: Kernel selber kompilieren
    3. CAPI installieren
    4. fritz-Treiber kompilieren und installieren
    5. CAPI konfigurieren und starten
    6. pppd konfigurieren und starten
        6.1. Konfiguration: Username, Passwort, Telefonnummer
        6.2. Online gehen
        6.3. Domain Name Server
        6.4. Online on demand
        6.5. Offline gehen
        6.6. Fehlermeldung "diald[207]: No devices free to call out on"
        6.7. ISDN Multi-Link
    7. FritzCard DSL

Anmerkung: Ich kann leider keine Garantie dafür übernehmen, daß diese Beschreibung vollständig und korrekt ist. Aber auf jeden Fall werden einige Dinge erwähnt, die mir etwas Zeit gekostet haben, sie herauszufinden. Falls jemand diese Anleitung für nützlich hält, oder auch Verbesserungsvorschläge bzw. Korrekturen anbringen möchte, würde ich mich über Feedback freuen (E-Mail-Adresse auf der Startseite). Die aktuelle Version dieses Howtos findet sich auf www.whatis.mynetcologne.de. Desweiteren übernehme ich keine Verantwortung für Schäden (an der eigenen Person, Hardware oder Systeminstallation, ...), die auftreten, wenn man versucht, dieser Anleitung zu folgen.

Auch soll erwähnt sein, daß es inzwischen möglich sein soll, die genannte Karte unter ISDN4Linux in Betrieb zu nehmen. Den einzigen Hinweis dazu habe ich in der FAQ auf den Seiten des ISDN4Linux Projektes gefunden: "The newest Fritz! PCI card (v2.0) is now supported by a new driver, however it has not yet been tested thoroughly." Ich habe mich mit dem Thema aber noch nicht tiefergehend befasst. Nachtrag: Wenn man dies probieren möchte, ist es wichtig, nicht den "hisax"-Treiber zu verwenden, sondern den "hisax_fcpcipnp"! Dieser Treiber kann entweder durch Eintragen in /etc/modules hart verdrahtet eingeladen werden, oder alternativ erst, wenn er benötigt wird. Dafür müssen die richtigen Einträge in der /etc/modules.conf vorhanden sein. Diese werden dort aber nicht direkt eingetragen, sondern über folgenden Mechanismus (alles als Knecht root-Recht durchführen):

Ich bekam auch den Hinweis, dass unter http://ixi.thepenguin.de/ weitere Informationen zu finden sind (Stichworte: capidrv, ippp0, vbox). Desweiteren könnte http://www.pl-berichte.de/t_netzwerk/debian-isdn.html interessant sein.

Nun aber zu der auf CAPI basierenden Lösung.

1. Fritz Treiber beschaffen und entpacken

Hier stößt man direkt auf das erste Problem. Der Fritz Treiber muß von http://www.avm.de/ gezogen werden, was schwierig ist, ohne online zu sein. Dieses Problem muß also über einen schon online fähigen Rechner gelöst werden...

Bei der im Download-Bereich der AVM-Web-Seite geforderten Produktwahl muß "FRITZ!Card PCI" ausgewählt werden. Die PCI 2.0 Karte ist nicht speziell genannt. Zum Zeitpunkt der Howto-Erstellung findet sich der Treiber unter http://www.avm.de/ftp/cardware/fritzcrd/linux/index.html auf dem AVM Server. Aktueller scheint inzwischen die URL ftp://ftp.avm.de/cardware/fritzcrd.pci/linux/. Aus einem der Verzeichnisse "suse.xy" kann die Datei "fcpci-suse*.tar.gz" gezogen werden. An dem Kürzel "suse" darf man sich nicht stören. In der Datei ist neben der für Suse vorkompilierten Version auch ein Teil des Source-Codes zum Kompilieren für andere Distributionen enthalten.

Achtung: Mir ist berichtet worden, daß es mit manchen Versionen des Treibers zu Systemabstürzen (oder Hängern) kommen kann. Angeblich hilft dann der Wechsel auf eine andere Treiberversion. Leider gibt es keine generelle Aussage, welche Version die bessere ist. Mal funktioniert die eine, mal die andere. Ich würde mit der aktuellsten Version beginnen, zu testen. Unter Woody hatte ich "fcpci-suse8.0-03.09.10.tar.gz" ohne Probleme im Einsatz.

Vielleicht liegen die Probleme aber bei debian/Sarge Usern auch woanders: Wenn ein Kernel-Modul mit einer anderen Version des gcc Compilers übersetzt wird, als es der Kernel wurde, kann es zu solchen Problem kommen. AFAIK wurde der 2.4.20-686-1 Kernel, den ich benutze, mit gcc 2.95 übersetzt. Mit

apt-cache search --names-only gcc | sort finden sich die möglichen gcc Versionen, die sich dann wie gewohnt mit "apt-get install" installieren lassen.

In einem Fall, der mir berichtet wurde, war im Kernel fälschlicherweise SMP Support aktiviert. Nach Ausschalten desselben stürzte der Rechner beim Laden des fcpci Moduls nicht mehr ab.

Desweiteren muß darauf geachtet werden, ob der Treiber unter Kernel 2.4 oder 2.6 eingesetzt werden soll. Neuere Versionen des fritz-Treibers (ich meine, ab SuSe9.1, vielleicht aber auch schon 9.0?) sind für Kernel 2.6 bestimmt und funktionieren nicht mehr unter Kernel 2.4. Genauso können wohl die alten Treiber nicht unter Kernel 2.6 verwendet werden. Dazu bekam ich dann noch folgende E-Mail von jemandem, der Kernel 2.4.26-2-686 unter debian/Woody einsetzte:

Ich hab jetzt mal das Paket fuer 8.2 gezogen. Das funktioniert schon eher, bedarf aber einer zusaetzlichen Aenderung: --- fritz.orig/src.drv/defs.h Tue Jul 8 00:02:00 2003 +++ fritz/src.drv/defs.h Sat Jul 10 23:36:17 2004 @@ -86,7 +86,7 @@ #endif #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0) -typedef void irqreturn_t; +/* typedef void irqreturn_t; */ #define IRQ_NONE #define IRQ_HANDLED sonst meckert der Compiler, irqreturn_t waere schon mal deklariert.

Die Datei "fcpci-suse*.tar.gz" speichert man beispielsweise unter "/usr/local/src/" und entpackt sie dort mit "tar xzf fcpci-suse*.tar.gz". Dadurch wird das Verzeichnis "fritz" angelegt, in dem sich der Treiber-Sourcecode findet. Es ist ratsam, das Verzeichnis umzubenennen, damit es der korrekten Version zugeordnet werden kann, falls man tatsächlich verschiedene Versionen ausprobieren möchte. Beispielsweise also in "fritz_suse8.0".

Kleiner Tipp: Hat man die Datei mit Hilfe einer DOS/Windows-Diskette an Land gebracht, so hilft ein "mdir a:" und "mcopy a:fcpci*.tar.gz /usr/local/src/" weiter.

2. Kernel für CAPI vorbereiten

Leider ist CAPI-Unterstützung im unter debian/Woody per default installierten Kernel-2.4.18-bf2.4 nicht aktiviert. Es gibt zwei verschiedene Möglichkeiten, CAPI Unterstützung anzuschalten: Entweder per einfachem Update auf ein anderes kernel-image oder durch Selbstkompilieren des Kernels.

2.1. Anderen Kernel installieren

Der Wechsel auf einen anderen Kernel ist unter debian recht einfach. Man muss sich lediglich den richtigen Kernel suchen und zu diesem dann das kernel-image und die kernel-header installieren.

Mit

apt-cache search --names-only kernel-image | sort werden alle verfügbaren kernel-images aufgelistet. Mit apt-cache show Packetname werden unter anderem die Informationen angezeigt, für welchen Prozessor das Packet gedacht ist. Bei einen Rechner mit einzelner aktueller Intel-CPU sollte kernel-image-2.4.18-686 gewählt werden, bei einer AMD-CPU dagegen kernel-image-2.4.18-k7. (Alternativ bei debian Sarge auch das jeweilige Image der Kernel Version 2.4.20). Außerdem müssen die dazu passenden kernel-header installiert werden, deren Packet bis auf "headers" statt "image" exakt den gleichen Namen tragen.

apt-get install kernel-image-2.4.18-686 kernel-headers-2.4.18-686 führt den Kernel-Wechsel dann durch. (Hier im Beispiel für eine Intel Plattform). Werden bei der Kernel-Installationen Hinweise auf dem Bildschirm ausgegeben, sollte man diese unbedingt durchlesen und befolgen. Ansonsten kann es sein, daß der Rechner beim nächsten Neustart nicht mehr hochfahren kann. Beispielsweise ist es beim Installieren des Kernels 2.4.20 nötig, einen Eintrag "initrd=/initrd.img" in der Datei /etc/lilo.conf vorzunehmen. Bei mir sieht der entsprechende Abschnitt der Datei dann wie folgt aus: image=/vmlinuz label=Linux read-only initrd=/initrd.img # restricted # alias=1

Nach Installation des Kernels muß der Rechner neu gestartet werden, damit der neue Kernel aktiv ist und die spätere Fritz-Treiber-Installation in das richtige Kernel-Modul-Verzeichnis installiert wird.

2.2. Alternativ: Kernel selber kompilieren

Dieser Abschnitt des Howtos stammt noch aus der Zeit als ich nicht wusste, daß es reicht, einfach ein anderes Kernel-Image zu installieren. Für den Fall, daß jemand mit einem vorgebauten Kernel nicht glücklich wird, belasse ich diesen Abschnitt weiterhin in dieser Anleitung. Im Normalfall kann dieser Teil also übersprungen werden und mit der CAPI Installation fortgefahren werden.

Falls aber der Kernel doch selbst konfiguriert und kompiliert werden soll, so findet sich in der Datei "src.sys/capi_modules.txt" des fritz-Packets eine genauere Information, welche Kernel-Optionen eingeschaltet werden müssen:

CONFIG_EXPERIMENTAL=y ... <M> CAPI2.0 support [*] Verbose reason code reporting (kernel size +=7K) [*] CAPI2.0 Middleware support (EXPERIMENTAL) <M> CAPI2.0 /dev/capi support [*] CAPI2.0 filesystem support <M> CAPI2.0 capidrv interface support ... Im Internet finden sich viele kernel-Build-Howtos, weswegen ich hier nur kurz zusammengefasst aufschreibe, wie ich vorgegangen bin:

Zu den Kernel-Einstellungen habe ich noch folgende E-Mail erhalten, die ich nicht weiter geprüft habe. Zitat:

ich musste bei meinem Kernel noch eine Option hinzufügen, damit ich mich mit dem pppd einwählen kann - das war die Option "PPP support for synch tty ports". Ohne die Option kam bei der Einwahl immer die Fehlermeldung "Couldn't set PPP line discipline". Das vielleicht nur als kleine Ergänzung zu deinem ansonsten absolut perfekten Artikel :-)

3. CAPI installieren

Ich habe lange gebraucht, um herauszufinden, daß nun noch einige Packete installiert werden müssen. Speziell daß ich das Packet "isdnactivecards" benötige, obwohl die Fritz PCI 2.0 eine passive Karte ist, war ziemlich verwirrend. Vielleicht hätte ich beim Kernel-Bauen besser aufpassen müssen, wo CAPI auch in dem Untermenü für "Active ISDN cards" angeschaltet wurde.

apt-get install isdnactivecards pppdcapiplugin Das Packet "libcapi20" (bzw. "libcapi20-2" oder ähnlich) sollte damit unter anderem automatisch mitinstalliert werden. Wenn hier nun Fehlermeldungen beim Starten von CAPI erscheinen, ist das ok, wir sind ja noch nicht fertig.

4. fritz-Treiber kompilieren und installieren

Falls eine andere als die voreingestellte C-Compiler-Version benötigt wird (siehe Abschnitt zum fritz-Treiber-Download), so kann die Auswahl beispielsweise mit

export CC="/usr/bin/gcc-2.95" erfolgen. Diese Einstellung ist nur für die aktuelle Shell gültig. Um herauszufinden, mit welcher gcc-Version der momentan gebootete Kernel kompiliert wurde, ruft man am Besten cat /proc/version auf. Ansonsten findet man vielleicht auch Hinweise in der Datei /usr/share/doc/kernel-image-2.4.20-1-686/Changes.gz (die kernel-image Versionsnummer im Pfad muß natürlich ggf. angepaßt werden). gcc-2.95 kompiliert bei mir den Fritz-Treiber ohne Fehler, während gcc-3.3 einige Warnings wirft. Im Zweifelsfall sollte also gcc-2.95 benutzt werden. Unter debian/Woody muß man sich hierum nicht kümmern, da wird automatisch der richtige Compiler benutzt.

Damit der Compiler die Kernel-Header findet, muß ggf. noch ein Eintrag in der Datei src.drv/makefile des Fritz-Packets geändert werden. Es gibt dort eine Zeile, in der die Variable KRNLINCL gesetzt wird. Dies muß auf eine der folgenden Möglichkeiten gesetzt werden:

KRNLINCL = /usr/src/kernel-headers-`uname -r`/include #KRNLINCL = /lib/modules/`uname -r`/build/include #KRNLINCL = /usr/src/linux/include Die Variante, die bei Aufruf mit "ls" keinen Fehler wirft, ist die richtige. ls /usr/src/kernel-headers-`uname -r`/include ist bspw. korrekt, wenn ein neues Kernel-Image per debian Packet installiert wurde. Die unterste der drei Alternativen kann benutzt werden, wenn in /usr/src ein symbolischer Link linux auf das Unterverzeichnis mit den Kernel-Source- oder Header-Dateien gesetzt wurde.

Nach dieser ganzen Vorarbeit sollte der Treiberbau recht einfach zu erledigen sein, wenn in der Datei /usr/local/src/fritz/make.card der Eintrag für den Kartentreiber korrekt ist. Bei mir war es aber mit "CARD=fcpci" korrekt voreingestellt.

su (falls man nicht schon "root" ist) cd /usr/local/src/fritz/ make clean make make install depmod -a

Ein unschöne Sache, die bei mir nun auftrat, war eine "unresolved symbols" Meldung des fcpci Moduls, die ein "depmod -a", das auch bei jedem Systemstart aufgerufen wird, gemeldet hat:

# depmod -a depmod: *** Unresolved symbols in /lib/modules/2.4.20-1-686/misc/fcpci.o Trotz dieser Meldung funktionierte der Treiber aber seltsamerweise. Dank eines Hinweises auf der CAPI-Seite von Steffen Barszus hat sich auch hierfür eine Lösung gefunden. Man muß die fritz-Datei src.drv/makefile editieren. Dort gibt es direkt hinter der Definition der KRNLINCL Variablen folgende Zeilen, die im Original so aussahen: # As propsed by /usr/include/linux/version.h... DEFINES = -DMODULE -D__KERNEL__ -DNDEBUG \ -D__$(CARD)__ -DTARGET=\"$(CARD)\" CCFLAGS = -c $(DEFINES) -O2 -Wall -I $(KRNLINCL) und von mir geändert wurden in DEFINES = -DMODULE -DMODVERSIONS -D__KERNEL__ -DNDEBUG \ -D__$(CARD)__ -DTARGET=\"$(CARD)\" CCFLAGS = -c $(DEFINES) -march=i686 -O2 -Wall -I $(KRNLINCL) \ -include $(KRNLINCL)/linux/modversions.h Ggf. muss der CPU-Typ "i686" angepasst werden. Im Zweifelsfall setzt man diesen vermutlich am Besten auf "i386". Danach nochmals ein "make clean; make; make install" und ein "depmod -a" hat nicht mehr gemeckert.

5. CAPI konfigurieren und starten

Nun müssen nur noch in der Datei "/etc/isdn/capi.conf" alle Zeilen auskommentiert werden, bis auf die für die Karte "fcpci": 
# card          file    proto   io      irq     mem     cardnr  options
fcpci           -       -       -       -       -       -
Damit sollte CAPI gestartet werden können, was bei einem Reboot automatisch erfolgt. Ohne Neustart des Rechners geht es mit Hilfe von 
capiinit stop
capiinit start

6. pppd konfigurieren und starten

6.1. Konfiguration: Username, Passwort, Telefonnummer

Als letztes muß für seinen Provider (ich nenne ihn hier "foo") eine Konfigurationsdatei angelegt werden. Dafür wechselt man als User "root " nach /etc/ppp/peers/isdn/ und benutzt eine dort schon vorhandene Datei als Vorlage. Bspw: cp arcor foo. Nun editiert man die Datei foo und passt die Werte für die Optionen "user", "password" und "number" an, die wohl ziemlich selbsterklärend sein dürften. Bei Fragen hilft vielleicht "man pppd" und "man capiplugin". Sicherheitshinweis: Das Passwort sollte nur für den ersten Test in diese Datei eingetragen werden. Da die Datei für jeden lesbar ist, kann auch jeder das Passwort sehen, der auf dem Rechner eingeloggt ist. Stattdessen sollte, wenn alles läuft, das Passwort aus dieser Datei wieder herausgenommen werden und stattdessen in eine der beiden Dateien /etc/ppp/chap-secrets oder /etc/ppp/pap-secrets eingetragen werden. Welche Datei benötigt wird, hängt von der Verbindungsart ab. Wenn man sich, so wie ich, nicht sicher ist, welche Datei die richtige ist, wird das Passwort einfach in beide Dateien eingetragen. Beispieleintrag: "user" * "password"

6.2. Online gehen

Sind diese Änderungen gespeichert, sollte ein pppd call isdn/foo (ggf. als user root) die Einwahl ins Internet vollziehen. Parallel dazu sollten die Ausgaben in dem Logfile "/var/log/syslog" mitverfolgt werden, um zu sehen, was passiert. Alternativ kann dieser Aufruf auch mit pon isdn/foo abgekürzt werden. Ganz bequem ist es, wenn die Konfigurationsdatei statt /etc/ppp/peers/isdn/foo in /etc/ppp/peers/provider umbenannt wird bzw. letzteres ein Sym-Link auf die Konfigurationsdatei ist. Diese Datei wird von pon benutzt, wenn nichts anderes angegeben wird, so dass mit einem einfachen pon die Verbindung gestartet werden kann.

6.3. Domain Name Server

Scheint alles zu funktionieren, lediglich der Browser kann keine Web-Site finden, so muß ggf. noch der DNS-Server konfiguriert werden. Dafür gibt es die Option "usepeerdns", die in der "foo"-Konfigurationsdatei eingetragen werden sollte (Wahrscheinlich ist dieser Eintrag schon vorhanden. Wenn nicht in der Datei foo, dann vielleicht in der globalen Konfigurationsdatei /etc/ppp/options, die die default-Optionen für alle Verbindungskonfigurationsdateien aufnimmt.) Damit werden die DNS-Adressen automatisch ermittelt und in die Datei /etc/resolv.conf eingetragen. Funktioniert dies nicht, können die Domain-Name-Server manuell in /etc/resolv.conf eingetragen werden.

6.4. Online on demand

Da ich "on demand" online gehen möchte, also dann, wenn ich bspw. im Browser einen Link anklicke, und nach einer bestimmten "idle"-Zeit ohne Datenübertragung wieder offline sein möchte, mußte ich manuell die DNS-Einträge in der resolv.conf vornehmen. Der DNS-Lookup triggert dann das Online-Gehen des pppd an. Es schadet aber nicht, zusätzlich auch die Option "usepeerdns" einzusetzen. Dann wird die resolv.conf Datei für die Dauer der Online-Verbindung neu erstellt, so daß alle aktuellen DNS-Server eingetragen sind. Allerdings habe ich häufig das Problem, dass die erste Online-Aktion scheitert. Der Browser (oder ein anderes Programm, das die Verbindung angestoßen hat) bekommt keine Antwort. Das erste Datenpacket scheint verloren gegangen zu sein. Wenn jemand weiß, warum dies so ist und wie man dies vermeidet, wäre ich für eine Info dankbar. Vielleich hängt dies mit der Firewall zusammen, die nach dem Verbindungsaufbau jedesmal neu aufgesetzt wird?

In der Konfigurationsdatei foo für die Verbindung müssen folgende Zeilen eingesetzt werden, wenn "on demand"-Online-Gehen gewünscht ist:

idle 30 demand connect "/bin/true" (In diesem Beispiel wird die Verbindung nach 30 Sekunden Inaktivität beendet.) Um online zu gehen muss nachwievor der ppp-daemon gestartet werden, also beispielsweise pon (siehe oben) aufgerufen werden. Allerdings wird die Online-Verbindung erst hergestellt, wenn ein IP-Packet den Weg ins Internet sucht, bspw. weil in einem Web-Browser eine URL eingegeben wurde.

Zusätzlich ist eine Anpassung des active-Filters sinnvoll. Es kann passieren, daß der eigene Rechner von außen immer wieder IP-Packete zugeschickt bekommt, die es verhindern, dass die Verbindung automatisch beendet wird. Um dies zu vermeiden, kann dem pppd angewiesen werden, bestimmte Packete bei der idle-Zeit-Zählung gar nicht zu beachten. Dies erledigt der folgende Eintrag:

active-filter 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0' Diese Zeile habe ich im Internet auf den Seiten von SuSe-Linux gefunden (In der Zeitschrift c't war dazu auch ein Artikel gewesen). Die genaue Bedeutung habe ich noch nicht analysiert.

Den folgenden Link auf eine fli4l-Seite bekam ich zugemailt, weswegen ich ihn hier wiedergebe möchte.

6.5. Offline gehen

Es bleibt nun noch die Frage, wie man die Verbindung wieder abbricht. Normalerweise sollte ein poff den pppd beenden. Laufen irrtümlicherweise mehrere pppd, so hilft ein poff -a. Funktioniert dies nicht, so hilft normalerweise ein "killall pppd" oder "capiinit stop" (ggf. unter "root"). Wenn ps axu | grep pppd keinen entsprechenden Eintrag ausgibt, kann man sich wohl ziemlich sicher sein, daß der Rechner wieder offline ist.

Zu letztem Punkt bekam ich inzwischen noch den Hinweis (Dank an Steffen Barszus), dass die pppd Option "nodetach" dafür sorgt, daß pppd nicht als eigener Prozeß geforkt wird, sondern an der Shell, in der man ihn startet, hängen bleibt. Damit erscheinen zum einen die debug-Ausgabe direkt in der Shell, zum anderen kann der Prozeß und damit die Online-Verbindung mit CTRL-C direkt wieder beendet werden.

6.6. Fehlermeldung "diald[207]: No devices free to call out on"

Ich bekam eine E-Mail, die ich dem weltweiten Netz nicht vorenthalten möchte: Bei mir schien alles zu laufen, aber ich bekam keine Verbindung. Dafür tauchten in /var/log/syslog Meldungen auf wie diese: ...diald[207]: No devices free to call out on Was passiert war: Ich hatte beim Aufsetzen des Systems auch den diald mit installiert (ich wollte ja ins Internet ...) und dieser versuchte nun bei jedem Request eine Verbindung über das schon durch den pppd besetze Gerät aufzubauen. Das ging nicht, weshalb er mit einer Fehlermeldung abbrach und niemand eine Verbindung bekommen konnte ... Nach der Deinstallation von diald mit dpkg -r diald war der Spuk vorbei.

6.7. ISDN Multi-Link

Eine Sache, die mit Sicherheit interessant ist, die ich selber aber nie ausprobiert habe, ist das Bündeln beider ISDN-Kanäle. Es werden also zwei ISDN-Verbindungen gleichzeitig betrieben, so dass insgesamt die doppelte Bandbreite zur Verfügung steht. Ich war über die folgenden Postings gestolpert, die ich hier nochmals wiedergebe: http://groups.google.com/groups?hl=en&lr=&frame=right&th=7e6aba2096f375fb&seekm=3bc1c7c4.23344708%40news.cis.dfn.de#link6 Nach der Beispieldatei (bei debian woody) unter /etc/ppp/peers/isdn/ soll das ganze hiermit funktionieren: # # AVM GmbH - Fast Internet Test Server with Multilink # debug sync noauth plugin userpass.so username netways password netways defaultroute plugin capiplugin.so number 03039984330 protocol hdlc ipcp-accept-local ipcp-accept-remote multilink mrru 1500 # endpoint need to be changed endpoint magic:4711 /dev/null Bei mir funktioniert es so! Man muss aber beachten das der Kernel PPP-Multilink unterstützen muss. Also bei der Konfiguration des Kernels aktivieren!!! Kleiner Tipp noch der Code ist "Experimental"! Es gibt sogar die Möglichkeit (hab ich irgendwo gelesen) den zweiten Kanal automatisch dazu zu schalten, sobald der erste komplett ausgelastet ist. Dieser schaltet sich dann auch wieder ab sobald der Traffic wieder abnimmt! Ist nur ne zusätzliche Option, nur welche weis ich jetzt nicht mehr.

7. FritzCard DSL

Für Besitzer der DSL-Variante bekam ich noch einen Hinweis von Gerold "Paul" Gruber: Hallo Gert, danke für Dein HowTo zur Fritz Card PCI, auf dieser Basis habe ich meine FritzCard DSL zum laufen gebracht. Unter http://www.sax.de/~paul/debian_fcdsl.html habe ich die Ergänzungen zu Deinem HowTo abgelegt. Wenn Du Lust hast, kannst Du Dein Howto damit ergänzen oder darauf verlinken. Danke und viele Grüße Paul (aka Gerold Gruber) Ok, dies habe ich nun endlich nach über einem Jahr getan. ;)

Lizenz

Dieser Text unterliegt der GNU Free Documentation License (FDL). Freie Verbreitung in modifizierter oder unmodifizierter Form ist erlaubt; Modifikationen müssen unmißverständlich gekennzeichnet sein und ebenfalls unter der FDL vertrieben werden.

Copyright (C) Gert Brinkmann
Erschienen auf Pro-Linux, letzte Änderung 2005-05-04