Fedora Core und die AVM Fritz Card ISDN Adapter

Ausnahmsweise schreibe ich diesen Blogeintrag mal in deutscher Sprache, denn er wird sich um die Besonderheiten, die sich mit der Verwendung der allseits (besonders im deutschen Sprachraum) beliebten AVM-Fritzcard Adapter unter Fedora Linux, befassen. Dabei werde ich allerdings nicht nur auf die Installationsschwierigkeiten des CAPI-Treibers eingehen, sondern auch beschreiben, wie die “alten” isdn4kutils zum Laufen gebracht werden können.

CAPI mit Hindernissen

Bis zur Version 9.3 (offiziell bis 9.0) der Distribution Suse leistete der Hersteller, AVM GmbH, direkten Support. Da ISDN-Kartentreiber im Wesentlichen direkt in den Kernel geladen werden müssen, können die von AVM immer noch auf ihrem FTP-Server zur Verfügung gestellten Versionen nicht mehr auf aktuelle Kernels angewandt werden. Das Paket, das man sich vom Server herunterladen kann, enthält einen quelloffenen Teil, der für die Schnittstelle zwischen Kernel und Hardwarezugriff zuständig ist und einen Closed-Sourceanteil, der im Wesentlichen für die Firmware der AVM-Karte genutzt wird. Weil die Wartung des Treibers seitens AVM eingestellt wurde und sich allerdings sehr viele abhängigen C-Headerdateien geändert haben (insb. in der Kernelserie 2.6), ist ein Neukompilieren ohne Modifikation des quelloffenen Teils des Treibers nicht möglich. In der Community gibt es allerdings immer wieder sehr findige C-Programmierer, die entsprechende Patches für den Sourcecode erarbeiten (Änderungen an der Firmware scheinen wohl nicht gemacht werden zu müssen) und diese dann veröffentlichen. Kompliziert wird es nur dadurch, daß manche Patches auf anderen Patches aufbauen und so erst mal die korrekte “Patchreihenfolge” herausgefunden werden muß.

Der einfache Weg des CAPIs

Derzeit sind Fedora Core 12-Benutzer, die ihre AVM Fritzkarte zum Laufen bringen wollen allerdings in einer recht glücklichen Lage: Das ATrpms-Repository stellt entsprechend vorkompilierte, bereits gepatchte RPM-Pakete für jede veröffentlichte FC12-Kernelversion zur Verfügung (ggf. mit leichtem Zeitversatz). Die Installation dieser Pakete ist über yum bzw. rpm möglich. Unabhängig davon, ob man ich den Kartentreiber über das Repository beschafft oder man den komplizierteren Patch&Compile-Weg ausgesucht hat reicht dies nicht aus, um die Karte auch automatisch zum Laufen zu bringen. Details, welche weiteren Schritte hierzu nötig sind, bietet eine Wiki-Seite auf der FedoraWiki. Im wesentlichen muß also dort

  • weitere Devicefiles über die udev-Schnittstelle anlegt (via mknod)
  • eine Konfigurationsdatei zum Laden des Kerneltreibermoduls entsprechend angepaßt und
  • das automatische Starten des CAPI-Moduls veranlaßt

werden. In einem konkreten Fall mit Fedora Core 12 zeigte sich, daß die Erstellung der Datei /dev/capi20 via udev (wie oben beschrieben) nicht ausreichte. Das Problem beim Systemstart war, daß diese Datei offensichtlich von udev nicht erzeugt wurde. Eine Beschreibung, wie man diese Datei manuell erzeugen kann, findet sich zum Beispiel in einem Eintrag bei OpenSuse. Das zentrale Kommando dabei ist

mknod /dev/capi20 c 68 0

Auch hier ist wieder zu beachten: Ist das Erstellen der Datei notwendig, so muß dies bei jedem Neustart wieder durchgeführt werden (Details siehe unten). Zu diesem Zweck empfiehlt es sich eine Datei /etc/rc.d/init.d/capi-pre zu erzeugen, die folgenden Inhalt aufweist:

#! /bin/bash
#
# chkconfig: 2345 8 90
# description: start and stop capi services for passive ISDN cards
#

PATH=/bin:/sbin:/usr/bin:/usr/sbin

# Source function library.
if [ -f /etc/init.d/functions ]; then
    . /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
    . /etc/rc.d/init.d/functions
else
    exit 0
fi

[ -f /sbin/capiinit ] || exit 0
[ -f /etc/capi.conf ] || exit 0
RETVAL=0

function start()
{
    # don't start again if it's already started
    action $"preparing capi4linux:" mknod -m 666 /dev/capi20 c 68 0
    RETVAL=$?
}

function stop()
{
    RETVAL=0
}

function restart()
{
    RETVAL=0
}
function condrestart()
{
    RETVAL=0
}

function status()
{
    capiinfo
}

case "$1" in 
    start)
       start
       ;;
    stop)
       stop
       ;;
    restart)
       restart
       ;;
    condrestart)
       condrestart
       ;;
    status)
       status
       ;;
    *)
       echo $"Usage: $0 {start|stop|restart|status|condrestart}"
       exit 1
esac

exit 0

Wie bei allen Serviceskripts notwendig, muß das Skript per

chkconfig --add capi-pre
chkconfig capi-pre on

zunächst aktiviert werden.

ISDN4KUtils – und nu’?

Für alle diejenigen, die “nur” eine Unterstützung der CAPI-Schnittstelle für ihre Programme benötigen, ist das oben vorgestellte bereits ausreichend. Es gibt allerdings eine Reihe von Legacy-Anwendungen, die noch auf der alten ISDN-Subsystemschnittstelle arbeiten, darunter so [Ironie on] “unwichtige” [Ironie off] Programme, wie

  • ipppd: ISDN-PPP-Daemon, der es erlaubt Internetverbindungen per ISDN herzustellen; auch dient er dazu, um den lokalen Server zu einem ISDN-Einwahlknoten zu machen
  • vbox: Anrufbeantworter mit sehr vielen konfigurierbaren Optionen bis hin zu eigenen Scripts mit DTMF-Tonwahlerkennung
  • isdnlog: D-Kanalprotokollierungssoftware zur Aufzeichnung von Wählvorgängen und Telefonkostenanalysen

Diese Programme befinden sich alle im ISDN4KUtils-Paket, das FC12 immer noch wie üblich zur Verfügung stellt. Allerdings können diese nicht direkt auf die CAPI-Schnittstelle zugreifen. Für diesen Zweck gibt es ein besonderes Kernelmodul, das die CAPI-Schnittstelle auf die ISDN-Subsystemschnittstelle übersetzt. Dies heißt durchaus etwas unintuitiv “capidrv.ko” – der nicht eingeweihte Leser würde dahinter wohl eher das Basis-CAPI-Subsystem erwarten. Dessen Anwendung wird auf den mISDN-Wikiseiten recht unprosaisch vorgestellt und ist zudem auch noch stark aus dem Zusammenhang gerissen. Alleine von zentraler Bedeutung sind die folgenden Kommandos:

modprobe capidrv

mknod -m 660 /dev/ttyI0 c 43 0
mknod -m 660 /dev/ttyI1 c 43 1
...
mknod -m 660 /dev/ttyI20 c 43 20

Allerdings ist auch das nur die Hälfte der Wahrheit, denn dann fehlen immer noch die beiden Char-Geräte /dev/isdnctrl0 und /dev/isdninfo, die für den Betrieb fast aller ISDN4KUtils-Programme unbedingt notwendig sind. Einen guten Hinweis, wie das Problem zu lösen ist, wird auf einer Wikiseite von ArchLinux vorgestellt (siehe dort Abschnitt “Isdnlog auch mit Capi weiterbenutzen”). Dadurch kommen nochmals die beiden Kommandos

mknod /dev/isdnctrl0 c 45 64 2>/dev/null
mknod /dev/isdninfo c 45 255 2>/dev/null

hinzu. Es ist allerdings zu beachten, daß alle diese Kommandos bei jedem Systemneustart auszuführen sind, da die Kommandos zwar Dateien (genauer: Gerätedateien) erzeugen, diese allerdings nur in ein virtuelles Dateisystem geschrieben werden, das naturgemäß nach einem Neustart wieder auf den Initialzustand zurückgesetzt wird. Anschließend kann die erfolgreiche Installation mit dem Kommando imontty geprüft werden. Ist dort

ISDN channel status:

Channel                 Usage Type  Number
----------------------------------------------------------------------
capidrv-1               Off
capidrv-1               Off

zu lesen (wichtig sind hier die beiden letzten Zeilen, die beide mit capidrv-1 anfangen), dann war die Adapterkonfiguration erfolgreich.

Ausblick

Es scheint in der aktuellen Version von Fedora Core 12 auch einen quelloffenen Treiber für die AVM Fritzkarten mitgeliefert zu werden (avmfritz.ko). Offensichtlich hat dieser nichts mit dem hier vorgeschlagenen Originaltreiber von AVM zu tun. Zum Zeitpunkt des Schreibens dieses Blogeintrages allerdings war ich nicht in der Lage, ein System mit diesem Treiber erfolgreich zum Laufen zu bringen. Auch schweigt sich Google über diesen Treiber derzeit noch vollkommen aus.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This blog is kept spam free by WP-SpamFree.