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.

Screenshot

Netter Zug der Deutschen Bahn; und richtig, so Erfahrungen zu gewinnen.

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.

Screenshot

Captive Portal done wrong :(

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.

Screenshot

Uh-oh. Äh, HTTPS zu hijacken ist nicht klug …

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!

Screenshot

Geil, zum Ab­schluß meiner Pend­ler­tage darf ich noch mal Beta­tester sein ;)

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 …

Screenshot

Lückenlos ist die An­bind­ung im ICE auch mit 3 Mo­bil­funk­netz­en nicht &hmdash; aber das wußte ich ja vorher ;)

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.

Screenshot

Exorbitant ist der Durchsatz nicht (BI-H).

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.
Screenshot

Kurzer Trace — ohne Tunnel geht es ja auch nicht.

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.
Screenshot

MTU-Pro­bleme ge­schickt um­gan­gen: MTU 1350 schon auf dem WLAN-In­ter­face.


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.

Screenshot

Weiterhin Verluste zwischen WOB & B.

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.

One thought on “WIFIonICE, erste Eindrücke

  1. TCP ist halt nicht für Verbindungen ausgelegt, die sich _so_ drastisch unterscheiden wie UMTS im fahrenden Zug. TCP passt sich hervorragend an Leitungen an, die zuverlässig etwa 5 % der pakete wegwerfen, steigert seine Wiederholungen und hält sich freiwillig mit dem Durchsatz zurück.

    Mit einer Leitung, die in einer Sekunde gar nichts, und zehn Sekunden später zehn Megabit mit 35 ms Latenz transportiert, ist TCP leider arg überfordert und kommt nicht schnell genug auf die Beine, dass die Leitung in ihrer “guten” Zeit angemessen ausgenutzt werden könnte. Da ist man schneller wieder im nächsten Funkloch als dass die erste halbe Bildschirmseite ssh-Output transportiert werden konnte.

    Eine VPN-Technik wie OpenVPN dazwischen stegert das Drama noch.

Comments are closed.