| Howto: ISDN Fritz PCI 2.0 unter Debian |
|
|
|
|
Von Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst 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 an Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst freuen. 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. 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 hier auf dem AVM-Server. 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 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. 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 mit dem 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 Paketname werden unter anderem die Informationen angezeigt, für welchen Prozessor das Paket 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 Paket 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-Installation 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:
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 wußte, 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-Pakets eine genauere Information, welche Kernel-Optionen eingeschaltet werden müssen:
Im Internet finden sich viele Kernel-Build-Howtos, weswegen ich hier nur kurz zusammengefasst aufschreibe, wie ich vorgegangen bin:
Ich habe lange gebraucht, um herauszufinden, daß nun noch einige Pakete installiert werden müssen. Speziell, daß ich das Paket »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.
Das Paket »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. Ich weiß leider nicht, welches die beste Art und Weise ist, die gcc-Version zu bestimmen, mit der der Kernel kompiliert wurde. Hinweise liefert anscheinend aber die 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-Pakets 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:
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-Paket 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.
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:
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:
und von mir geändert wurden in
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 Als letztes muß für seinen Provider (ich nenne den hier mal "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". Sind diese Änderungen gespeichert, sollte ein pppd call isdn/foo (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. Scheint alles zu funktionieren, lediglich der Browser kann keine Web-Site finden, so muß ggf. noch der DNS-Server konfiguriert werden. Vielleicht hat man Glück mit dem Einfügen der Option "usepeerdns" in die "foo"-Konfigurationsdatei, oder man trägt den oder die Domain-Name-Server in /etc/resolv.conf ein. Es bleibt nun noch die Frage, wie man die Verbindung wieder abbricht. Ich habe dafür noch keine andere Möglichkeit als "killall pppd" oder "capiinit stop" (ebenfalls unter "root") gefunden. 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 man den Prozeß und damit die Online-Verbindung mit CTRL-C direkt wieder beenden. Viel Erfolg, |
|||||||||||||||||
| < Zurück | Weiter > |
|---|