Wer heutzutage über Bluetooth Netzwerk schreibt, hat sich wohl als Erstes mal zu rechtfertigen.
Bluetooth heute?
Das in Zeiten wo WLAN in Standards ABGN und noch einigen weiteren Erweiterungen, in allen möglichen Frequenzen verfügbar ist. Ohne mich jetzt unnötig in technischen Details zu verlieren, die ich zugegebenermaßen ohnehin selbst nachschlagen müsste, stelle ich einfach mal die Behauptung in den Raum, dass Bluetooth sich teilweise für mobile Geräte einiges besser eignet als WLAN.
Obwohl beide Techniken ungefähr zur gleichen Zeit zum Endnutzer vordrangen und ursprünglich im gleichen Frequenzband liegen, wurden sie doch mit sehr unterschiedlichen Zielsetzungen entwickelt. Auch in den ersten WLAN Standards findet sich eine Menge zum Thema Powersaving. Aber:
In der Praxis hat es nie wirklich das Tageslicht erblickt. Sendeleistung ist nur in einigen Treibern überhaupt konfigurierbar, in noch weniger Fällen wird diese automatisch angepasst. Stattdessen verfolgte man beim WLAN hauptsächlich ein Standby Konzept. Wenn ein Client nichts zu senden hat, legt er sich für eine definierte Zeit schlafen, in der er nicht mehr erreicht werden kann. Im normalen Betrieb ergab sich daraus eine durchaus unangenehme Latenz, verbindungsorientierte Übertragungen können dadurch unterbrochen werden.
Das alles zusammen führte in letzter Konsequenz dazu, dass sich Powersaving im WLAN Bereich nur minimal und sehr defensiv durchsetzte. Für WLAN im Heimbereich war es nicht relevant, solange es nur darum ging Kabel zu sparen. Für größere Laptops ist der Stromverbrauch von WLAN im Vergleich zum Gesamtverbauch auch nicht wirklich kritisch.
Kritisch wurde der Stromverbrauch erst mit Geräten, bei denen das Halten einer WLAN Verbindung für den Standbybetrieb inakzeptabel wurde. Auf den meisten Mobilgeräten ist dies kaum möglich. Verwendet man eine App, die nicht nur zyklisch Daten abfragt, sondern dauerhaft eine Verbindung benötig, so wird diese höchstwahrscheinlich nach recht kurzer Zeit im Standby abbrechen. Sogar wenn man per Hand alle möglichen WLAN Einstellungen verdreht, ist man leider immer noch nicht vor Verbindungsabbrüchen im Standby sicher. Dies ist unter anderem auch von der verwendeten Netzwerkhardware abhängig. Eigentlich wollte ich ursprünglich noch ein How-To schreiben, aber so viel gibt es diesmal nicht zu tun. Erneut scheint der Textteil deutlich zu überwiegen.
Eine Garantie dafür, dass es funktioniert gibt es auch nicht. Bluetooth unter Linux ist seit Jahren ein Graus. Außer dem Projekt BlueZ gibt es nichts, was nennenswerte Bekanntheit erreicht hätte. BlueZ wiederum ist nicht gerade das, was ich als ein Linux Vorzeigeprojekt bezeichnen würde.
Ohne mich in die Tiefen der Quellcodes gegraben zu haben, schildere ich hier nur den Eindruck, den ich als langjähriger Nutzer gewonnen habe:
Die ersten Versionen hatten einen straight forward Ansatz, wie er im embedded Linux Umfeld üblich ist. Bestehend aus Kerneltreiber und ein paar Daemons, die sich jeweils um sehr eng gesteckte Aufgabengebiete kümmerten. Konfiguriert und gesteuert wurde diese Infrastruktur, von funktional gehaltenen kleinen Binärprogrammen, die direkt mit den Daemons kommunizierten.
Dann kam eine folgenschwere Entscheidung, von der sich Bluetooth auf Linux bis heute nicht ganz erholt hat. Statt das Projekt erwachsen werden zu lassen und erst einmal die Infrastruktur auf alle möglichen Bluetooth Funktionen (und Bluetooth kann bedeutend mehr, als nur Bilder versenden und FTP) zu erweitern, hat irgend jemand beschlossen, dass BlueZ in der alten Form nicht mehr zeitgemäß ist und für den Desktopbetrieb die Infrastruktur komplett umgebaut werden müsste. Anscheinend gefiel es den Entscheidungsträgern nicht, dass die Netzwerkverwaltungsapplets der Desktopdistributionen die Daemons nicht direkt umkonfigurieren konnten, sondern stattdessen dazu jene kleinen Binärprogramme aufgerufen werden mussten.
Das einzig hierfür gültige Argument wäre ein ernst zu nehmender Overhead. Ein Solcher ergibt sich aber realistisch wohl erst bei ein paar Tausend Vorgängen pro Sekunde. Dennoch wurde das Projekt in der Folgezeit funktional auf Eis gelegt und seitdem in Schneckentempo an der Infrastruktur gebastelt.
Die Entscheidung gegen eine Vielzahl kleinerer Daemons, die sich um sehr enge Bereiche kümmern, hin zu dem großen allzweck bluetoothd **Daemon, kann ich mit viel Wohlwollen noch nachvollziehen, auch wenn man sich damit eine deutlich größere Fehlerdomäne heranzüchtet, da nun schlimmstenfalls nicht mehr eine Bluetooth Funktion abstürzt, sondern gleich alles. Gerade, wenn man mit wackeligen exotischen Funktionen arbeitet, ist es nicht gerade ein Fortschritt, wenn beim experimentieren gleich immer Alles ausfällt.
Absolut nicht nachvollziehbar ist für mich aber die Entscheidung, die komplette Kommunikation über DBUS abzuwickeln. Ein derart komplexer Nachrichtenbus, sollte für Kommunikation auf Applikationslevel vorgesehen sein und zumindest nicht der einzige Weg sein, dem Bluetoothd irgendetwas mitzuteilen. Jede embedded Plattform wird im Zuge dieser Entwicklung DBUS implementieren müssen, um überhaupt die neueren BlueZ Versionen verwenden zu können.
Auch die Migration dahin verlief alles andere als sauber. Zeitweise liefen beide Ansätze quasi parallel, die kleinen Binärtools wurden umgeschrieben, den Bluetoothd zu nutzen, einige weitere Daemons wurden dennoch gebraucht und bis Heute fehlt ein halbwegs vernünftiges Desktop Applet, dass mehr kann als Filetransfer (wenn er denn mal funktioniert) und Eingabegeräte einbinden. Blueman geht da immerhin schon einmal in die richtige Richtung.
Das Wirrwar um die Bluetooth Funktionen lässt sich auf einen kurzen Blick erfassen, wenn man mal mit dem sdptool und seiner browse Funktion ein Gerät abscannt. Die, zugegebenermaßen schwer zu lesende, Auflistung der verfügbaren Dienste zeigt, was das Gerät glaubt zu können und mit welchen Protokollen man diese Funktionen erreichen könnte. Hier sollte einiges mehr stehen, als die GUIs einem gefiltert offerieren. Noch weniger davon wird das Gerät aber tatsächlich können, denn nicht mal diese Listen werden ordnungsgemäß geführt. Dieses Problem beschränkt sich aber nicht nur auf Linux.
Kommen wir nun also zu dem, worüber ich eigentlich schreiben wollte:
Ethernet über Bluetooth
Wie schon erwähnt, bietet Bluetooth einiges mehr, als nur Eingabegeräte, Filetransfer und FTP. Schon seit sehr langer Zeit gehört auch IP fähige Ethernetemulation zum Standard. Ethernetemulation heißt in diesem Zusammenhang übrigens PAN (Personal Area Network). Recht schnell findet man dazu auch ein How-To aus den besseren Tagen des BlueZ Projekts. Inzwischen funktioniert davon leider so ziemlich gar nichts mehr. Die Ankündigung, die entsprechenden Compat Pakete demnächst komplett zu entfernen, klingt in diesem Zusammenhang fast wie eine Drohung. Jedenfalls halte ich es deshalb nicht mehr für eine gute Idee, noch lange auf diese Tools zu setzen. Aber zunächst die Grundlagen.
PAN kann als Group Ad Hoc Network realisiert werden, einem eher losem Verbund mehrer Client Nodes (PANU) mit einem Verwaltenden Master Node (GN). Diese Betriebsart ist für nicht statische, isolierte lokale Netze gedacht.
Für den Ersatz bzw. die Ergänzung von WLAN eignet sich eher die Betriebsart mit einem Network Access Point (NAP). Dieser stellt dann die Verbindung vom LAN, WAN, oder auch diesem ominösen Internet bereit.
Wird auf einem Bluetooth Adapter mit einem aktuellen BlueZ Stack die NAP Funktionalität aktiviert, so braucht man zwingend eine virtuelle Ethernet Bridge. Das Starten des Dienstes erzeugt nicht sofort ein Ethernet Interface, welches verwaltet, oder konfiguriert werden könnte. Stattdessen wird das Interface dynamisch erzeugt, wenn ein Client sich verbindet. Es ist keine automatisierte Konfiguration des Interfaces vorgesehen, wie man sie in Form von Up- und Downscripts. ggf. von anderen Projekten kennt.
Dadurch wird die Bridge erforderlich. Das einzige was der Dienst macht, ist ein Interface erzeugen, es hochzufahren und dann automatisch in eine vorher per Kommandozeile angegebene Bridge zu hängen. Das funktioniert überraschend gut und ist, von dem bisschen extra Aufwand die Bridge zu erstellen, sehr einfach.
Wie man eine Bridge erstellt und konfiguriert habe ich schon an anderer Stelle beschrieben und gehe daher nicht mehr detailliert darauf ein.
Einen kleinen technischen Haken hat die Geschichte noch und dieser Haken hat mich mehrere Tage und eine Fehlinvestition gekostet. Hardwareseitig ist der NAP Dienst ist nicht in allen Bluetooth Dongles oder Laptopmodulen implementiert. Nicht mal dass er sich starten lässt, ist eine Garantie dafür, dass er dann auch richtig funktioniert. Mit meinen neusten beiden Dongles ging es z.B. nicht. Mit beiden ließ der Dienst sich starten und eine Verbindung mit Mobilgeräten konnte aufgebaut werden. Nach kurzer Verwendung flog die Verbindung dann ohne verwendbare Fehlerberichte raus. Ein Blick in die syslog gibt nur Auskunft über ein hohes Aufkommen von Fehlerhaften ACL Paketen, bevor die Verbindung abbricht.
Klar ACL Pakete. Was auch immer das nun sein soll. So nah wollte ich mich nun eigentlich auch nicht mit der Protokollebene beschäftigen. Etwa eine Stunde Recherche auf Google bringt zu der Fehlermeldung nur immer wieder die gleichen Fehlerberichte zu Tage, wo Nutzer nach einem Systemupdate Probleme damit hatten ihre Logitech Bluetooth Maus zu verwenden.
Bezüglich PAN gibt es keine Treffer nicht einmal irgendwelche Details, was das nun für Pakete sind, warum sie Defekt sein könnten und wie man es beheben könnte. Einige Stunden genervtes Gefrickel später, hatte ich dann raus, dass es sich wohl um ein Problem zwischen Treiber und Dongle handelt. Mit einem zehn Jahre alten Bluetooth V1.0 Class A Adapter ging es dann nämlich plötzlich tadellos.
Sollte dieses Problem bei Irgendjemandem auftreten, kann ich also leider auch überhaupt keine Hilfestellung geben. Abhilfe könnten da nur die Entwickler des BlueZ Stacks selbst schaffen.
Was ist zu tun?
Als Erstes braucht man die aktuellen Binärtools des BlueZ Projektes. Die sind zumindest bei einem Stock Ubuntu noch nicht installiert. Es gibt zwar ein paar Demo Tools mit den Namen bluez-test-*, aber die sind wohl eher Anschauungsmaterial und nicht für den Dauergebrauch gedacht. Es handelt sich um Python (!!!?) Skripte. Im Network Skript ist ein willkürlicher Timeout eingebaut, nachdem der Dienst einfach wieder runter fährt. Es kursieren zwar einige Hacks im Netz, die es für den Dauergebrauch flott machen sollen, aber die funktionierten bei mir nicht und dann ist da noch diese Hemmschwelle.
Einen Systemdienst über ein nicht terminierendes Python Skript konfigurieren, das dann mit samt dem Interpreter im Speicher rumgammelt, bis der Dienst beendet wird? Sonst geht’s Euch aber gut, oder?
Also, mal vorausgesetzt, der geneigte Leser möchte ebenso wie ich, den Dienst nicht von einem wackeligen Hochsprachenskript abhängig machen, dann empfiehlt sich stattdessen die Installation der bluez-tools. Vorausgesetzt das Paket ist auf Deiner Distribution verfügbar, sollte es mit dem Paketmanager deiner Wahl zu beschaffen sein.
Unter Ubuntu und vermutlich damit auch Debian geht es in einem Terminal folgendermaßen:
sudo apt-get install bluez-tools
Aber Vorsicht: Bei mir auf dem Desktop (mit XUbuntu) führt das geradewegs in einen Konflikt. Das Paket enthält ein paar OBEX Tools (das ist der Dienst mit dem Muttis Bilder von ihren Kindern tauschen), die gerne diejenigen ersetzen würden, von denen das Systemapplet Blueman abhängt.
Bei einer Serverinstallation sollte dies nicht weiter stören, denn wer hat schon eine grafische Oberfläche. Für meinen Laptop hieß das:
“tschüß Blueman!”
Ab jetzt wird Bluetooth eben über die Kommandozeile verwaltet. Genau das muss im Folgenden noch gemacht werden, damit der Dienst genutzt werden kann.
Eine PAN Verbindung kann nämlich erst aufgebaut werden, wenn die beteiligten Geräte gepaart sind und einander noch mal explizit vertrauen (Trust). Über das Letztere bin ich dann auch noch einmal gestolpert. Selbst wenn die Geräte gepaart sind, wird die Verbindung ohne Trust nicht aufgebaut. Im syslog findet sich dazu dann nur eine winzige security exception.
Je nach Gerätekombination kann das Pairing von beiden Geräten initiiert werden, oder nur von einer Seite.
Äh? Wieso das denn?
Weil die Praxis mal wieder anders aussieht, als die Theorie. Am Pairing sind softwareseitig einige Timeouts beteiligt, die auf meinem Nexus7 dazu führten, dass ich in etwa eine Sekunde Zeit hatte, einen vierstelligen Code einzugeben und mit Fertig zu bestätigen, bevor das Fenster einfach wieder verschwand. Da ich das in dieser Zeitspanne kein einziges Mal geschafft habe, weis ich jetzt nicht, ob es überhaupt funktioniert hätte.
Eine allgemeingültige Anleitung zum Pairing kann ich aus diesem Grund dafür nicht angeben. Aber ich kann die Tools nennen, die man dazu braucht.
Auf der Serverseite wird man ohne die MAC Adresse des Clients nicht weit kommen. Da wir alle es hassen, diese viel zu langen MAC Adressen abtippen zu müssen, bietet es sich hier an, den Client auf sichtbar zu stellen. Bitte dabei nicht vergessen, dass er sich im Regelfall nach recht kurzer Zeit von alleine wieder auf unsichtbar stellen wird.
Ab hier bauchen wir für jeden weiteren Befehl Administratorrechte, weshalb für die anstehende Bastellei auf eine Root Konsole gewechselt werden sollte.
sudo -s
Willkommen in der Root-Shell.
Das Scannen nach auffindbaren Bluetooth Geräten ist eine Funktion des Adapters. Jeder Bluetooth Adapter erhält vom BlueZ eine eigene Liste von Geräten mit denen er gepaart ist und denen er vertraut. Dies bitte nicht vergessen, falls Ihr Experimente mit mehreren Adaptern vor habt.
Ein Scan kann zwar weiterhin auch mit dem hcitool initiiert werden, aber wir sind ja up to date.
bt-adapter -d
Ich gehe jetzt mal davon aus, dass der gewünschte Client in der Liste ist. Die MAC Adresse sollte jetzt irgendwo hinterlegt werden, wo man sie beliebig oft wieder rauskopieren kann.
So. Jetzt hätte ich beim Schreiben beinahe einen Fehler gemacht, der mir auch beim Basteln passiert ist. Die meisten Geräte fragen nämlich nur genau ein mal ab, welche Dienste der Partner anbietet und das ist beim Pairing. Dabei kommt das weiter oben schon erwähnte Service Discovery Protokoll (SDP) zum Einsatz. Dabei wird eine kryptische Liste mit teils numerischen Identifiern und Zoix(tm) getauscht. Der NAP Dienst wird aber erst in der Liste des Servers geführt, wenn er auch aktiv ist. Irgendwie logisch, oder? Das machen wir jetzt also mal ganz schnell zwischendurch.
bt-network -s nap <BRIDGE> &
Das war’s auch schon. Der Dienst läuft und ist im SDP registriert. Ich bitte darum, das kaufmännische Und am Ende der Zeile nicht zu vergessen, da das Tool sich nicht selbst in den Hintergrund begibt, und ansonsten die Kommandozeile blockiert. Natürlich könnte man hier mit einem beherzten Strg + Z und dem darauffolgenden Befehl bg (Background) Abhilfe schaffen.
Der Dienst ist nun also da. War es das nicht schon?
Nein leider nicht. Man findet den Dienst jetzt zwar mit dem sdptool, aber verbinden können sich nur Geräte, die gepaart sind, einander vertrauen und vor allem überhaupt wissen, dass der Dienst verfügbar ist. Wenn die Geräte schon mal gepaart waren, sollte der Client in den meisten Fällen noch mal entfernt werden, damit er beim nächsten Mal eine aktuelle Liste der Dienste bezieht.
bt-device -r <CLIENT MAC>
Wird den Client bei Bedarf Serverseitig aus der Liste der bekannten Clients und auch der Trustliste entfernen.
Das Pairing kann jetzt aktiv oder passiv erfolgen. Aktiv geht des so:
bt-device -c <CLIENT MAC>
Dadurch wird automatisch bei Bedarf der bt-agent gestartet, der sich um den Rest des Parings kümmern wird. Je nachdem, welche Bluetooth Versionen beteiligt sind. Müssen jetzt Nummern getauscht werden, oder nur bestätigt, oder eine DNA Probe abgegeben werden.
Wenn die aktive Variante des Pairings nicht funktioniert, kann der Server das auch passiv. Dazu muss der bt-agent einfach manuell gestartet werden. Allerdings sollte der Server in diesem Zeitraum überhaupt sichtbar sein, sonst macht das herzlich wenig Sinn.
bt-adapter --set Discoverable True bt-agent
Achtung: Der Kram legt Wert auf korrekte Groß- und Kleinschreibung (WTF!)
Ebenso wie der bt-network Dienst, blockiert auch der Agent die Kommandozeile. In diesem Fall ist das aber wünschenswert, weil wir sie für die nötigen Eingaben brauchen werden. Wie schon bei der aktiven Variante, sollte der Pairingprozess relativ selbsterklärend sein.
Da man anscheinend davon ausging, dass gleich mehrere hundert Clients angemeldet werden sollen, beendet sich der Agent nicht selbst, sondern muss via Strg + C terminiert werden (seufz).
Das war’s jetzt schon - fast!
Da wäre immer noch die Sache mit dem Vertrauen. Der NAP Dienst ist nämlich verdammt misstrauisch und lässt absolut niemanden rein, dem er nicht vertraut. Selbst wenn er in Form des Pairings eigentlich schon den Haustürschlüssel hat.
Du kommst hier vielleicht rein. Aber reden tu’ ich deshalb noch lange nicht mit dir!
Also gut, dann müssen wir halt für eine sanfte Annäherung sorgen:
bt-device --set <CLIENT MAC> Trusted True
Damit sollte der Weg jetzt frei sein! - Oder, was jetzt gehen sollte:
Der Server wird auf dem Client als Computer angezeigt. Je nach Betriebsystem, bei mir sind das diverse Androiden, kann man eine Liste der verfügbaren Dienste unter Details anzeigen. Dort gibt es dann auch einen Dienst Namens Internetfreigabe, oder so ähnlich.
Klickt man diese Freigabe an, baut der Client eine Verbindung zum Server auf. Der NAP Server erzeugt ein Ethernetinterface und fügt es der Ethernetbridge hinzu. Von der Bridge aus sollte ein DHCP Server zu erreichen sein, denn der Client wird als nächstes versuchen eine IP Adresse zu beziehen und DNS Server und Gateway zu konfigurieren. Im trivialsten Fall wird das alles der Router erledigen, der die Internetverbindung bereitstellt. Bei Problemen muss also nur überprüft werden, ob die Bridge richtig funktioniert. Wenn das Bridgeinterface selbst über DHCP keine Adresse bekommt und keine Verbindung zum Internet herstellen kann, dass wird dies auch keinem Interface gelingen, das der Bridge hinzugefügt wurde.
In meinem Fall habe ich durch dieses doch recht beschauliche Setup jetzt endlich eine stabile Verbindung mit meinen Mobilgeräten, selbst wenn diese sich im Standby befinden. Verbinde ich mich stattdessen z.B. über WLAN auf den SSH Server meines Tablets, erhalte ich ein Netzwerklag, welches sich in etwa wie eine gestörte GPRS Verbindung verhält, sobald der Bildschirm aus ist.
Bluetooth hingegen bleibt uneingeschränkt performant, hat aber zugegebenermaßen grundsätzlich eine deutlich geringere Durchsatzrate als WLAN und ist damit für größere Downloads und Internetvideos ungeeignet. Dafür hat man aber eine stabile Verbindung die auch ohne Probleme die ganze Nacht übersteht.