#AlwaysOnDevice

Habt ihr schon mal versucht im ICE zu surfen?

Ich auch.

Habt ihr dann auch nach kurzer Zeit eurer MacBook auf den Tisch im ICE-Großraumabteil geschlagen und damit vergeblich versucht, die vermeintlichen Errungenschaften einer digital immer weiter zusammenwachsenden Gesellschaft in das Bewusstsein eurer Mitreisenden zu hämmern?

Gut…ich auch nicht.

Ein Scheißprodukt!

Dennoch ist klar: was die Telekom im ICE als „Surfen“ oder „Internet“ bewirbt, ist eine große, stinkende Farce. Nicht weil die technische Umsetzung so schlecht ist, sondern weil man sie nicht konsequent zu Ende gedacht hat.
Kurz zur Erinnerung: im ICE gibt es ein „Internetangebot“ der Telekom: In jedem Wagen hängen WiFi-Access-Points, die manchmal per Kabel, manchmal aber einfach nur über weitere WiFis miteinander verbridget sind. Das ganze endet dann in einem Router pro Zug, der wiederum über das Telekom-Mobilfunknetz eine Internetverbindung aufbaut.

Die Performance ist miserabel. Mal ein Megabit pro Sekunde über die Leitung zu bekommen ist ausgesprochenes Glück und mit zeitweisen Latenzen von mehr als 17 Sekunden (Sekunden, nicht Millisekunden!) gibt es – genau – nichts, was man mit der Leitung sinnvoll hinbekommt. Es ist einfach nur ein großer Haufen Scheiße, der den unwissenden Kunden als Internetzugang verkauft wird. Willkommen im Telekom-Monopolismus.

Ein Scheißprodukt?

Aber schauen wir mal auf das größere Bild:
Natürlich ist die Frage, wie man so ein bis zu 300 Km/h schnelles Gefährt vernünftig ans Internet anbinden kann alles andere als trivial. Das Telekom-Netz ist vielleicht das beste in Deutschland (vielleicht ist es momentan auch wieder Vodafone, keine Ahnung, ist mir auch egal), dennoch kann man generell sagen, dass die deutsche Mobilfunkinfrastruktur im Vergleich mit anderen Industrienationen einfach scheiße ist.
Da wird das Ergebnis nicht besser, wenn sich neben der ICE-Hardware noch die 200 Telefone der mitreisenden Telekom-Kunden im Vorbeifahren in eine Zelle einbuchen.

Eine Lösung für diesen Problem wäre z.B. ein dediziertes Netz der Telekom für die Anbindung der Züge. Das hat man auch schon ausprobiert, als dieses Projekt noch in den Kinderschuhen steckte. Man verwendete damals (zumindest teilweise) alte UHF-Frequenzen und den Flash-OFDM-Standard.
So ein extra Netz zu betreiben kostet natürlich Geld (von den geringen Datenraten, die Flash-OFDM bietet mal ganz zu schweigen). Geld ausgeben mag die Telekom gar nicht, siehe Vectoring.

Eine andere Lösung wäre, den Reisenden einfach die Nutzung von Mobiltelefonen im Zug nur in Notfällen zu erlauben, um mehr Bandbreite für den Zugserver zur Verfügung zu haben. Der Empfang ist dank metallbedampfter Fenster und mangelhafter GSM-only-Repeater eh miserabel und an Nervfaktoren im ICE rangieren lautstark in Telefone brüllende Menschen („HÖRST DU MICH?!“) direkt hinter militanten Eltern („WAS HEISST HIER RUHEWAGEN!? DAS SIND KINDER!“) und übergroßen Koffern im Gang („ICH KANN DIESEN KOFFER NICHT NACH OBEN HEBEN!“).

Zwischenlösung

Da ich mich eh schnell von dummen Menschen im öffentlichen Personenverkehr reizen lasse, gibt es eine relativ einfache Lösung, um beim „Surfen“ im Zug nicht vollkommen auszurasten: ein Ping zu Google. Wenn die Lieblingspornoseite nicht laden will, ist über den auslaufenden Ping sehr bequem erkennbar, dass nicht etwa der überdimensionale Penis im Clip die lange Ladezeit verursacht, sondern eben die gerade nicht existente Verbindung zum Internet.

1-Device-Only

Doch ständig den Ping in einem Fenster offen zu haben ist spätestens bei Fullscreen-Porn unpraktikabel. Dazu kommt erschwerend, dass der Telekom-Hotspot immer nur ein Gerät mit den gleichen Zugangsdaten erlaubt, ich im schlimmsten Fall also nicht in der Lage bin, den Porno auf einem Second-Screen zu kommentieren. Das geht natürlich gar nicht, Second Screen ist schließlich gerade der heiße Scheiß.

Sicherheitsaspekte

Wer sich wirklich dazu erdreistet, im ICE Pornos zu schauen, wird sich wahrscheinlich keine allzu großen Gedanken zum Thema Privatsphäre machen. Aber mal ganz im Ernst: es gibt noch erschreckend viele Webseiten, die ausschließlich Login-Daten verschlüsselt übertragen, alles andere aber im Cleartext über den Äther rauscht tröpfelt. Da das WiFi selbst natürlich unverschlüsselt ist, stellt dieser Fakt ein großes Sicherheitsrisiko dar, welches den meisten Nutzern nicht bewusst sein dürfte.
Die Telekom bietet zwar einen VPN-Client an, aber letztlich sollten Nutzer nicht irgendwelche Software aus irgendwelchen Quellen installieren müssen, um sicher zu surfen. Wie man es richtig macht, hat mir die WiFi-Installation der letzten CCC-Veranstaltungen gezeigt (WPA-Radius mit Wildcards).

[Natürlich darf man solch innovative Lösungen nicht von der Telekom erwarten.]

Lösung in einem Paket

Ich überlegte mir also irgendwann, dass eine Linux-Box praktisch wäre, die all meine Probleme mit dem Thema „Surfen im Zug“ lösen könnte.

  • Lückenhafte Abdeckung des Telekom-Netzes –> Failover mit LTE-Stick im Vodafone-Netz, automatische Erreichbarkeitstests mit Auto-Login am Hotspot
  • 1-Device-Only –> Die Linux-Box als „Proxy“, der Access Point für weitere Geräte ist
  • Sicherheitsaspekte –> komplettes Tunneling des Traffics über eine VPN-Technologie

Hardware-Anforderungen

Diese Lösungen sind technisch nicht sehr kniffelig umzusetzen. Viel schwerer war es aber, eine Hardwareplattform zu finden, die alle Vorraussetzungen erfüllte:

  • Schnelle USB-Implementierung für den LTE-Dongle
  • Weitere (nicht per USB-Hub gelöste) USB-Implementierung für den „empfangenden“ (also mit dem Hotspot verbundenen) WiFi-Dongle
  • Integriertes WiFi (für eigenen Access Point, mit dem sich Clients verbinden)
  • Halbwegs starker Prozessor, wegen VPN; optimaler Weise Hardware-Crypto
  • Wenn alles super ist: Ladeelektronik (das Ding soll ja auch mobil funktionieren)

Ich habe mir relativ viele Boards angeschaut. Der Raspberry Pi ist nach wie vor zu langsam, auch in seiner aktuellen Ausführung. Die USB-Implementierung ist lächerlich, es gibt keinen eingebauten WiFi-Chip und der LAN-Port ist auch nur via USB angebunden.

Hardware

Main-Board

Andere Boards wirkten dank ihrer Mini-PCIe-Slots sehr interessant (WiFi-Anbindung!), aber am Ende entschied ich mich für einen Banana Pro. Für diesen gibt es nämlich mit „Bananian“ ein relativ schmales, angepasstes Debian, das Erfahrungsberichten nach sehr zuverlässig läuft. Leider kommt mit Bananian nur ein relativ alter Linux-Kernel, den man zwar über die Bananian-Repositories updaten kann, dann aber auf viele Funktionen des Boards verzichten muss (etwa auf den WiFi-Chip und USB-OTG).

Auf meinem Board läuft also Bananian mit dem alten Kernel. Daran stecken ein Huawei LTE-Stick mit „hilink“-Technologie, ein TP-Link WiFi-Dongle (RTL8192CU), der als Access Point agiert sowie ein weiterer TP-Link WiFi-Dongle (RT3573) mit Dualband-Unterstützung.

LTE-Dongle

Bei dem LTE-Dongle handelt es sich um das Modell E3372 von Huawei, welches die sogenannte „hilink“-Technologie einsetzt. „hilink“ heißt eigentlich nur, dass der Stick nicht als Modem erkannt wird, sondern als USB-Ethernet-Adapter. Der Dongle hat also sein eigenes Webinterface, über das er sehr komfortabel zu konfigurieren ist. Außerdem kann man mit einer halbwegs nützlichen Rest-API Dinge auslesen.

RTL8192CU

Statt dem integrierten WiFi nutze ich nun einen USB-WiFi-Dongle mit RTL8192CU-Chipsatz als Verbindung zu meinem MacBook und anderen Geräten. Wenn man den Treiber von der Realtek-Website selbst kompiliert, funktioniert dieser auch mit dem alten Kernel. Sogar als Access Point.
Den integrierten Chip kann ich leider nicht nutzen, weil dieser eine eigene, recht kaputte Version von hostapd braucht, mit der man keine Vendor-Elements in die Beacon-Frames des WiFi-APs schreiben kann. Diese Vendor-Elements brauche ich aber, um den Clients ein Apple-Tethering-Netzwerk vorzugaukeln.

RT3573

Als Client-WiFi (als das, was sich im Zug mit dem Telekom-Hotspot verbindet) nutze ich einen ziemlich fetten TP-Link-Dongle mit RT3573-Chipsatz. Auch hier musste ich den Treiber selbst kompilieren. Der Dongle unterstützt auch das 5GHz-Band, sollte die Telekom das irgendwann einsetzen. :'D

Wie ich das ganze softwaremäßig umgesetzt habe, werde ich zu einem späteren Zeitpunkt erläutern.