In wenigen Wochen geht es zum Bahnfahren in die Schweiz. Ohne mobile
Daten in ernstzunehmender Menge geht das gar nicht. Bisher habe
ich mich stets mit einer Swisscom Natel Easy-Prepaidkarte versorgt,
deren wunderbarer uralter Tarif bei 3 Franken pro Tag für mobile
Datennutzung gedeckelt war. Dummerweise ist diese Karte seit ihrer
letzten Benutzung verstorben, so dass es eine Alternative braucht.
Das ist in der Schweiz gar nicht so einfach; die nach Deutschland
bestellbaren SIMs haben entweder Mindestlaufzeit und Grundgebühr, oder
mobile Daten in homöopathischer Dosis von 50 oder 100 MByte pro Tag.
Das hat mir zugegeben vor zehn Jahren noch gereicht; im Jahr 2017 ist
dieses Kontingent aber morgens schon vor dem Frühstück aufgebraucht.
Einziger, mir ins Gesicht springende Kandidat ist Lycamobile.ch, eine
tatsächlich kostenlose Prepaidkarte, zu der man innerhalb von 30 Tagen
zu verbrauchende 5 Gigabyte für 13 Stutz 90 hinzukaufen kann. Das ist so günstig, dass ich bezweifle, dass das Angebot ernst gemeint ist. Also eine Mail mit ein paar harmlosen Fragen ("Entstehen Zusatzkosten, kann man die Karte per Post nach Deutschland bestellen, kann man eine in der Schweiz gekaufte Karte als Kunde aus Deutschland ohne Schweizer Adresse freischalten") hingeschickt und zwei Wochen gewartet.
Steinar H. Gunderson, sesse, has written an interesting article about TCP performance. I didn't find your blog's comment function, so I am commenting with a trackback. (note: which didn't work either, "The auto-discovered trackback URI does not match our target URI")
I frequently use mobile internet, using various of the German GSM/UMTS network operators, out of a moving train. As you have written, this frequently causes packet loss which is not only not caused by congestion, but sends the congestion avoidance algorithms on a false path.
For example, when the train passes through the 3575 m long Distelrasentunnel between Frankfurt and Fulda, my network link is broken for like two minutes. Passing through other parts of Germany sometimes gives me a ping response of hundreds of thousands of microseconds by virtue of the rather huge send buffer the UMTS equipment has.
In these circumstances, ssh sessions frequently take tens of minutes to notice that the network is back before the session is useable again. Frequently, it doesn't come up again before an hour has passed. And I have not found a way to work myself around this. Can you explain what's happening here, and do you have any ideas to solve the issue?
Das Schicksal des Usenet-Teilnehmers hat einen T-Mobile Web'n'Walk-Stick (das schwarze Modell) in der nicht gesimlockten Version in meine Hände gespült. Auf sowas war ich ja immer schon scharf, weil ich mir von dem per USB angebundenen Gerät einen etwas stabileren Betrieb erhofft hatte als von meiner jetzt doch schon etwas älteren, nicht HSDPA-fähigen PCMCIA-Karte gewohnt bin. Aber das Ding unter Linux zum Laufen zu bringen war dann doch nicht so einfach wie gedacht.
Beim magentafarbenen UMTS/GPRS-Internet lautet der korrekte String für den APN "internet.t-mobile" und nicht "internet.t-mobile.de".
Trägt man den falschen APN ein, landet man in einem Netz, aus dem man surfen kann, aber sonst nichts: Außer TCP/80 und TCP/443 habe ich nichts gesehen was funktioniert hätte. Ich war schon ziemlich stinkig, wie Vendor T es wagen kann, sowas kastriertes als Internetzugang zu verkaufen, aber nach Korrektur des APN tat es dann auch mit OpenVPN, ssh und nntp.
$ ping 10.8.0.11
PING 10.8.0.11 (10.8.0.11) 56(84) bytes of data.
64 bytes from 10.8.0.11: icmp_seq=1 ttl=63 time=79.6 ms
64 bytes from 10.8.0.11: icmp_seq=2 ttl=63 time=79.5 ms
64 bytes from 10.8.0.11: icmp_seq=3 ttl=63 time=79.7 ms
<ethernetkabel wird gezogen>
64 bytes from 10.8.0.11: icmp_seq=295 ttl=63 time=724 ms
64 bytes from 10.8.0.11: icmp_seq=296 ttl=63 time=1079 ms
64 bytes from 10.8.0.11: icmp_seq=297 ttl=63 time=559 ms
Dies ist das Verhalten meines Netzüberwachungs-Notebooks auf dem zum Management dienenden OpenVPN-Link beim Ziehen des Ethernetkabels. Auf dem Ding läuft eh ein Nagios und es hat zum Verschicken von Warn-SMS aus dem Nagios eine UMTS-Karte. Also habe ich ihm jetzt per Event Handler beigebracht, automatisch einen pppd zu starten, wenn die Gegenstelle des OpenVPN-Tunnels ihren Status nach DOWN wechselt. Und das funktioniert sogar.
Die hohen RTTs nach dem Ziehen des Ethernetkabels kommen übrigens daher, dass in der UMTS-Karte derzeit eine uralte Simyo-SIM steckt, die noch nicht UMTS-fähig ist. Aber die ist bald leer, und dann kommt da auch eine USIM rein.
Today, I had the opportunity to try my UMTS initialization mechanism that I built this weekend with more recent hardware, a newer Option Globetrotter 3G Express Card with Vodafone branding (reporting itself to be a "Globetrotter HSDPA Modem" with Vendor ID 0xaf0 and Product ID 0x6701). To get the card connected to my test Notebook, a hp compaq nc8000, I had a "Expresscard in a PC card slot" adapter and a passive "Expresscard at a normal USB port" adapter. The USB adapter had cost about ten Euros, and I don't imagine the PC card adapter to be much more expensive.
For mobile UMTS/GSM, I have been using an Option 3G Data Card for two and a half years now. I blogged about getting the card to work (in German, sorry) on Linux in July 2005. I never found the time - until now - to automate the card initialization so that I had been using a horrible chat script for card initialization when the PPP connection was built.
I recently took the time to automate this, so that the PIN is transmitted to the card automatically when the card is plugged in. This article documents what I did.
On a side note: Unfortunately, the vendors' attitude towards Linux hasn't changed since 2005. Their Hotlines still deny that their products can be used with Linux at all, and they surely do not publish any documentation that can be of help. Otoh, Vodafone has published a software that supposedly aids usage of their products under Linux. I haven't tried it yet since it is not packaged yet for Debian. Additionally, Vodafone support media and sales do not seem to know about this effort, they still deny that their products work with Linux. Windows users happily install proprietary software products that do little more than sending a handful of AT commands to the emulated USB modem and hand over the connection to Windows' PPP Stack. A very unsatisfying situation.
Just for the record: Dear Vodafone DE, a week ago you missed the sale of a new USB UMTS interface because you don't even document it on Linux. This motivated me to look into the drawer that holds the old, non-HSDPA PC cards that have been decommissioned at the customers' site and use an old, used device. Your fault.
Vodafone-Websessions sind ein hübsches, innovatives Produkt für den mobilen Internetzugang für Wenignutzer. Und leider überhaupt nicht zu empfehlen, wenn man "nur" eine Provider-SIM hat.
Last thursday and friday, I spent around eleven hours in the InterCity Express (ICE) of Deutsche Bahn. I was online, using Simyo GPRS, during this entire time. Thanks to the cellular network repeaters in ICE's coach 3 and 23, this has worked reasonably well and has cost me EUR 5,27 - in a tariff with no basic charge and no commitment.
Heute habe ich das erste Mal versucht, UMTS im Handywagen eines Redesign-ICE1 zu benutzen.
Mit Betonung auf "versucht". Der Repeater scheint nur GSM zu verstärken, es war die ganze Zeit nix außer GPRS zu kriegen. Mit den bekannten Wackellatenzen zwischen 800 und 1200 ms mit minutenlangen Aussetzern. Zum interaktiven Arbeiten völlig unbrauchbar.
Heute hatte ich nach der Erfolgsmeldung des prinzipiellen Funktionierens das erste Mal die Gelegenheit, UMTS in der Praxis auszuprobieren, und zwar gleich unter erschwerten Bedingungen: Testort ist der IC von Weinheim an der Bergstraße nach Hamburg. Das ist vor allen Dingen deswegen "erschwert", weil es im IC keine Repeater in den Wagen gibt.
