Lichte Wege
Besonders Notebook-Benutzer stehen vor der Schwierigkeit, ihr System ad hoc in unterschiedliche Umgebungen einzubinden. Zumindest derzeit ist Infrarottechnik aufgrund ihrer Vielseitigkeit dafür das Mittel der Wahl. Unter Linux ist die Benutzung noch mit einigen Hürden verbunden.
- Ulrich Jörgens
- Michael Kuschke
Speziell für mobile Rechner stellt sich das Problem einer Ad-hoc-Integration in wechselnde Umgebungen. Dafür bietet sich die Infra-rot(IR)-Schnittstelle an, über die heute fast jedes Notebook verfügt. Viele Mainboards sind ebenfalls für IR-Übertragungen vorbereitet, andere Geräte wie Handys und Palm Tops werden zunehmend damit ausgestattet.
Für die einwandfreie Verständigung der Gerätegattungen untereinander sorgt ein Zusammenschluss von circa 150 Herstellern, die Infrared Data Association (IrDA). Sie treibt die Standardisierung der physikalischen Übertragung sowie der Protokolle voran und zertifiziert für Produkte für die Einhaltung der Standards. Diese sieinsehen. Die Standardcharakteristika von IR-Datenanbindungen sind:
- Punkt-zu-Punkt-Verbindung mit direkter Sichtlinie,
- Entfernung von bis zu 1 m bei einem Winkel von ±15 Grad,
- Verbindungsgeschwindigkeiten von 9600 Bit/s bis 4 MBit/s, eine Erweiterung auf 16 MBit/s ist in Arbeit.
Für eine Anbindung unter Linux lässt sich entweder ein eingebautes IR-Interface (Diode) oder ein Hardwarezusatz (Dongle) verwenden. Die meisten Notebooks verfügen über eine integrierte IR-Schnittstelle; bei Desktops bieten sich Dongles an, die an einen seriellen oder parallelen Port des PC angeschlossen werden. Manche Mainboards verfügen von Haus aus über ein entsprechendes Interface.
Seit Version 2.2.x beinhaltet der Linux-Kernel IrDA-Support. Dies erfüllt für neuere Distributionen die notwendigen Grundvoraussetzungen bezüglich der Treiber. Zur Nutzung des IrDA-Protokollstacks bedarf es zusätzlicher Komponenten. Zentrale Bestandteile sind in den irda-utils zusammengefasst. Die Einbindung des IrDA-Stacks ist der von PCMCIA-Karten nachempfunden - die eigentliche Steuerung realisiert ein User-Level-Daemon, der irmanager. Dieser übernimmt mit Hilfe von Tools und Hilfsdateien unter /etc/irda die Konfiguration der Protokollelemente und richtet gegebenenfalls Netzwerk und Drucker ein, die die IR-Schnittstelle nutzen. Falls die irda-utils nicht Bestandteil einer Distributionen sind, muss der Anwender sie sich beschaffen (siehe Kasten ‘Fundorte im Web’) und übersetzen.
Praktische Betrachtungen inklusive
Für diesen Artikel wurden Tests mit Notebooks von Dell und Siemens durchgeführt: ein Dell Latitude 233 CP und ein Scenic Mobile 510AGP jeweils mit integrierter IR-Schnittstelle. Die irda-utils lagen in der Version 0.9.3-pre8 vor und liefen unter der Kernelversion 2.2.9 sowohl auf dem Red-Hat-basierten Halloween als auch auf Suse. Der Kernel wurde mit dem aktuellen patch-2.2.9-irda2 versehen. Die Übersetzung der in den irda-utils enthaltenen Werkzeuge irdadump, irdaping und obex erforderte weitere zum Teil nicht enthaltene Werkzeuge. Unter Red Hat fehlte libtool, und bei Suse war zusätzlich autoconf nötig.
Die autoconf.sh-Skripts zeigten sich statisch auf die Umgebung der Entwickler zugeschnitten. So vergleichen sie beim Versions-Check der Werkzeuge, wie libtool, die Ausgaben der Programme (Option -version) mit festen Versionsnummern. So beschwert sich das autoconf.sh von irdadump bei der Verwendung der 1.3.xer Version von libtool, dass libtool Version 1.2 oder höher notwendig sei. Nach dem Anpassen des Shell-Skripts funktionierte das Kompilieren.
Dem Übersetzen der notwendigen Werkzeuge folgt die Konfiguration des Stacks. Hierzu sind die Dateien drivers und network unter /etc/irda anzupassen. Die konkreten Werte hängen vom jeweiligen System respektive Chipsatz ab. Unter Suse funktionierte IrLAN erst nach Modifikation der Datei network. Hier musste ein geeigneter ifconfig-Eintrag anstelle des ifup/ifdown her, da die irda-utils für Red Hat vorkonfiguriert sind. In Red Hat muss nur das Device irlan0 über den Netzwerkmanager eingerichtet werden. Nach dem Starten des irmanager (irmanager -d1 -s1) stand eine Netzwerkverbindung zur Verfügung, die sich als unerwartet performant erwies. Bei unkomprimierten Dateien lag die FTP-Übertragungsrate bei circa 13 KByte/s, mit komprimierten waren es immerhin noch 7 bis 9 KByte/s. Mit zunehmendem Abstand der Notebooks nahm die Verbindungsqualität rapide ab. Es kam zu Aussetzern, die Datenrate sank erheblich. Bei mehr als zwei Metern Distanz war die Verbindung endgültig unterbrochen. Sobald die Geräte wieder näher aneinander rücken, wird die Verbindung automatisch wiederhergestellt.
Interrupts sorgen für Hakeleien
Unerwartete Schwierigkeiten bereitete auf dem Latitude der cardmgr. Dieser belegte bei eingesteckter PCMCIA-Netzwerkkarte den Interrupt 3. Der IR-Port ließ sich erst nach Sperren des Interrupts in der Datei /etc/pcmcia/config.opts ansprechen. Mit den verbleibenden IRQs ließ sich die Netzwerkkarte nicht mehr in Betrieb nehmen. Wer beides gleichzeitig verwenden will, muss unter Umständen die IR-Schnittstelle im BIOS auf COM1 statt COM2 legen. Das heißt aber, auf den seriellen Port zu verzichten.
Doch neben Notebooks und PC verfügen mittlerweile eine Reihe anderer Geräte über IR-Interfaces. Ein beliebter Vertreter ist der Palm III. Dieser lässt sich aber von Haus aus nur über den Cradle gegen einen PC synchronisieren. Voraussetzung für die Kontaktaufnahme mit dem PC ist ein ‘Enhanced Infrared Update’, das kostenlos bei 3Com heruntergeladen werden kann. Diese Software implementiert das IrCOMM-Protokoll, das eine serielle Schnittstelle emuliert. Damit kann man beispielsweise über die Infrarotschnittstelle eines Handys eine TCP/IP-Verbindung aufbauen. Für die Synchronisierung gegen einen PC ist es damit noch nicht getan. Der Abgleich der Objekte erfolgt beim Palm III über das IrOBEX-Protokoll. Abhilfe schafft hier die (kostenpflichtige) Software IrLink von IS/Complete. Ist der Palm III entsprechend präpariert (Beam on), eingeschaltet und auf die IR-Schnittstelle des PC ausgerichtet, taucht er in der Discovery auf. Auf dem Notebook zeigt cat /proc/net/irda/discovery im Erfolgsfall etwa die folgenden Informationen über den Palm an:
# cat /proc/net/irda/discovery
IrLMP: Discovery log:
name: Uli Jörgens, hint: PDA/Palmtop IrOBEX ,
saddr: 0x9a4110b7, daddr: 0x60745746
Damit ist die technische Voraussetzung für einen Datenaustausch geschaffen, der Palm reagiert auf die Signale von irdaping. Für eine sinnvolle Nutzung der Verbindung fehlt nur noch entsprechende Anwendungssoftware. Die Pilot-Link-Tools bieten für diesen Zweck eine umfangreiche Sammlung von Shell-Kommandos, mit denen sich nahezu beliebige Daten zwischen Pilot und Linux übertragen lassen. Angefangen bei Adressen und Terminen über die Installation von Software bis hin zum Auslesen des Palm-ROM findet der Anwender praktisch für alles ein passendes Programm.
So richtig interessant wird es aber erst, wenn auch Applikationen zur Termin- und Adressverwaltung in der Art von Outlook synchronisieren können. KDE stellt hierfür kpilot zur Verfügung. Es ermöglicht die Datensynchronisation mit dem Palm III. Dieser speichert die Daten der sogenannten Conduits wie ToDo, Adressbuch und Kalender im vcs-Format. Das Conduit-Setup legt den Pfad des entsprechenden Synchronisationsfiles fest. Für den korganizer liegt dieses meist unter ~/.kde/share/apps/korganizer. Voraussetzung für kpilot ist KDE 1.1.1, unter Version 1.1 ließ sich das Tool nicht installieren. Zur Synchronisierung über die IR-Schnittstelle dient das Device /dev/irnine. Falls es noch nicht existiert, muss der Benutzer es per mknod /dev/irnine c 60 64) anlegen. /dev/irnine emuliert eine neunpolige RS-232-Schnittstelle inklusive Hardwarefluss- und Modemkontrolle.
Die Übertragungsrate ist zwar mit der des Cradle vergleichbar, allerdings traten bei größeren Datenmengen sporadische Verbindungsabbrüche auf. Eine Datensicherung musste so mehrfach gestartet werden, bis sie vollständig durchlief. Erst durch einen Reset in Form eines ‘brutalen’ Stichs in die Rückseite war der Palm nach einem solchen Verbindungsabbruch wieder zu beleben. Die Ursache haben wir nicht herausfinden können. Im derzeitigen Stadium verlangt die Synchronisierung über IR-Schnittstelle neben einem ausgeprägten Spieltrieb eine gehörige Portion Geduld. Wem diese nicht gegeben ist, der fährt mit der erheblich robusteren Übertragung über Cradle und Kabel allemal besser.
Alle Versuche, einen Windows-CE-Handheld mit Linux-IrDA anzusprechen, führten leider zu keinem befriedigenden Ergebnis. Wohl taucht der Handheld in der Discovery des Linux-Rechners auf, aber die höheren Protokolle (TCP/IP) kommen nicht zusammen. Microsoft scheint hier weder den mit IrLAN vorgegebenen Pfad noch die Emulation einer seriellen Verbindung durch IrCOMM zu unterstützen.
IrDA unter Kontrolle
Nicht zuletzt der Experimentalstatus der Implementierung macht Debugging und Diagnose zur notwendigen Betriebsvoraussetzung. Unter /proc/net/irda gibt es diverse Dateien, mit denen sich den Protokolllayern auf die Finger schauen lässt:
- discovery: listet entdeckte IrDA Partnerrechner auf.
- irias: zeigt alle registrierten Dienste mit Attributen an.
- irda_device: gibt Auskunft über das Low Level IrDA Device.
- irlap, irlmp, irlpt_client irlpt_server, ircomm, irlan und irttp: liefern Informationen über die Instanzen der jeweiligen Protokollschicht.
Dem direkten Einfluss auf den Protokollstack dienen unter /proc/sys/net/irda diverse Pseudodateien. Über geeignete Eingaben in diese Dateien lassen sich beispielsweise Komprimierung und Debugging steuern. So schaltet echo 4 > /proc/sys/net/irda/debug das volle Debugging des IrDA-Stacks ein. Den Namen des Linux-Rechners in der IrDA-Welt kann man über die Datei devname verändern. Diese Anpassung nimmt der irmanager im Zuge der Initialisierung selbstständig vor. Das automatische Entdecken von Infrarotgeräten lässt sich mit 0 oder 1 in der Datei discovery umschalten.
Fazit
Derzeit ist die Treiberentwicklung unter Linux noch lange nicht vollständig. FIR-Treiber für die getesteten Geräte waren nicht verfügbar. Es ist leider praktisch unmöglich, den Chipsatz zu ermitteln. Das komplexe Protokoll tut ein Übriges, sodass Trouble Shooting zur zeitraubenden Aufgabe wird. Im Vergleich zu Windows steht Linux dennoch recht gut da, denn dort wird auf Diagnosemöglichkeiten weitgehend verzichtet. Nicht nur unter Linux sind daher die Einsatzgebiete von IrDA beschränkt. Vermutlich nutzt nur ein Bruchteil der Notebook/PDA/-Besitzer die (fast) obligatorische IrDA-Schnittstelle. Neben den Hardwarefragen wird eine einfache Integration in die zugehörigen Desktop-Anwendungen über Nutzbarkeit und Verbreitung entscheiden. Einzig dem Ad-hoc-Netzwerk zwischen zwei entsprechend ausgestatteten und konfigurierten PCs ohne die Notwendigkeit, erst Kabel zu ziehen, konnten wir einen echten Nutzen abgewinnen. Wenn Bluetooth hält, was die Hersteller versprechen, wird IrDA in einigen Bereichen mächtige Konkurrenz bekommen. Für IrDA spricht die Marktverbreitung und die Verfügbarkeit von Treibern für eine Vielzahl von Systemen. Die Entwicklung zeigt (über die aktuelle Version der irda-utils: 0.9.4, mit einem 2.2.12er Kernel und einem Patch soll sich sogar ein Siemens-C25-Handy ansteuern lassen), dass die Linux-Gemeinde intensiv an den Schwierigkeiten arbeitet. Vielleicht motiviert dieser Artikel ja den einen oder anderen Leser, sich daran zu beteiligen.
Ulrich Jörgens
arbeitet bei der Dr. Materna GmbH als Berater für Systemmanagement.
Michael Kuschke
ist bei NavaraSoft als Entwicklungsleiter tätig.
