Installationsanleitung für Teledat USB 2a/b und baugleiche Geräte

Der übliche Weg den Treiber zu installieren, besteht darin die Module selbst zu kompilieren. Hierbei ist zu beachten, dass einige Entwicklungswerkzeuge installiert sein müssen (gcc, make, kernel-sourcen). Detailiertere Informationen sind bei der Beschreibung der jeweiligen Tests zu finden.

Für die Installation selbst (make install) braucht man root-Rechte. Der Rest kann als normaler Benutzer durchgeführt werden.

Folgende Schritte sind auszuführen:

Für den Fall, dass man die benötigten Entwicklungswerkzeuge nicht installieren möchte, gibt es noch eine alternative Möglichkeit. Im Download-Bereich der Teledat-Homepage liegen einige vorkompilierte Module. Wenn man Glück hat ist ein Modul für den eingesetzten Kernel vorhanden.

Die Module sind auch nach Distribution geordnet, jedoch es ist darauf zu achten, dass die Kernelversion übereinstimmt. Das configure-Skript prüft zur Sicherheit noch einmal automatisch die Version, damit kein falsches Modul installiert wird.

Achtung bei fxusb.o! Aus verschiedenen Gründen heißt das Modul für bestimmte Fritz und Teledat Geräte gleich. Es ist besonders darauf zu achten das richtige Modul herunterzuladen.

Nachdem das Modul heruntergeladen wurde, muss es ins Unterverzeichnis src.drv kopiert werden. Danach durch Eingabe von ./configure --precompiled-module und make install das Modul installieren.

Soweit ein RPM vorhanden ist, ist es wichtig darauf zu achten, das das RPM sowohl für das Gerät richtig ist, als auch, daß das RPM auch für den richtigen Kernel ist. Der Kernelname im Namen des RPM sollte mit der Ausgabe von uname -r unbedingt übereinstimmen. Wenn das richtige RPM heruntergeladen ist, reicht es einfach rpm -ihv rpmname auszuführen um das RPM zu installieren. Darauf folgend muß nur noch das Gerät einmal abgezogen werden und danach wieder eingesteckt und der Treiber sollte geladen werden.

Soweit ein Source-RPM für deine Distribution vorhanden ist, kann man mittels rpm --rebuild sourcerpmname das RPM für seinen Kernel neu kompilieren. Dabei entstehen mehrere rpms passend für den aktuell installierten Kernel. Um ein Source RPM zu kompilieren, sollten alle benötigten Pakete entsprechend der Distribution installiert sein.

Gilt für Debian GNU/Linux Woody (3.0) oder höher (testing/unstable) mit teledat-1.4. Hardware bei diesem Beispiel war eine Teledat USB2a/b.

Einen Kernel bauen (>2.2.17 oder 2.4.x), dabei (neben allem anderen) folgendes einstellen:

Kernel erstellen (make menuconfig in /usr/src/linux, Optionen einstellen, Exit und mit "fakeroot make-kpkg kernel_image --revision=mykernel.1" kompilieren. Im übergeordneten Verzeichnis mit "dpkg -i kernel-image-xxxx.deb" installieren) und mit diesem neu booten.

Für einfaches Handling des USB-Anschlusses könnt ihr hotplug installieren und starten (apt-get install hotplug, /etc/init.d/hotplug start).

Das Paket isdnactivecards installieren (apt-get install isdnactivecards), evtl. in/etc/isdn/capi.conf nicht benötigte/nicht vorhandene ISDN-Controller auskommentieren (nicht zwingend erforderlich) und isdnactivecards starten (/etc/init.d/isdnactivecards start).

Jetzt kann teledat kompiliert werden (./configure, make, make install).

Nachdem das Modul installiert wurde, muss in jedem Fall der Befehl depmod -a ausgeführt werden. Durch diesen Befehl werden die Abhängigkeiten zwischen den Kernel-Modulen neu ermittelt und die Anlage kann nun automatisch erkannt werden.

Wenn man nun die Anlage aus- und einsteckt bekommt man das auf einem Terminal mitgeteilt. Alternativ dazu kann man die Meldung auch unter /var/log/messages nachlesen. Danach kann man mit lsmod komtrollieren ob das jeweilige Kernel-Modul des Gerätes geladen wurde.

Um das Gerät zu aktivieren ist es notwendig jetzt das Kommando capiinit start auszuführen. Damit das nicht nach jedem Neustart gemacht werden muss, sollte man diesen Vorgang in das Startsystem von Linux einbinden. Leider ist dieser Schritt bei jeder Distribution etwas anders gelöst. Wir möchten jedoch eine möglichst allgemeingültige Anleitung geben:

Wir konnten bisher noch nicht definitiv klären ob capiinit nur für interne oder auch für USB-Geräte benötigt wird. Es gibt wiedersprüchliche Meldungen zu diesem Thema. Falls eine Fehlermeldung wie „CAPI_REGISTER failed. No such device (19)“ angezeigt wird ist meistens das nicht aufgerufene capiinit daran Schuld.

Falls beim Aufruf von capiinit Fehlermeldungen angezeigt werden müssen in der capi.conf (Position durch capiinit status erfahren) alle nicht verwendeten Geräte entfernt werden.

Im Beispiel der Teledat USB 2a/b sollte nur

in der Datei stehen

Das Gerät ist jetzt aktiviert und bereit eine Verbindung aufzubauen. Weitere Details dazu sind im Kapitel „Verbindungsaufbau“ nachzulesen.

Durch einen Aufruf von ./configure --help wird eine Hilfe zu den verfügbaren Konfigurationsoptionen angezeigt. Die Optionen sind dabei gut dokumentiert.

Alle --disable-* Optionen dienen dazu bestimmte Test zu deaktivieren. Es gibt unterschiedlichste Gründe einen Test zu deaktivieren. Ein Grund wäre wenn bestimmte Module die benötigt werden direkt in den Kernel einkompiliert wurden. Normalerweise ist das jedoch nicht der Fall und wer so etwas macht, weiß auch welche Tests man mit gutem Gewissen deaktivieren kann.

Die Option --precompiled-module wird benötigt, falls man ein vorkompiliertes Modul verwenden möchte. Weitere Informationen dazu sind im Kapitel „Vorkompilierte Module nutzen“ nachzulesen.

Im Normalfall müssen die aktuellen Kernelsourcen in /usr/src/linux liegen. Wenn das auf dem System nicht der Fall ist, muss man nun entweder einen entsprechenden Link anlegen oder die Option --with-kernelsrcdir=<pfad> angeben. Ein weiterer Grund für diese Option ist die Möglichkeit ein Modul für einen anderen Kernel zu bauen. Dies kann sehr nützlich sein, falls auf einem anderen System keine Entwicklungsumgebung zur Verfügung steht (z.B. FLI4L). Einfach die Kernelsourcen eines anderen Kernel installieren und diese als <pfad> angeben.

Das configure-Skript sollte eigentlich im Normalfall das angeschlossene Gerät von selbst erkennen. Falls das Gerät aus irgendeinem Grund falsch oder gar nicht erkannt wurde, kann man den Gerätetyp mit --card=<cardname> erzwingen. Das sollte nur angewendet werden wenn man sich sicher ist, dass der Fehler an keiner anderen Stelle liegt.

Dieser Test wird benötigt um zu erkennen ob auf dem System ein GNU C Compiler installiert ist. Der Compiler wird benötigt um das Treiber-Module zu kompilieren. Falls kein Compiler gefunden wurde muss entweder einer installiert werden oder ein vorkompiliertes Modul/Paket verwendet werden.

Mit Hilfe der Option --cc=<compiler> kann man die Verwengung eines alternativen Compilers erzwingen. Das ist für den Fall nützlich, dass auf dem System mehrere GNU C Compiler parallel installiert sind.

Es wird getestet ob das Tool make vorhanden ist. Dieses Tool wird in jedem Fall für die Installation benötigt und muss, falls nicht vorhanden nachinstalliert werden.

Für die Installation des Treibers wird ein Kernel 2.4.x aufgrund der CAPI- und USB-Module benötigt. Falls ein älterer Kernel verwendet wird, kann der Treiber nicht installiert werden. In Klammern dahinter befindet sich im Erfolgs- oder Fehlerfall die Kernelversion.

Die Dateien modversions.h, version.h und weitere Header werden für die Komplierung des Treiber-Moduls benötigt. Falls die Datei nicht vorhanden ist, gibt es mehrere Möglichkeiten diese zu bekommen. Man kann z.B. die benötigten Pakete, sofern vorhanden, aus der verwendeten Paketverwaltung einspielen.

Bei Debian gibt es zwei Pakete dafür. Zum einen kernel-header und zum anderen kernel-source. Das Paket kernel-header enthält schon die benötigten Dateien, wobei sie bei kernel-source noch per Hand erzeugt werden müssen.

Falls die Kernel-Header in keinem Paket vorhanden sind oder ein Kernel von kernel.org verwendet wird, ist es notwendig die benötigten Header per Hand zu erzeugen.

Jetzt sollten alle benötigten Header vorhanden sein und der Test keine Fehler mehr melden.

Es kann jedoch auch sein, dass nur der Link /usr/src/linux nicht auf die aktuellen Kernel-Sourcen zeigt. Als Lösung entweder diesen Link anlegen oder die Option --with-kernelsrcdir=<pfad> benutzen.

Der ppp Deamon ist eine der möglichen Voraussetzungen eine Verbindung aufzubauen. Falls er nicht installiert ist, muss das entweder nachgeholt werden oder mit Hilfe von isdn4linux (ipppd/isdnctrl) eine Verbindung aufgebaut werden.

Es gibt verschiedene Möglichkeiten eine Verbindung zum Provider aufzubauen. Diese Möglichkeiten basieren auf unterschiedlichen Programmen die getestet werden. Im Erfolgsfall werde in den Klammern dahinter alle Möglichkeiten aufgelistet.

Die Details wie man mit den unterschiedlichen Programmen eine Verbindung aufbaut ist im Kapitel „Vebindungsaufbau“ beschrieben.

Für die Initialisierung des CAPI Systems müssen verschiedene CAPI-Tools installiert sein. Falls nicht vorhanden müssen sie nachinstalliert werden.

In Klammern dahinter wird im Fehlerfall das nicht vorhandene CAPI-Tool ausgegeben.

Das Modul usbcore muss geladen sein, um die USB-Sub-System zu aktivieren. Falls der Test fehlschlägt muss das USB-System des Linux-Rechners richtig eingerichtet werden. In diesem Fall hilft das Distributions-Handbuch weiter.

Für eine einmalige Aktivierung einfach modprobe usbcore eingeben.

Damit der USB-Host Controller benutzt werden kann, muss der richtige Treiber geladen werden. Welcher Treiber das ist muss selbst festgestellt werden. Es ist entweder usb-ohci,usb-uhci oder uhci. Normalerweise sollte ein Aufruf von modprobe <modul> das richtige identifizieren.

Die CAPI-Module capifs, capiutil, kernelcapi und capi müssen als Modul kompiliert worden sein. Die großen, aktuellen Distribution haben das im Normalfall schon so eingerichtet.

Probleme kann es bei selbst kompilierten Kerneln geben. Es ist dann festzustellen, ob die Module im Kernel fest einkompiliert worden oder nicht vorhanden sind. Falls sie fest in den Kernel einkompiliert wurden muss dieser Test deaktiviert werden.

Im Fehlerfall werden in den Klammern dahinter alle nicht verfügbaren Module angezeigt.

Bei diesem Test wird versucht automatisch den Typ der verwendeten Anlage zu bestimmen. Falls es zu Problemen kommt kann es an eine der folgenden Ursachen haben:

Versuchen Sie mit Hilfe des Parameters --card=<cardname> den Anlagentyp per Hand zu bestimmen. Sollte die Anlage daraufhin trotzdem unter Linux nicht funktionieren liegt der Fehler an einer anderen Stelle.

Der Test taucht nur auf, wenn versucht wurde ein vorkompiliertes Modul zu installieren. Aufgrund der Meldung in Klammern dahinter lässt sich die Art des Fehlers feststellen.

Wird der Name eines Moduls ausgegeben, so wurde es nicht gefunden. Da Modul muss zu dem verwendeten Gerätetyp passen.

Erscheint in Klammern dahinter ein Konstrukt wie (2.4.18-3 != 2.4.20) dann ist das Modul zwar vorhanden, aber für den falschen Kernel kompiliert. Als Lösung entweder ein passendes Modul laden oder das Modul selbst kompilieren.

Wenn beim „Dial possibility Test“ in Klammern dahinter „pppdcapiplugin“ ausgegeben wurde, ist es möglich mit Hilfe des pppd eine Verbindung aufzubauen.

Damit die Handhabung des pppd einfacher ist, sind im Unterverzeichnis scripts zwei Skripte ppp-dial und ppp-hangup abgelegt. Diese Dateien kann man für seine Bedürfnisse modifizieren und zum Verbindungsauf- und abbau benutzen. Diese Skripte erklären sich durch ihre Kommentare von selbst.

Natürlich kann man auch statt in diese Skripte die Anpassungen in der dafür vorgesehenen Datei der Distribution ausführen. Bei vielen Distributionen sind dafür die zwei Dateien /etc/ppp/ip-up.local und /etc/ppp/ip-down.local vorhanden. Bei Debian ist dieses aber etwas anders gemacht. Dort gibt es /etc/ppp/ip-up.d/ und /etc/ppp/ip-down.d/ Verzeichnisse in denen man mehrere Scripte plazieren kann.

Beide Wege haben Vor- und Nachteile. Modifikationen an den Dateien in /etc/ppp/ gelten für die Anwahl mit ppp und ipppd. Wenn man hingegen Anpassungen an den Skripten [i]ppp-[dial|hangup] vornimmt, gelten die immer entweder für ppp oder ipppd. Das kann je nach Anforderungen erwünscht oder auch störend sein.

In dem Verzeichnis /etc/ppp/isdn/ liegen einige beispielhafte pppd-Skripte für den Aufbau einer Verbindung. Die genaue Syntax ist durch man pppd zu erfahren.

Die Konfiguration des ipppd ist etwas aufwendiger, als die des pppd. Voraussetzung dafür ist, dass beim „Dial possibility Test“ in Klammern dahinter „isdn4linux“ ausgegeben wurd

Als erstes ist sicherzustellen ob das System die notwendigen Module und Dienste zum Verbindungsaufbau gestartet hat. Auf jeden Fall müssen die Module isdn, slhc und capidrv geladen sein. Zusätzlich muss der ipppd gestartet sein. Die meisten Distributionen bieten ein Werkzeug an um diese ISDN-Dienste einzurichten. Oft hilft es eine andere ISDN-Anlage einzurichten und dann die Änderungen per Hand durchzuführen. Ein Blick ins Handbuch der Distribution hilft an dieser Stelle weiter.

Falls es für die Distribution kein Werkzeug zu diesem Zweck gibt, kann man das Init-Skript srcipts/isdn_teplate benutzen. Es ist ein minimales Init-Skript ohne weitere Features wie z.B. das Starten von isdnlog. Bevor das jedoch funktioniert müssen erst noch einige Einstellung geändert werden.

Jetzt muss noch die Datei /etc/ppp/pap-secrets angepasst werden. Viele call-by-call Provider sind schon eingetragen. Falls ein zusätzlicher Eintrag erfolderlich ist, muss er im Stil

'provider' * 'internet'

hinzugefügt werden. Dabei ist zu beachten, dass der gleiche Name auch beim Aufruf von ipppd angegeben werden muss. Das kann gegebenfalls im isdn_template Skript geändert werden.

Damit die Handhabung des ipppd einfacher ist, sind im Unterverzeichnis scripts zwei Skripte ippp-dial und ippp-hangup abgelegt. Diese Dateien kann man für seine Bedürfnisse modifizieren und zum Verbindungsauf- und abbau benutzen. Diese Skripte erklären sich durch ihre Kommentare von selbst.

Damit das ganze funktioniert muss also das isdn_template Skript aufgerufen werden oder der Rechner neu gestartet werden. In diesem Fall muss das System natürlich so konfiguriert werden, dass dieses Skript bei Systemstart aufgerufen wird. Weitere Anmerkungen zu diesem Vorgang sind schon im Kapitel „ Aktivierung des Gerätes“ gemacht worden.

Eine FAQ zum Thema isdn4linux ist unter http://www.isdn4linux.de/faq/i4lfaq.html im Internet verfügbar. Dort ist auch beschrieben wie man mit isdn4linux eine Multilink Verbindung aufbauen kann. (Kapitel 18)

Fragen zu isdn4linux werden gerne in der Newsgroup de.comp.os.unix.linux.isdn diskutiert. Recherchieren kann man in dieser Newsgroup sehr einfach über Google Groups.

Das Modemlämchen Applet ist die bevorzugte Möglichkeit mit Gnome 1.4 bzw 2.0 die Verbindung zu kontrollieren. Dabei muss man natürlich den richtigen Befehl für Verbindungsaufbau und Trennung angeben.

Wenn man die Verbindung mit Hilfe von pppd aubaut, muss im Dialog „Komplex“ die Modem-Lockdatei /var/lock/LCK..0 eintragen werden.

Nutzt man zum Verbindungsaufbau ipppd, dann kann man einfach „ISDN verwenden“ im Dialog „Komplex“ aktivieren. Es ist darauf zu achten, dass man dafür ausreichende Rechte auf /dev/isdninfo haben muss.

Danach wird die aktuelle Übertragungsrate grafisch im Applet angezeigt.

GKrellM kann, neben vielen anderen Sachen, auch eine ppp-Verbindung überwachen. Die Konfiguration von GKrellM ist völlig Dialog gesteuert und Bedarf keiner großen Erklärung. Einfach das Interface ppp0 bzw. ippp0 eintragen und es sollte funktionieren. Der ein- und ausgehenden Datenverkehr wird grafisch dargestellt und ist vielseitig konfigurierbar.

Das einzige Problem könnte werden, dass man nur einziges Kommando definieren kann. Es ist also eine Anwahl per Knopfdruck möglich, aber die Abwahl muss dann per Hand erfolgen. Mit ein wenig Aufwand könnte man ein Skript bauen, welches dieses Problem beseitigt. Wer interesse daran hat, möge weitere Informationen bitte bei uns erfragen.

http://www.gkrellm.net/

Kisdndial ist ein Kicker-Applet welches die Kontrolle der Verbindung über isdn4linux ermöglicht. Es hat eine Anzeige der Übertragungsrate und man kann einfach (soweit konfiguriert) zwischen verschiedenen Providern wechseln. Es bietet in Zusammenhang mit isdnlog eine Rufnummernanzeige bei eingehenden Anrufen. Man sollte jedoch sicherstellen, das die Rechte richtig gesetzt sind. Nachteilig bei diesem Programm ist, daß es darauf besteht das isdnctrl setuid root gesetzt ist.

http://www.kisdndial.de/

LineControl ist ein Server, der auf Anfrage eines Clients die Internetverbindung kontrolliert. Dieses hat den Vorteil, daß man manuell die Verbindung kontrollieren kann , obwohl die ISDN Karte an einem anderen Rechner im Netz angeschlossen ist. Aber auch wenn beide (Client und Server) am gleichen Rechner angeschlossen sind funktioniert dies natürlich.

Es existieren Clients für Win32, GTK, KDE und die Kommandozeile. Neben der Einwahl bietet LineControl optional Rufnummernanzeige, eine Weboberfläche für den Verbindungsstatus, sowie eine Übersicht, wer wieviel gesurft hat, was recht nützlich sein kann wenn man seinen Internetzugang mit anderen teilt. Der Verbindungsauf- und Abbau wird über Scripte geregelt welche vom Server gestartet werden.

Somit unterstützt LineControl eigentlich alle erdenklichen Möglichkeiten sich mit dem Internet zu verbinden (isdn4linux wird explizit unterstützt, inclusive Kanalbündelung). Auch können Scripte definiert werden, die ausgeführt werden sobald sich ein Client mit dem Server verbindet. Für das Ausschalten des "Routers" kann ein (oder mehrere) Benutzer definiert werden, dem dieses ermöglicht wird.

http://linecontrol.sourceforge.net/

Das Programm "mserver" funktioniert nach dem gleichen Prinzip wie LineControl (eher andersrum, da mserver älter ist als LineControl). Der Vorteil von "mserver" ist, daß es mehr Clients gibt. Sehr gelungen ist zum Beispiel der Gmasqdialer. Es existiert keine Unterstützung für isdn4linux (obwohl durch eigene Skripte durchaus möglich, empfiehlt es sich LineControl für isdn4linux zu verwenden) und es ist sehr auf Modems angepaßt. Ein weiterer Nachteil ist, daß mserver leider nicht mehr weiterentwickelt wird. Wer jedoch Gnome benutzt, wird evtl. mserver LineControl vorziehen.

http://w3.cpwright.com/mserver/

wmisdn ist ein Dock Applett welches die Kontrolle der Verbindung über isdn4linux ermöglicht. Man kann eine Verbindung für ein konfiguriertes Gerät starten, stoppen oder die Einwahl abschalten. Man kann es als DockApp in WindowMaker, Blackbox und ähnlichen verwenden oder alleine als normales Programm laufen lassen (Unter Kde2 gab es Kappdock, ich kann nicht sagen ob es vergleichbares noch gibt). In seinem Hauptfenster zeigt es den Status des konfigurierten ippp-Gerätes

http://www.uni-bonn.de/~uzsymm/linux.html#programs/

Auch unter IceWM ist es möglich den Status der Verbindung über das pppdcapiplugin zu kontrollieren. Zur Einrichtung kann man ice-pref verwenden. Dort unter „Taskbar“ kann man das Gerät angeben (in unserem Fall ppp0) welches überwacht werden soll. Unter „Commands“ kann man nun ein geeignetes Script angeben, welches ausgeführt wird sobald auf die Statusanzeige des ppp0 geklickt wird. Auch hier ist wie bei Gkrellm nur die Angabe eines Scriptes möglich und es gilt dort gesagtes.

Durch Zufall gefunden und evtl. interessant für Nutzer dieses WM's. Falls jemand dieses Programm getestet hat, kann er uns gerne ein Testbericht zukommen lassen.

http://freshmeat.net/projects/bbppp/

Ein weiterer ungetesteter ISDN-Dialer für Gnome. Lässt sich wahrscheinlich auch gut in andere Window Manager intergrieren. Auch hier würden wir uns über einen Testbericht freuen.

http://freshmeat.net/projects/gisdnbutton/?topic_id=20