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\u00f6nnen.
\n<\/p>\n
Bis zur Version 9.3 (offiziell bis 9.0) der Distribution Suse leistete der Hersteller, AVM GmbH<\/a>, direkten Support. Da ISDN-Kartentreiber im Wesentlichen direkt in den Kernel geladen werden m\u00fcssen, k\u00f6nnen die von AVM immer noch auf ihrem FTP-Server<\/a> zur Verf\u00fcgung gestellten Versionen nicht mehr auf aktuelle Kernels angewandt werden. Das Paket, das man sich vom Server herunterladen kann, enth\u00e4lt einen quelloffenen Teil, der f\u00fcr die Schnittstelle zwischen Kernel und Hardwarezugriff zust\u00e4ndig ist und einen Closed-Sourceanteil, der im Wesentlichen f\u00fcr die Firmware der AVM-Karte genutzt wird. Weil die Wartung des Treibers seitens AVM eingestellt wurde und sich allerdings sehr viele abh\u00e4ngigen C-Headerdateien ge\u00e4ndert haben (insb. in der Kernelserie 2.6), ist ein Neukompilieren ohne Modifikation des quelloffenen Teils des Treibers nicht m\u00f6glich. In der Community gibt es allerdings immer wieder sehr findige C-Programmierer, die entsprechende Patches f\u00fcr den Sourcecode erarbeiten (\u00c4nderungen an der Firmware scheinen wohl nicht gemacht werden zu m\u00fcssen) und diese dann ver\u00f6ffentlichen. Kompliziert wird es nur dadurch, da\u00df manche Patches auf anderen Patches aufbauen und so erst mal die korrekte “Patchreihenfolge” herausgefunden werden mu\u00df.<\/p>\n Derzeit sind Fedora Core 12-Benutzer, die ihre AVM Fritzkarte zum Laufen bringen wollen allerdings in einer recht gl\u00fccklichen Lage: Das ATrpms-Repository<\/a> stellt entsprechend vorkompilierte, bereits gepatchte RPM-Pakete f\u00fcr jede ver\u00f6ffentlichte FC12-Kernelversion zur Verf\u00fcgung (ggf. mit leichtem Zeitversatz). Die Installation dieser Pakete ist \u00fcber yum bzw. rpm m\u00f6glich. Unabh\u00e4ngig davon, ob man ich den Kartentreiber \u00fcber 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\u00f6tig sind, bietet eine Wiki-Seite auf der FedoraWiki<\/a>. Im wesentlichen mu\u00df also dort <\/p>\n werden. In einem konkreten Fall mit Fedora Core 12 zeigte sich, da\u00df die Erstellung der Datei Auch hier ist wieder zu beachten: Ist das Erstellen der Datei notwendig, so mu\u00df dies bei jedem Neustart wieder durchgef\u00fchrt werden (Details siehe unten). Zu diesem Zweck empfiehlt es sich eine Datei Wie bei allen Serviceskripts notwendig, mu\u00df das Skript per <\/p>\n zun\u00e4chst aktiviert werden.<\/p>\n F\u00fcr alle diejenigen, die “nur” eine Unterst\u00fctzung der CAPI-Schnittstelle f\u00fcr ihre Programme ben\u00f6tigen, 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 <\/p>\n Diese Programme befinden sich alle im ISDN4KUtils-Paket, das FC12 immer noch wie \u00fcblich zur Verf\u00fcgung stellt. Allerdings k\u00f6nnen diese nicht direkt auf die CAPI-Schnittstelle zugreifen. F\u00fcr diesen Zweck gibt es ein besonderes Kernelmodul, das die CAPI-Schnittstelle auf die ISDN-Subsystemschnittstelle \u00fcbersetzt. Dies hei\u00dft durchaus etwas unintuitiv “capidrv.ko” – der nicht eingeweihte Leser w\u00fcrde dahinter wohl eher das Basis-CAPI-Subsystem erwarten. Dessen Anwendung wird auf den mISDN-Wikiseiten<\/a> recht unprosaisch vorgestellt und ist zudem auch noch stark aus dem Zusammenhang gerissen. Alleine von zentraler Bedeutung sind die folgenden Kommandos:<\/p>\nDer einfache Weg des CAPIs<\/h4>\n
\n
\/dev\/capi20<\/code> via udev (wie oben beschrieben) nicht ausreichte. Das Problem beim Systemstart war, da\u00df 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<\/a>. Das zentrale Kommando dabei ist<\/p>\n\r\nmknod \/dev\/capi20 c 68 0\r\n<\/pre>\n
\/etc\/rc.d\/init.d\/capi-pre<\/code> zu erzeugen, die folgenden Inhalt aufweist:<\/p>\n\r\n#! \/bin\/bash\r\n#\r\n# chkconfig: 2345 8 90\r\n# description: start and stop capi services for passive ISDN cards\r\n#\r\n\r\nPATH=\/bin:\/sbin:\/usr\/bin:\/usr\/sbin\r\n\r\n# Source function library.\r\nif [ -f \/etc\/init.d\/functions ]; then\r\n . \/etc\/init.d\/functions\r\nelif [ -f \/etc\/rc.d\/init.d\/functions ] ; then\r\n . \/etc\/rc.d\/init.d\/functions\r\nelse\r\n exit 0\r\nfi\r\n\r\n[ -f \/sbin\/capiinit ] || exit 0\r\n[ -f \/etc\/capi.conf ] || exit 0\r\nRETVAL=0\r\n\r\nfunction start()\r\n{\r\n # don't start again if it's already started\r\n action $\"preparing capi4linux:\" mknod -m 666 \/dev\/capi20 c 68 0\r\n RETVAL=$?\r\n}\r\n\r\nfunction stop()\r\n{\r\n RETVAL=0\r\n}\r\n\r\nfunction restart()\r\n{\r\n RETVAL=0\r\n}\r\nfunction condrestart()\r\n{\r\n RETVAL=0\r\n}\r\n\r\nfunction status()\r\n{\r\n capiinfo\r\n}\r\n\r\ncase \"$1\" in \r\n start)\r\n start\r\n ;;\r\n stop)\r\n stop\r\n ;;\r\n restart)\r\n restart\r\n ;;\r\n condrestart)\r\n condrestart\r\n ;;\r\n status)\r\n status\r\n ;;\r\n *)\r\n echo $\"Usage: $0 {start|stop|restart|status|condrestart}\"\r\n exit 1\r\nesac\r\n\r\nexit 0\r\n<\/pre>\n\r\nchkconfig --add capi-pre\r\nchkconfig capi-pre on\r\n<\/pre>\n
ISDN4KUtils – und nu’?<\/h4>\n
\n
\r\nmodprobe capidrv\r\n\r\nmknod -m 660 \/dev\/ttyI0 c 43 0\r\nmknod -m 660 \/dev\/ttyI1 c 43 1\r\n...\r\nmknod -m 660 \/dev\/ttyI20 c 43 20\r\n<\/pre>\n