WIFIonICE, erste Eindrücke

Ich hatte am Dienstag das überraschende Vergnügen, »WIFIonICE«, die Nach­fol­ge­tech­nik für Inter­net im ICE der Deutschen Bahn, aus­probieren zu können.

Vorab: wie auch seinerzeit vor Einführung des WLAN-Angebots, was seit Dezember 2014 in der ersten Klasse ja kostenfrei war, durfte ich zufällig das Nach­folgeangebot testen, denn klugerweise nutzt die Bahn ihre Kunden als Ver­suchs­kanninchen, um die neue Tech­nik möglichst praxisnah zu testen.

War ich bei den ersten Erspähungen des »Te­le­kom_ICE«-WLANs aber noch hellauf begeistert, wohl auch weil ich der einzige Nutzer war ;), testet heute potentiell der gesamte (zweiteilige) ICE, also Nutzer in der ersten als auch der zweiten Klasse.

Während beim Telekom-Setup ein ICE-Portal (welches u. a., sofern Uplink vorhanden, aktuelle Info zur Verspätung des Zuges präsentierte) die Startseite war und man dann per Klick zum Telekom-Hotspot-Portal weitergeleitet wurde – was bei fehlender Verbindung dann schon nicht mehr klappte, da es extern realisiert wurde –, setzt man aktuell eine ziemlich verstörende Captive-Portal-Lösung ein, die mich auf dem Telefon direkt mich Si­cher­heits­warn­ung­en über­schüt­tete.

Captive Portals (Anfragen eines Clients werden, über DNS-Capturing, auf eine lokale Seite umgeleitet — für die Frage nach der IP-Adresse von google-public-dns-a.google.com wird dann z. B. statt 8.8.8.8 192.168.1.1 zurückgegeben und dort präsentiert dann ein Webserver die Info, daß man $irgen­dwas machen muß, um ins Internet zu kommen) sind halt Kacke, und sie funk­tionieren prinzipbedingt nur mit un­ver­schlüsselten Ver­bind­ungen (http: statt https:) wirklich.

Warum bei meinem Androiden dann https://www.google.com aufgerufen wurde – http://www.google.com hätte den Zweck ja auch erfüllt – verstehe ich nicht. Fakt ist: Android ist ziemlich pissed bei sowas, und hätte ich nicht um diese Dinge gewußt und tapfer http://heise.de im Browser aufgerufen, um das Captive Portal zu bekommen, ich wäre wohl nicht online gegangen. War­nung­en bei SSL, da müs­sen heut­zu­tage bei jedem alle Alarm­glock­en Über­stun­den machen!

Ernsthaft, liebe Deutsche Bahn, DAS solltet Ihr so nicht abnehmen; kann man so machen, ist dann halt Kacke. Aber letztlich habe ich es ja geschafft und konnte mit meinem Mobiltelefon online gehen.

Man möge mir nachsehen, daß die Begeisterung sich in Grenzen hielt — als Passagier der 1. Klasse habe ich nun einmal funktionales WLAN quasi mitgebucht (sonst würde ich, ggf. günstiger, 2. Klasse fahren), und Experimente sind an der Stelle nicht zwingend willkommen, erwartet man ggf. aus $Gründen einen produktionsreifen Zugang. Hier setzt sich die Deutsche Bahn halt latent in die Nesseln, denn funkionales WLAN im ICE erwarte ich heute, ein knapp Jahr nach dem Start, als 1.-Klasse-Passagier einfach. Ist ja auch im Ticket-Preis inklusive …

Aber kommen wir zu den interessanteren Fragen: was bringt das neue, 3-Provider-WLAN, wirklich?

Anfang 2014 habe ich ja mal ein Experiment gemacht, und die Verbindungsqualität des Telekom-Setups während einer Fahrt Güterloh-Berlin per Smokeping aufgezeichnet.

Das Ergebnis war: ja, im Grunde schon mal ein Schritt in die richtige Richtung, aber bis ich verläßlich damit im ICE online wirken kann, fließt noch das eine oder andere Hochwasser die Elbe herunter.

Nun habe ich ja selbst in 2012 schon ähnliche Experimente angestellt: D1, D2 und o2 per Mobilfunkstick an einen zentralen Router angebunden, der »mittels Magie« (verschiedene (OpenVPN-) Tunnel über die Provider und dann OLSR als Routingprotokoll zwischen dem lokalen AP und der stationären Gegenstelle) für Konnektivität sorgt. Das klappte mehr oder minder leidlich, als Proof-of-Concept war es soweit ok, hätte ich Zugriff auf Außenantennen gehabt, wäre es sicherlich cooler gewesen. Im Endeffekt will man je Anbieter 2 Funkmodule haben, eins LTE (alle Bänder), eins HSPA+ (alle Bänder), und dann … braucht man noch eine gute Lösung, die Bandbreite zu kombinieren.

Für mich als Einzelnutzer war das »wie« egal, ich hatte halt Verbindung über das, was es gerade gibt: D1 GSM, D2 EDGE, o2 HSPA+ — OLSR ist es egal, wie schnell die Verbindung ist, alles, was zählt, ist die Funktion gemessen in der Fehlerfreiheit. Insofern weiß ich nicht, wie der neue Partner icomera AB dies löst; der Durchsatz allerdings war duchgehend »knapp akzeptabel«, aber es gab auch Zeiten, in denen es mit IP eher mau war. Im Sekundentakt sich ändernde Verbindungsqualitäten zu bündeln halte ich technisch für schwierig und wenig sinnvoll, insofern würde ich davon ausgehen, daß entweder für 1. und 2. Klasse unterschiedliche Präferenznetze gewählt werden oder aber schlicht, ähnlich wie bei meinem Experiment, nur das jeweils verlustfreieste Netz genommen wird und die mehreren Anbieter »nur« zur Abdeckung von Netzlücken verwendet werden.

Jedenfalls verwendet icomera augenscheinlich irgendwelche Tunneltechniken, was einerseits sich beim kurzen Weg durch’s Netz zeigt, andererseits auch in der auf 1350 Bytes reduzierten MTU¹ der Funkschnittstelle, 150 Bytes weniger als normal.

Kurzum: die neue WLAN-Lösung scheint prinzipiell zu funktionieren, ob sie dem Ansturm eines ganzen ICEs standhalten kann, wird erst die Zukunft zeigen. Ich hatte, als das Telekom_ICE-WLAN noch nur testweise vorhanden war, deutlich höhere Durchsätze als jetzt mit WIFIonICE; damals war ich aber wahrscheinlich, zumal morgens zwischen 6:30 und 9:00 auf der Strecke Güterloh-Berlin, ziemlich alleine unterwegs in den virtuellen Weiten.

Am Dienstag fuhr ich gegen 9:30 los, daß es WLAN im ICE gibt ist bekannt und WIFIonICE stand auch in der 2. Klasse kostenlos zur Verfügung — für das Telekom-WLAN mußte man in der 2. Klasse entweder zahlen oder einen Telekom-Hotspot-Tarif haben.

Aber: Netz hinzaubern, wo außen keine Anbindung besteht, kann auch icomera nicht. Zwischen Wolfsburg und Berlin habe ich mal die Paketverluste aufzeichnen lassen, es fällt auf, daß schon zum Accesspoint Pakete verloren gingen, aber auch zum Ziel kamen nicht alle Pakete durch. Das deckt sich mit dem »gefühlten« Netz, interaktives arbeiten stockte gelegentlich, da sind sicher IP-Pakete verloren gegangen und neu geschickt worden — was nicht tragisch ist, denn dafür ist TCP ausgelegt.

Jedenfalls nähert sich die Welt meiner Vision aus den 90ern von »IP Everywhere« immer mehr an, selbst in der Bahn oder im Flugzeug kann man heute oftmals »online sein«, und eine gut geplante WLAN-Lösung im Zug ist deutlich besser als mit seinem Handy zu versuchen, online zu gehen. Weiter so ;)

____
¹ Die MTU, »Maximum Transfer Unit«, bestimmt, wie groß ein Datenpaket sein darf, größere Pakete müßten vor der Übertragung auseinandergepflückt, »fragmentiert«, werden und beim Empfänger wieder zusammengefügt. Dies möchte man aus Effizienz- und anderen technischen Gründen gerne vermeiden, daher begrenzt man die Paketgröße möglichst frühzeitig. Aktuelle IP-Netzwerke transportieren normalerweise maximal 1500 Byte große Pakete; wenn man Tunneltechniken einsetzt, zwischen zwei Routern also ein IP-Paket in ein anderes einpackt, es durch ein bestimmtes Netzsegment »tunnelt«, muß die Nutzlast des eingepackten Paketes entsprechend sinken, da man die 1500-Byte-Grenze quasi auf jedem Gerät hat; das Paket kann also nicht größer werden kann.