Zugschlusbeobachtungen (Entries tagged as umts)

TCP and mobile IP

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 04 Sep 2009 16:00:11 +0200

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 war gar nicht HSO einfach

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 23 Oct 2008 23:29:43 +0200

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.

Unter dem schwarzen Gehäuse verbirgt sich ein Option Icon 225, der leider ein wenig zu groß ist, um direkt auf einen der beiden etwas versenkt angebrachten USB-Ports meines Notebooks aufgesteckt zu werden. Dafür ist ein Clip für die Befestigung am Displaydeckel und ein etwa 20 cm langes USB-Kabel enthalten, das mir ermöglicht, den Stick dort festzuklemmen, wo ich vorher die externe Antenne der PCMCIA-Karte angeklemmt habe, wenn die funktechnische Umgebung für die Benutzung der eingebauten Antenne der PCMCIA-Karte nicht ausreichte - also besonders im Zug und in Frankfurter Bürogebäuden.

Eigentlich hätte ich erwartet, dass sich auch dieses Gerät wie die früheren UMTS-Dingens als per USB angebundenes serielles Modem zeigt, das man mit AT-Befehlen steuert und dann PPP spricht. Ganz so ist es eher nicht. Vorher schon hatte ich gewusst, dass die neueren Dinger die Installation unter Windows einfacher machen dadurch, dass sie sich als USB-CDROM zeigen, von dem die Treiber installiert werden können. Unter Linux ist sowas ja eher hinderlich, weil die benötigten Treiber ja eh nicht auf der “CD” drauf sind. Nun denn.

Für den Option-Stick gibt es einen Linux-Treiber namens HSO, der seltsamerweise über ein Webforum veröffentlicht wird. Da er noch nicht für Debian paketiert ist, freue ich mich darüber, dass ich in den Release-Notes für Kernel 2.6.27 lese, dass der HSO-Treiber jetzt im Mainline-Kernel enthalten ist. An anderer Stelle lerne ich sogar, dass die Entwicklung des HSO-Treibers von Option offiziell unterstützt wird - schön, dass wieder ein Hersteller das Licht gesehen hat.

Für den Wechsel von 2.6.26 auf 2.6.27 geht wieder der übliche Kampf mit den kommerziellen Modul-Lieferanten los, den ich endlich für den Wechsel von VMware zu Virtualbox OSE nutze - die schleppende Unterstützung neuer Kernel-Releases von VMware geht mir schon seit Jahren auf den Zeiger, und vmware-any-any wird in den letzten Monaten auch eher schlecht als recht gepflegt. Aber darüber blogge ich in einem anderen Artikel.

Nachdem auf meinem Notebook endlich die Voraussetzungen für die Installation von Linux 2.6.27 geschaffen sind (meine virtuellen Maschinen sind mir wichtiger als UMTS), gehen die Experimente mit dem neuen UMTS-Stick los. Ich lerne, dass man den Stick mit einem Userspace-Programm vom CD-ROM-Modus in den Modus für die eigentliche Benutzung umschalten muss, versuche mich ein paarmal mit dem überall empfohlenen rezero (was mir nicht nur einen Komplettabsturz des Notebooks beschert) und lande schließlich beim neueren ozerocdoff, das zusammen mit dem im Tarball enthaltenen 51-hso-udev.rules (was aufgrund seiner Unterstützung für eine lange Liste von Devices und allen möglichen udev-Versionen zu lang zum hier reinpasten ist) dafür sorgt, dass der Stick nach dem Einstecken automatisch in den richtigen Modus gelangt und man neben den drei erwarteten seriellen Devices auch ein weiteres Netzinterface hso0 im System sieht.

wtf? Ein Netzwerkinterface? Nun, das wird man doch sicher links liegen lassen können. Also schnell die PPP-Konfiguration an den neuen Interfacenamen angepasst und “pon umts-icon”. Was passiert? Nichts. der Verbindungeaufbau bleibt dort stehen, wo die PPP-Verhandlung beginnt. Alle drei seriellen Geräte durchprobiert, nichts. Also doch mal die Doku lesen.

Naja, die Doku ist zwiespaltig und besteht hauptsächlich aus Einträgen in Webforen von webforumsüblicher Qualität. Die Hilfe kommt mal wieder aus dem Pharscape-Forum, wo ein Anonymous seine Scripts veröffentlicht hat. Das ist zwar eine üble Kombination aus Chat- und Shellscripts, aber immerhin sieht man, wie der Icon bedient werden will: Die seriellen Devices dienen der Konfiguration des Sticks mit Hilfe von AT-Befehlen, der Datentransfer geht über das Netzinterface. Man konfiguriert den Stick wie die alten Karten, gibt ihm dann mit einem neuen Befehl die Anweisung zum Verbindungsaufbau, liest dann mit einem weiteren Befehl die Verbindungsparameter (hauptsächlich IP-Adresse und DNS-Server) aus und setzt sie dann mit ifconfig auf das Netzwerkinterface und los geht’s. Das ganze wird über /etc/network/interfaces so bedient, dass ein ifup hso0 die Verbindung aufbaut und ifdown hso0 die Verbindung wieder abbaut. Ein bisschen Überlegung erklärt auch, warum diese Perversion der Implementierung gewählt wurde: Bis zu 7.2 Mbit/s über eine (virtuelle) serielle Schnittstelle zu übertragen hat man sich dann wohl doch nicht mehr getraut.

Da ich chat(1) abgrundtief hasse und die Shellscripts aus dem Pharscape-Forum außerdem manche Debian-Mechanismen (allen voran resolvconf) ignorieren, entschließe ich mich, das ganze in Perl neuzuschreiben, unter Verwendung des Device::Modem-Moduls. Men Script findet Ihr hier - entgegen meiner sonstigen Gewohnheit nicht mit -T laufend, da Device::Modem im Tainted-Modus nur auf die Schnauze fliegt. Die Konfigurationsdatei sieht so aus:

<umts>
        provider vodafone-websessions
        controldevice /dev/wctrl0
        <default>
                pin xyzw
        </default>
        <simyo>
                apn internet.eplus.de
        </simyo>
        <vodafone-websessions>
                apn event.vodafone.de
        </vodafone-websessions>
</umts>

Zusammen noch mit dem /e/n/i-Eintrag

iface hso0 inet manual
        pre-up /usr/local/stow/hso/share/hso/hso-script
        post-up /usr/local/stow/hso/share/hso/hso-script
        pre-down /usr/local/stow/hso/share/hso/hso-script
        post-down /usr/local/stow/hso/share/hso/hso-script

kann die Verbindung dann manuell oder mit einem “allow-hotplug hso0” schon beim Einstecken des Sticks automatisch aufgebaut werden.

Kurz ausprobiert, geht. Ein bisschen gepingt, geht.

Am nächsten Tag im Zug dann die unangenehme Überraschung: Die Verbindung hält nur wenige Minuten und bleibt dann stehen. Im Log steht dann was von USB-Reset und einem fehlenden Callback im Treiber und “Tx timeout”. Das war’s dann bis zum Ausstöpseln des Sticks.

Kurzes Betrachten des Kernel-Quellcodes zeigt, dass im Kernel 2.6.27 hso.c 1.2 enthalten ist. Das Pharscape-Forum ist aber schon bei 1.6. Daniel Baumann, der inzwischen den HSO-Treiber für Debian paketieren möchte, ist noch bie 1.3 und sagt auch, dass er lieber bei den offiziell bei Option veröffentlichten Treibern bleiben würde. So im Regen stehend, suche ich nach einer anderen Lösung und kopiere schließlich das hso.c von Pharscape kurzerhand in meinen 2.6.27-Kernel-Tree und baue neu. Glücklicherweise ist der Treiber stabil genug, dass diese Kombination prima baut und auch läuft. Und sogar stabil.

Auf der Rückfahrt aus Hannover bin ich (online mit einer Vodafone Websession) ganz begeistert: Der neue Stick funkt trotz kleinerer Antenne auch im ICE ganz prima, bucht sich stabil und schnell zwischen UMTS und GPRS hin und her und selbst nach der Durchfahrt durch den Distelrasentunnel bei Schlüchtern kommt die Verbindung sauber wieder auf die Beine. Hier war sonst mit der alten PCMCIA-Karte verlässlich ein Neuaufbau der Verbindung fällig. Auch die sporadischen Hänger des Interfaces, bei denen sich die Karte auf den seriellen Devices tot stellt und nur durch ziehen und wieder einstecken wiederzubeleben ist, treten mit dem USB-Stick nicht auf. Entweder funkt der Icon 225 massivst besser als die alte Option Datacard 3G, oder ich hab nur einen ICE mit einem außerordentlich gut funktionierenden Repeater in Wagen 3 erwischt. Auf der knapp dreistündigen Fahrt habe ich nur einen Hänger, der das Ziehen der USB-Verbindung notwendig macht. Das ist eine bessere Bilanz als ich sie mit der alten PCMCIA-Karte je gehabt habe. Auf der nächsten Fahrt nach Berlin nächste Woche werde ich es mal mit der halb so teuren Tagesflatrate von Fonic probieren, die mit der alten PCMCIA-Karte im Zug reproduzierbar mehr Auszeiten als nutzbare Zeit produziert. Wir werden sehen.

internet.t-mobile ist nicht internet.t-mobile.de

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 13 Oct 2008 12:24:12 +0200

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.

Automatisierter UMTS-Fallback mit Nagios

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 21 Jul 2008 08:35:14 +0200

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

Works with a more recent card as well

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 03 Jun 2008 17:16:17 +0200

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.

The later Option card is recognized as three USB-connected serial ports by the Option kernel driver (CONFIG_USB_SERIAL_OPTION) as the older one is, and it works just fine. The only difference is that the udev rule needs a different value for the ATTRS{modalias} setting. My umts-pin script complains about an “illegal seek” after entering the PIN, but the card registers itself with the network nevertheless. Both gammu to send SMS and pppd for IP connectivity worked out of the box.

Especially the “Expresscard-to-USB” adapter setup is very sexy for setups where neither an Expresscard nor a PC Card slot is available, and USB cables can be nice and long. So one could even mount the UMTS interface near the window and pull a longer USB cable to the actual system. I decided on putting the UMTS interface into a notebook, though, and mount the notebook near the window to be able to monitor the monitoring systems and send out SMS even when the whole datacenter is without power (by virtue of the notebook having a built-in UPS).

Automatic initialization of a Option 3G Datacard

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 01 Jun 2008 11:17:00 +0200

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.

But now back on topic: For a data center monitoring system, I want to send out alerts as text message (for German speakers: SMS - we have a rather strange vocabulary for mobile communications), and am reluctant to do so via IP: IP is one of the things that can fail, so it is preferred to directly inject the text messages into the network of the operator that provides service to the recipients of the text messages. Fortunately, most of the recipients are in the same network.

After evaluating current hardware solutions that could be plugged directly into the “real” server doing the monitoring and running into the wall of non-support provided by the network operators and hardware vendors, I decided on taking things a little further and to build an Ethernet-Connected text message device. An old hp compaq nc8000 (no, not mine, mine still works fine and is in daily use) and an old, first generation Option Datacard 3G will be mounted near the datacenter’s windows and equipped with Debian and Nagios. That way, the text message device can itself monitor the monitoring system and even send out a warning message when the data center goes out of power: It has a built-in UPS.

But now back on topic: For the text messages to go out reliably, it is necessary that the UMTS card is initialized automatically when the system comes up. A great opportunity to finally address this issue for Linux, on customers’ expense **grins**.

UMTS card initialization is done in two steps: First, when the card is plugged in, the virtual OHCI host port appears. Initialization of the virtual OHCI happens automatically. Most documentation on the web says that you now need to load an appropriately parametrized usbserial module, and I did it this way for years, but that’s not necessary any more. CONFIG_USB_SERIAL_OPTION is a dedicated kernel module for the Option 3G data card, which gets automatically loaded if it is available.

If you don’t have the Option module for some reason, you still need the following udev rule to automatically load the generic USB serial module. I figured that out yesterday before I learned about the Option module in a comment made to the original version of this article.

SUBSYSTEM==“usb”, \
   SYSFS{idProduct}==“5000”, SYSFS{idVendor}==“0af0”, \
   ACTION==“add”, \
   RUN+=“/sbin/modprobe usbserial vendor=0x$attr{idVendor} product=0x$attr{idProduct}”

SUBSYSTEM==“usb”, \
   SYSFS{idProduct}==“5000”, SYSFS{idVendor}==“0af0”, \
   ACTION==“remove”, \
   RUN+=“/sbin/modprobe -r usbserial”

Unfortunately, the usbserial and option modules stay around after the card is pulled. This doesn’t hurt though.

Next, we see three virtual serial interfaces, which we can detect via udev, and assign “speaking” device names and transmit the PIN. This goes into /etc/udev/rules.d/50-option3g.rules:

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“option”, \
   ATTRS{bInterfaceNumber}==“00”, \
   ATTRS{modalias}==“usb:v0AF0p5000d0000dc00dsc00dp00icFFiscFFipFF”, \
   SYMLINK=“UMTS-DATA”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“option”, \
   ATTRS{bInterfaceNumber}==“02”, \
   ATTRS{modalias}==“usb:v0AF0p5000d0000dc00dsc00dp00icFFiscFFipFF”, \
   RUN+=“/usr/local/sbin/umts-pin --device %k --symlink UMTS-CONTROL”

I am not sure what the modalias attribute identifies, but it looks like it identifies the hardware model: An identical Option Datacard 3G, plugged into the other PC Card Slot gets properly initialized as well.

These two udev stanzas do two different things: First, they make sure that the new devices are symlinked to /dev/UMTS-DATA and /dev/UMTS-CONTROL, suggesting the intended use of the interface. The second virtual interface of the 3G Data Card does not seem to be useable at all, and you cannot build an actual data connection over the third. So, we baptize the first interface /dev/UMTS-DATA and ignore the second. The third gets called /dev/UMTS-CONTROL.

Now to the real magic: /usr/local/sbin/umts-pin is a perl script that sends the PIN to the Card. %k gets expanded to the device name of the device that has just been detected, so umts-pin gets called with “--device ttyUSB2”. Please note that this udev stanza does not have a SYMLINK clause, but instead umts-pin creates the symlink after sending the PIN to keep other processes from trying to grab the device before it was properly initialized.

It makes use of Cosimo Streppone’s Device::Modem module (Device::Gsm is not yet packaged for Debian and might be of better use here) to talk to the UMTS device. Unfortunately, I have not yet fully understood the logging and answer processing features of Device::Modem, so the implementation might look a little clumsy. I hope that it can be clearly understood anyway.

The actual PIN is read from a configuration file in an apache-like format, which is by default looked for in /etc/umts/pin.conf:

<pin>
        <default>
                pin xyzw
        </default>
</pin>

The reason I settled for this rather complex configuration file format is that the ultimate goal is to automatically detect which of my SIMs is currently inserted in the UMTS card and to automatically send the correct PIN. I haven’t been successful in doing so since I didn’t find an AT command yet to get the UMTS card to divulge the SIM serial number or the IMSI before the PIN is transmitted to the SIM. So currently, the only things that are supported are the “default” stanza and an identically formatted “override” stanza which takes precedence over the default stanza if present.

If the first attempt to send the PIN fails, the script tries again ten seconds later. On my test system, this happens about once in twenty times. That must be some weird timing issue. So, if you have the wrong PIN configured, you’ll need the PUK after plugging in the card for the second time, since the first try will eat two of your three attempts. Beware.

If you feel uncomfortable with all this scripting and the “quality” of my code, you can also use gammu’s entersecuritycode function. I discovered this after my PIN script was already written, and gammu currently forces you to expose the PIN on the command line (see #484102), and of course my script’s PIN handling is vastly superior **grins**.

Preise fuer Vodafone Websessions koennen abweichen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 17 Mar 2008 13:00:00 +0100

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.

Wer dieses Blog liest oder mich kennt weiß, dass ich den mobilen Internetzugang der Mobilfunkanbieter verhältnismäßig selten, dafür aber intensiv nutze. Dazu verwende ich üblicherweise E-Plus über einen der beiden Discounter Blau oder Simyo zum Volumentarif von 24 Cent pro Megabyte.

Dieser Zugang hat leider den Nachteil, dass er genau dann, wenn man ihn dringend benötigt, nicht funktioniert. Das UMTS ist besonders in den Ballungsgebieten (beispielsweise in Frankfurt) schlecht ausgebaut, und meine typische Anwendung, ssh, ist per GPRS besonders dann eine Zumutung, wenn auf der Verbindung außer der ssh-Session noch andere Dinge laufen.

Also braucht es einen Fallback-Zugang für den Fall, dass E Plus UMTS nicht in der gerade benötigten Qualität zur Verfügung steht. Alternativ - für Nochwenigernutzung - habe ich bisher immer die Klarmobil-D1-Karte aus dem Telefon in die UMTS-Karte eingelegt und den - zwar nicht günstigen, aber auch nicht prohibitiv teuren - Zeittarif von 9 Cent pro Minute verwendet. Inzwischen steht auch eine O2-Karte zur Verfügung, die im Default auch neun Cent pro Minute kostet, für die man aber mit relativ kurzer Laufzeit versehene Volumenpacks von 200 MB oder 5 GB dazu kaufen kann. Aber ich schweife ab.

Irgendwann letztes Jahr haben sich findige Strategen bei Vodafone das Produkt Websessions einfallen lassen. Hierzu braucht man nur eine beliebige SIM, die einen ins Vodafone-Netz bringt, und nach Eintragung des APN event.vodafone.de verhält sich das Ding wie ein (kostenpflichtiger) WLAN-Hotspot: Der Browser wird beim ersten Aufruf einer Webseite auf eine Anmeldewebseite umgeleitet, und man kann sich entscheiden, wie lang die Websession dauern soll und wie man zu bezahlen gedenkt. Die “kurzen” Laufzeiten bewegen sich in der Größenordnung der feingranularer abgerechneten Minutentarife von Klarmobil und O2, interessant ist einzig die 24-Stunden-Websession, die ursprünglich EUR 14,95 gekostet hat, inzwischen auf 4,95 verbilligt wurde und die ab 30. April 7,95 kosten soll.

Als Bezahloptionen steht überall, dass man per Kreditkarte, über die SIM oder über die Rechnung einer anderen Vodafone-SIM bezahlen kann. Im letzten Fall bekommt man an die zu dieser SIM gehörende Rufnummer ein Passwort geSMSsed, mit dem man die Websession starten kann; bei Bezahlung über die benutzte SIM taucht die Websession entweder im Falle einer Vertragskarte auf der Rechnung auf oder wird vom Prepaid-Guthaben abgebucht. Das ganze basiert auf einem Parkuhr-Prinzip: Eine um 14.18 Uhr gestartete Zwei-Stunden-Websession endet um 16.18 Uhr, auch wenn man sich sofort wieder ausgelogged hat. Beliebig viele Verbindungsaufbauten und -abbauten sind erlaubt; so lange eine Websession noch läuft, verhält sich das System so als würde ein “normaler” GPRS/UMTS-Zugang benutzt.

Dieses Produkt ausprobieren wollend, habe ich mir eine CallYa-Karte bei Ebay geschossen (1 Euro bezahlt, fünf Euro Startguthaben bekommen) und leider nicht darauf geachtet, ob es eine Vodafone- oder eine Providerkarte ist. So bin ich dann schließlich bei einer Debitel-CallYa-Karte für das Vodafone-Netz gelandet, die zwar dem Grunde nach funktioniert, aber im Zusammenhang mit den Websessions den einen oder anderen Nachteil hat. Zum Telefonieren oder gar mit dem zur Karte gehörenden Datentarif online gehen taugt die Karte eh nicht, die Tarife sind unterirdisch schlecht. Da hat Debitel echt den Schuss nicht gehört.

Im Zusammenhang mit Vodafone Websessions fehlt dieser Karte vor allen Dingen die Bezahloption per Kreditkarte. In Ermangelung einer anderen Vodafone-SIM musste ich mich zur Online-Aufladung der Karte beim Bezahldienst Luupay anmelden, weil Debitel kein eigenes Webfrontend für die Bedienung dieser Karte hat. Benutzt habe ich im Dezember einmal eine Zwei-Stunden-Websession aus dem Zug, weil E Plus mal wieder übellaunig war und ich eh mal ausprobieren wollte, wie Vodafone funktioniert.

Im Februar 2008 hat Vodafone dann den Preis für die 24-Stunden-Websession temporär auf 4,95 gesenkt, was für mich endgültig der Auslöser war, es auf einem eintägigen Businesstrip nach Hannover Ende Februar gar nicht erst mit dem Blau-Volumentarif zu versuchen, sondern gleich nach Ausfahrt aus Mannheim Hbf eine 24-Stunden-Websession zu buchen. Ich achtete darauf: Auf der Anmeldewebseite stand der Preis von 4,95. Während dieser 24 Stunden war die Connectivity von Vodafone - im ICE, im Hannoveraner Hotel und auch beim Kunden im Besprechungsraum - ohne Tadel.

Das böse Erwachen kam dann vor zehn Tagen, als ich beim Debugging einer Telefonstörung ausprobieren wollte, ob eine bestimmte Rufnummer aus dem Netz von Vodafone erreichbar wäre und meine Debitel-SIM in ein Telefon gesteckt habe. Da schallte mir gleich der Hinweis entgegen, dass meine Prepaid-Karte nur nur 38 Cent Guthaben hat und dass ich doch bitte aufladen möchte. Das kann ja nun gar nicht sein, denn zu den 5 Euro Startguthaben hatte ich 15 Euro per luupay aufgeladen, 5 Euro hab ich im letzten Jahr für die zwei-Stunden-Websession verbraten. Ich habe den Verdacht, dass Debitel den “alten” Preis für die 24-Stunden-Websession, also zehn Euro mehr als auf der Anmeldewebseite angekündigt, abgebucht hat.

Leider bleibt das Phänomen ungeklärt, denn es kommt so wie erwartet: Debitel bietet kein Webinterface für die Bedienung der Prepaid-Karte an und hat somit nicht nur ein preislich völlig unattraktives Produkt, sondern auch noch eins, dessen Leistungsmerkmale auf dem Niveau von vor zehn Jahren liegen. Das kann heute jeder Discounter besser, pfui. Aber auch die 0900-Hotline (die mit 41 Cent pro Minute aus dem Festnetz sogar bezahlbar, aber von meinem Nicht-Telekom-Festnetzanschluß nicht erreichbar ist, so dass ich bei Optik am Schloss gegen zwei Euro in die Kaffeekasse telefonieren muss) kann mir hier nicht helfen: Man kann mir zwar sagen, dass für die Karte kein Jamba-Abo besteht und dass auch keine debitel-eigenen Dienste genutzt wurden, aber wo das Guthaben hin ist, kann man mir nicht verraten. Ich solle mich doch deswegen an Vodafone wenden. Auch an der (immerhin gebührenfreien) Vodafone-Hotline pralle ich ab, denn dort kann man natürlich auf die Buchungsdaten der Debitel-SIM erst recht nicht zugreifen. Und für Websessions gibt es grundsätzlich mal gar keinen Support. Nach den beiden Hotline-Erlebnissen zahle ich lieber zwei Euro für keine Hilfe, als dass ich mich erstmal gestoppte acht (und gefühlte dreißig) Minuten durch ein schlecht gemachtes Voicemenü stammle, bevor man mir dort auch nicht weiterhilft.

Ich entschließe mich, Debitel die zehn Euro 38 zu schenken, die Debitel-Callya-SIM ungenutzt in die Ecke zu werfen und spreche eine starke Warnung vor “klassischen” Provider-Prepaid-Karten aus: Es gibt keine Kostenkontrolle; die Anbieter können im Prinzip abbuchen was sie wollen weil sie ihren Kunden eh nicht Rede und Antwort darüber stehen was sie vom Guthaben abziehen und bei Unklarheiten wird mit den Schultern gezuckt und mit dem Finger auf jemand anderen gezeigt. Die Tarife kann man eh komplett vergessen, und die Produkte mit den zeitgemäßeren Leistungsmerkmalen (z.B. Aufladung per Webseite, Einzelverbindungsnachweis trotz Prepaid etc) gibt es sowieso bei den Discountern.

Die nächste Websession wird nun mit einer Original Vodafone Callya-Karte (1 Euro bei Ebay, 10 Euro Startguthaben) abgewickelt. Da gibt es in der Websessions-Anmeldeseite die bei Debitel vermisste Option der Bezahlung über Kreditkarte, und im Falle einer weiteren Abrechnungs-Unstimmigkeit hat man wenigstens nur eine Firma, mit der man sich auseinandersetzen muss und das Fingerzeigen auf den anderen dürfte dem Hotlineagenten deutlich schwerer fallen.

Mobile Internet is affordable in Germany

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 04 Aug 2007 22:02:28 +0200

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.

I really like that, because this usage of the mobile cellular network would have cost about fifty times more just a year ago. Thanks, Simyo, E Plus and the other E Plus resellers who have made the first step to reducing the cost of mobile Internet in Germany.

A few technical notes:

The repeaters in the ICE coaches do only repeat GSM and thus GPRS, but not UMTS. It is advised to lock the UMTS card to GPRS when using Internet from inside the ICE, since the card will otherwise move back and forth between UMTS and GPRS millions of times, which will always result in more than just a few seconds outage. It is much better to live with GPRS’ abysmally large latency.
I took the opportunity to empty my still-active, old, GPRS only, Simyo SIM which still holds like fifteen Euros. I suspect that I’ll need two more trips of this magnitude to successfully get rid of the amount on that prepaid card.
I need an external antenna for my UMTS card - it worked really really bad in my mom’s apartment right in the middle of Hamburg.
There seem to be a number of independent issues in Debian sid (the reason why I am blogging this in English): The connection occasionally hangs (a couple of times an hour) and does not come back by itself. Often, poff/pon is enough, but sometimes it is necessary to pull the UMTS card (an Option 3G PC-Card Datacard) and to re-insert it since there was no answer any more on ttyUSB0. Very annoying.
The Option 3G Datacard behaves differently depending on the SIM that is inserted. With my older, GPRS-only Simyo SIM, the response to AT+CPIN? is “SIM PUK2” after sending the PIN to the card, while it is “SIM PIN2” in the same situation with the newer UMTS-enabled Simyo SIM.
chat(8) sucks badly, because it doesn’t seem to elegantly handle this case - no regexps, no if/then, every command sent needs to generate exactly one answer from the card, everything else is an error after timeout.
When I do this more often, one of the now available flat rates (or, for starters, a 5 GB commitment tariff) for like 20 Euros becomes attractive.

UMTS im ICE

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 11 Aug 2006 00:30:25 +0200

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.

UMTS unter Linux in der mobilen Praxis

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 15 Oct 2005 00:55:54 +0200

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.

Testumgebung ist wie gehabt mein hp compaq nc8000 mit der von Vodafone gebrandeten Option-Karte. Die Karte ist auf “UMTS bevorzugen, GPRS als Rückfallebene” konfiguriert; Softwareumgebung ist Debian GNU/Linux Unstable mit Kernel 2.6.14-rc1, statischem /dev und dem derzeit bekanntermaßen kaputten hotplug. Als PPP-Daemon verwende ich den “Normalen” pppd, der mir auch bei PPPoE und Modem Dienste leistet.

Die Testumgebung gibt das automatische Laden des usbserial-Kernelmoduls nicht her, so dass nach dem Einstecken des Karte erstmal auf der Shell ein modprobe-Aufruf fällig wird.

Im Chatscript muss man der Karte drei Parameter mitgeben. Dabei zeigt sich schon die erste Herausforderung: Die Karte beginnt erst nach Übermittlung der PIN damit, sich in das Mobilfunknetz einzubuchen, gibt aber sofort nach dem Kommando das “OK” und beginnt auch nach dem ATDT-Kommando sofort mit dem PPP-Handshake. Das wiederum führt dazu, dass der Einbuchungsvorgang beim Funknetz noch nicht abgeschlossen ist, während am anderen Ende der Karte der LCP-Handshake austimed und der pppd beleidigt terminiert. Beim zweiten Mal bekommt man dann bei Übermittlung der PIN einen ERROR, muss also das Chatscript so anpassen, dass es an dieser Stelle auch einen ERROR als “korrekte Rückmeldung” verbucht. Eventuell ist es sinnvoller, direkt nach dem Laden von usbserial die Konfiguration der Karte per Extra-Chatscript vorzunehmen, und den pppd erst dann aufzurufen, wenn die Karte sich korrekt eingebucht hat.

Nachdem diese erste Hürde genommen ist, zeigt sich, dass die UMTS-Verbindung schon dann ins Stocken gerät, wenn der IC die geschlossene Ortschaft für länger als 30 Sekunden verlässt. Glücklicherweise ist in Rhein/Main die nächste Zelle nie weit, und die Session überlebt das Wiedereinbuchen inklusive der bestehenden TCP-Verbindungen problemlos.

Die Latenz liegt üblicherweise unter 300 ms, wobei einzelne Pakete auch mal zwei Sekunden unterwegs sind. In Gebieten mit Aussetzern bemerkt man bei einem mitlaufenden Dauerping die durchaus ausgeprägte Pufferung auf der Karte - wenn das Netz wiederkommt sind pings mit 200000 ms Laufzeit durchaus normal. ssh mag sowas gar nicht und nimmt sich nicht selten nochmal zwei, drei Minuten Auszeit bis die Session wieder ansprechbar ist. Lästig.

Vor Giessen bucht sich die Karte dann das erste Mal per GPRS ein. Offensichtlich ist die Netzabdeckung per UMTS schon relativ weit fortgeschritten, denn bis Kassel zeigt sich, dass entweder UMTS geht, und das gut, oder gar nix. Ganz selten mal blinkt die Karte grün (GPRS) und IP-Pakete gehen durch. Irgendwie ist das GSM-Funkteil der Option-Karte ziemlich bescheiden implementiert. Insbesondere auf dem Abschnitt im “bergigen Nichts” zwischen Wabern und Kassel geht gar nix. Da funkt sogar mein betagtes 6310i besser - was aber eventuell auch daran liegt, dass man das per Bluetooth angekoppelte Mobile direkt ans Fenster stellen kann, während die UMTS-Karte fest ans Notebook gefesselt fast zwangsläufig einen schlechteren Empfangsplatz hat.

Zwei, dreimal kommt es vor, dass der pppd sich nach längeren Netzhängern komplett verabschiedet, “tcflush failed: Bad file descriptor”, gefolgt von “tcsetattr: Invalid argument (line 1010)”; und einem lapidaren “Exit”. In diesem Zustand reagiert die Karte beim folgenden Verbindungswiederaufbauversuch schon auf das “ATZ” gar nicht mehr; man muss das usbserial-Modul entladen, die Karte einmal kurz ziehen und wieder von vorne anfangen. Entlädt man das usbserial-Modul nicht, bleibt es eventuell im Speicher kleben, lässt sich auch mit rmmod -f nicht mehr entfernen und natürlich für die neu eingesteckte Karte nicht mehr neu laden: Reboot tut
gut.

Auf dem kurzen Stück Neubaustrecke zwischen Kassel-Wilhelmshöhe ist nach wie vor wenig bis gar nichts, nicht einmal der über 10 km lange Mündener Tunnel ist inzwischen für GSM oder UMTS erschlossen. Die Mobilfunkanbieter sehen bahnfahrende Reisende immer noch nicht als Kunden, da wird lieber das letzte bisschen Pampa-Autobahn lückenlos ausgeleuchtet.

Auch auf der Weiterfahrt bis Hamburg ist bestenfalls von “manchmal geht es” zu sprechen. Zum interaktiven, ernsthaften Arbeiten ist das völlig unbrauchbar. Zum Mails in den Offline-IMAP-Client reinziehen vielleicht schon eher.

Und: Das ständige Blinken der Karte, und das auch noch in zwei Farben, nervt.