Linux^2

Uuuund einen ganz speziellen Gruß an mein Brüderchen an dieser Stelle! Der ist zwar durch die Verwendung proprietärer Betriebssysteme geschlagen, erleichtert sich den Schmerz aber durch Einsatz von MWconn. Und das Programm hat mittlerweile einen kleinen Bruder, ixconn.

ixconn will eine Komplettlösung sein – Einwahl ins Internet, Anzeige verschiedener Statusdaten, USSD-Abfragen direkt vorgefertigt zur Guthabenabfrage, -aufladung, Homezone-Prüfung und so weiter.

Die Dokumentation (auch im PDF-Format direkt zum Download verfügbar) ist detailliert und nachvollziehbar. Leider schränkt sich die Software auf eine enge Betriebssystemwahl ein: Unterstützt wird Ubuntu x86. Die aktuelle Version 0.2 ist unter bzw. für Ubuntu 9.10 entstanden. Schon auf einem Kubuntu fehlen dem (laut ldd) statisch gebundenen Binary die libgnomeui-2.so.0 – so die Meldung beim Aufruf:

$ ldd /usr/bin/ixconn
not a dynamic executable
$ file /usr/bin/ixconn
/usr/bin/ixconn: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped
$ /usr/bin/ixconn
/usr/bin/ixconn: error while loading shared libraries: libgnomeui-2.so.0: cannot open shared object file: No such file or directory

Da eine Nachinstallation von libgnomeui-0 den halben GNOME-Desktop hinterherzieht, habe ich auf diesen Test erst mal verzichtet. Noch dazu, da es fraglich erscheint, ob ein x86-Binary mit der amd64-Library etwas anfangen kann. Zumindest im Paket „ia32-libs“ ist libgnomeui nicht enthalten.

Um es ganz klar zu sagen: Die oben angeführten Probleme liegen in der Auswahl meines Haupt-Desktops, eben KDE. Unter GNOME, wo die notwendigen Bibliotheken sowieso bereits installiert sind, wäre dies alles kein Problem. Auch die x86-Unterstützung mag Sinn machen, wenn man Netbooks als Zielgruppe ansieht. Ein 64-Bit-OS macht auf den kleinen Kisten sicherlich keinen Sinn. Wer jedoch einen „ausgewachsenen“ Laptop mit sich herumbuckelt, wird mit der Wahl der Architektur sicherlich hadern. Abhilfe scheint aber in Sicht: Über das Download-Forum von MWconn finden sich auch x64-Versionen des reinen ixconn-Binaries. Man kann also annehmen, dass es demnächst auch Pakete für ein 64-Bit Ubuntu geben wird.

Obwohl MWconn wie ixconn kostenlose Software ist, sind die Sourcen leider nicht zu haben. In der Windows-Welt durchaus üblich, mag das für andere ein Hinderungsgrund sein.

Bleibt zugegebenerweise der Eindruck, eigentlich keinen Eindruck bekommen zu haben. Mal sehen, ob ich im Rahmen einer Ubuntu-LiveCD nicht doch noch zu einem ixconn-Erlebnis kommen kann!

Unglaublich. Wenn’s mal regnet, dann gleich Ströme… B^)

Was ich damit sagen will? gammu kann auch USSDs versenden! Jedoch scheint der Umgang noch etwas hakelig zu sein. Eine erster Test mit einer ~/.gammurc mit Inhalt

[gammu]
port = /dev/ttyUSB1
connection = at

und dem Aufruf

gammu -c ~/.gammurc getussd ‚*100#‘

führt bei mir momentan nur zu Timeouts. Ich werde mir das später noch mal genauer ansehen und dann berichten.

Grüße,
Jochen

Bevor ich auch nur die ersten Versuche in Richtung gsm-ussd unternommen habe, gehorchte ich natürlich erst mal dem Imperativ der Faulheit und durchsuchte das Netz, ob nicht schon jemand mein Problem gelöst hat. Wie man sieht, ohne Erfolg. Kaum hat man aber seine Arbeit vollendet, kommt der Hinweis auf das Programm, das man ganz zu Anfang gesucht hat… In diesem Fall: ussdq.

Caveat lector: Da ich hier als Autor von gsm-ussd schreibe, muss jeder selbst wissen, ob er meine Argumente und Meinungen auch teilen will oder möchte.

Eine Ursache, weshalb ich das Programm nicht gefunden haben mag, scheint darin zu liegen, dass der Autor sein Projekt nicht bei freshmeat.net eingetragen hat. Zwar liegt das Programm auf sourceforge.net öffentlich verfügbar und eine Suche nach seinem Namen hat auch Erfolg, aber eine Suche mit naheliegenden Stichwörtern hat – zumindest bei mir – keinen Treffer erbracht. Schade eigentlich, denn so hat das Programm einen Benutzer weniger und einen „Konkurrenten“ mehr…

An Voraussetzungen benötigt das Programm die Rumtime-Umgebung mit der Netzkomponente von Gambas, einer VisualBasic-ähnliche Programmiersprache und IDE. Ist diese installiert, ist die Inbetriebnahme von ussdq leicht:

$ ./configure
$ make
$ sudo make install

Wer nicht direkt installieren will, findet nach dem „make“ das Gambas-„Binary“ unter ussdq/ussdq.gambas. Von dort aus läßt es sich auch problemfrei aufrufen. Eine Man-Page existiert leider nicht, aber das README und die Online-Hilfe helfen weiter:

Usage
-e, –encoding Encoding used for 8-bit characters. You can use any 8-bit encoding by iconv (see iconv-l).
-d, –dcs Method of coding ussd-response. Used when the dcs in the answer modem not defined (gsm7|8bit|ucs2
-n, –no-pdu Assume ascii instead of pdu (for response only)
-f, –force-dcs Use the specified dcs, rather than received from the modem.
-t, –decode-this Decoding this modem response (debug function)
-v, –verbose Verbose output
-i, –in-pdu Encoding query in the PDU format

Grundsätzlich funktioniert ussdq so mit jedem Modem, welches USSD-Anfragen im Klartext versteht und selbst in die Netzwerkpräsentation umsetzen kann und auch die Antworten mit entsprechenden Encoding-Hinweisen versieht. Über die Optionen kann man dann verlangen, dass die USSD-Abfrage im PDU-Format übergeben wird (-i/–in-pdu) oder dass die Rückmeldung nach Vorgabe (statt nach Modem-Angabe) decodiert wird (-f/–force-dcs, -d/–dcs). Besitzt man nun ein Modem, dass mit den Standard-Vorgaben nicht funktioniert, muss man probieren, was funktioniert.

Nach einigem Testen habe ich so mein E160 (dessen Eigenheiten ja ein schlichtes, per picocom abgesetztes AT-Kommando unmöglich machen) mit folgenden Optionen zum Laufen bekommen:

ussdq.gambas -i -f -d 8bit /dev/ttyUSB1 ‚*100#‘

Im Vergleich zu meinem eigenen Programm gefällt mir ussdq erst mal gar nicht schlecht. Schließlich tut es erfolgreich seinen Zweck. Auf den zweiten Blick jedoch offenbaren sich auch Nachteile: Die obige Kommandozeile funktioniert schon nicht mehr bei der USSD-Abfrage „*135#“ (eigene Telefonnummer bei D1). Die zwangsweise vorgegebene 8bit-Kodierung passt nicht mehr und muss weggelassen werden. Wie man es dreht und wendet: Es gibt keine Möglichkeit, das Kommando so anzugeben, dass es bei beiden Abfragen gleichermaßen funktioniert. Sicherlich ist das zu einem gewissen Teil auch Huawei oder D1 anzukreiden, aber ein Problemfall ist es trotzdem.

In technischer Hinsicht gefällt mir die zusätzliche Abhängigkeit zu Gambas2 nicht. Für die Implementierung meines Skripts habe ich mit Bedacht Perl ausgesucht, da es bei jeder Standard-Linuxinstallation vorhanden sein sollte. Das zusätzlich benötigte Modul Expect ist bei allen mir bekannten Distributionen im Standardumfang des Repositories enthalten, was bei Gambas2 leider nicht der Fall ist (RHEL/SLES).

Weiterhin ist die Dokumentation zu ussdq mangelhaft. Kennt man sich mit USSD-Abfragen, Modems, GSM-Zeichensatz und den verschiedenen Kodierungsformaten aus, kommt man über kurz oder lang zu einer für’s eigene Modem passenden Kombination. Fehlt einem das Wissen, steht man den Optionen einigermaßen ratlos gegenüber.

Zu guter Letzt empfinde ich persönlich heutzutage ein einfaches Tar-Archiv als Download für zu wenig. Zwar ist die Installation per Dreiklang „./configure && make && make install“ nicht sehr schwierig, arbeitet aber wieder am Paketmanagementsystem der Distribution vorbei.

Ich hoffe, dass Victor Sidorov seine Arbeit an ussdq weiter fortsetzt. Das Projekt scheint ja – wie auch gsm-ussd – recht jung und aktiv. Aber meine eigene Arbeit an gsm-ussd werde ich deswegen nicht einstellen.

Hi da draußen,

nehmen wir mal an, jemand hat Euch von gsm-ussd erzählt, ihr habt’s ausprobiert und – nix funktioniert. Was tun?

Beim Debuggen helfen ein paar Optionen zu gsm-ussd. Keine Bange, „Debuggen“ klingt hier schlimmer als es ist: In erster Linie dreht es sich darum, zu erfahren, was hinter den Kulissen tatsächlich passiert.

Die Option „-d“ oder „–debug“ macht gsm-ussd ziemlich geschwätzig. Alle Aktionen, abgesetzten Kommandos, erkannten Antworten usw. werden dann mitprotokolliert. Dies hilft, die Stelle zu erkennen, an der etwas schiefläuft. Die Option „-l“ oder „–logfile„, die einen Dateinamen als weiteres Argument benötigt, schreibt den Chat zwischen Programm und Modem unverändert in die benannte Datei. So kann man erkennen, warum bestimmte Ereignisse vielleicht nicht erkannt werden.

Wenn man nun also ein Problem hat, ruft man gsm-ussd wie folgt auf:

gsm-ussd -d
-l chat.out <…Optionen nach Bedarf…> 2>&1 |
tee gsm-ussd.out

Dies zeigt den Debug-Output an, schreibt ihn zusätzlich in die Datei gsm-ussd.out und legt das Chatlog in der Datei chat.out an. Mailt mir diese Dateien, ich werfe dann einen Blick darüber und schaue nach, wo das Problem liegt.

Weitere interessante Informationen in einem Fehlerbericht wäre zusätzlich der Output von „lsusb„.

Grüße,
Jochen

Hi everyone,

suppose someone told you about gsm-ussd, you tried it – and it doesn’t work as expected. Now what to do?

There are some option you can supply to get debugging output. Don’t worry, it sounds scarier than it is! Option „-d“ or „–debug“ will make gsm-ussd quite verbose; every step in communicating with the modem is reported. Option „-l“ or „–logfile“ with a filename as argument will write the chat between gsm-ussd and the modem into the named log file.

So, if you have a problem, try the following command:

gsm-ussd -d -l chat.out <…further options as needed> 2>&1 | tee gsm-ussd.out

This will show you the debug output and create two files: chat.out containing the chat log and gsm-ussd.out containing the debugging output. Mail these files to me; I promise to take a look.

Cheers,
Jochen

Eine kleine Entstehungsgeschichte

Da ich jeden Arbeitstag eine gute Strecke im Zug pendele, ist mir mein Laptop zum ständigen Begleiter geworden. Spielen, lesen, lernen, programmieren, schreiben geht mir mit ein wenig Musik auf den Ohren leicht von der Hand. Fehlt eigentlich nur noch die Möglichkeit, ein wenig surfen zu können. So ein UMTS-Stick wäre da schon eine schöne Sache – ein paar textlastige Info-Websites kann man ja schon aushilfsweise per Handy besuchen, aber warum mit einem Briefmarkendisplay begnügen, wenn man dem Browser auch 1280×800 Pixel zur Verfügung stellen kann?

Als Aldi den „Medion S4011 Surfstick“ in ihr Sortiment aufnahm, dauerte es nur eine kleine Recherche lang (kein SIM-Lock, ist in Wirklichkeit ein Stick von Huawei und wird unter Linux unterstützt), bis ich meine Technikausstattung um ein UMTS-Modem erweiterte. Obwohl ich sonst mit dem Prepaid-Tarif von Aldi (Medion Talk, E-Plus-Reseller) zufrieden bin, kaufte ich mir eine Congstar SIM dazu. Warum? Auf einigen Streckenabschnitten ist die E-Plus-Netzabdeckung so schlecht, dass Telefonate zusammenbrechen. Da wollte ich mal testen, ob das D1-Netz auf der Strecke besser ausgebaut bzw. stabiler ist.

Wie das Leben so spielt, hatte ich nun zwar den Stick, aber aus verschiedenen Gründen erst mal keine Zeit, damit auch wirklich zu basteln. Letzten Endes war die Inbetriebnahme unter Linux aber auch kein Riesenproblem: Unter Kubuntu 9.10 wird der Stick beim Einstecken erkannt und im knetworkmanager angeboten. Die Einrichtung des Zugangs war bis auf den knetworkmanager-Hirnschaden, dass man als Einwahlnummer nur „*99“ eintragen darf („**1#“ ergänzt das Programm von alleine!), kein echtes Problem. So surfte ich denn ein wenig umher und war’s zufrieden – für 35¢ pro MB, abgerechnet in 10K-Paketen. Nicht gerade billig, aber sooo viel Traffic wird man ja schon nicht verursachen. Apropos, wie ist eigentlich noch mein Guthaben auf der Karte?

Auf dem Handy ist die Guthabenabfrage kein Problem: „*100#“ ist bei so ziemlich jedem Prepaid-Tarif die Abfrage für’s Restguthaben. Notfalls kann man ja auch die Servicenummer anrufen und sich durch die Menüs arbeiten, aber so viel Geduld bringe ich normalerweise nicht auf. Aber wie jetzt diese Abfrage mit dem UMTS-Stick stellen?

An dieser Stelle ergaben sich mehrere Möglichkeiten.

1. Windows statt Linux auf dem Laptop installieren, denn die Software, die der Stick per ZeroCD mitbringt (Windows-Only natürlich), hat dafür eine Funktion.
2. Nach Linux-Tools recherchieren für diesen Zweck recherchieren. Ich kann doch nicht der Erste mit diesem Problem sein!
3. Die SIM-Karte aus dem Stick ziehen, in ein Handy packen, die Abfrage machen und den Ausgangszustand wieder herstellen.
4. Forschen, wie der Stick funktioniert und dann sich selbst ein Tool dazu programmieren.

Selbstverständlich fiel „Lösung“ Nr. 1 sofort flach. Schließlich wollte ich ja nicht das Pferd von hinten aufzäumen.

Lösung Nummer 2 hat mich einige Zeit gekostet, nur um einsehen zu müssen, dass ich scheinbar doch der Erste war, der dieses Problem hatte. Das ansonsten sehr umfangreiche umtsmon hat Schwierigkeiten mit dem 64-Bit-Linux und scheinbar auch keine Funktion, um solche Abfragen zu stellen. Jedoch war die Zeit, die ich in die Recherche dieser Tools steckte, nicht ganz verloren, da sich jede Menge Informationen zu USB-UMTS-Modems im Allgemeinen und Huawei-Modems im Speziellen finden ließ. Die wichtigsten Hinweise waren die Erläuterung, dass Code wie „*100#“ USSD-Codes sind und dass ein UMTS-Modem genau das ist: Ein Modem wie anno dazumals und daher mittels AT-Befehlssatz zu steuern.

Lösung Nummer 3 habe ich exakt einmal ausprobiert. Abgesehen von der Tatsache, dass der Stick die SIM-Karte nur widerwillig hergegeben hat, musste ich sowohl den Stick als auch das Handy komplett zerlegen – für eine schnelle Guthabenabfrage im Zug vollkommen ausgeschlossen.

Seufz. Da war ja noch Lösung Numero 4…

Also erst mal etwas forschen. Steckt man den Stick an, schlägt sich das nach kurzer Zeit im Kernellog nieder:

usb 2-3: new high speed USB device using ehci_hcd and address 10
usb 2-3: configuration #1 chosen from 1 choice
option 2-3:1.0: GSM modem (1-port) converter detected
usb 2-3: GSM modem (1-port) converter now attached to ttyUSB0
option 2-3:1.1: GSM modem (1-port) converter detected
usb 2-3: GSM modem (1-port) converter now attached to ttyUSB1
scsi23 : SCSI emulation for USB Mass Storage devices
scsi24 : SCSI emulation for USB Mass Storage devices
scsi 24:0:0:0: Direct-Access HUAWEI MMC Storage 2.31 PQ: 0 ANSI: 2
sd 24:0:0:0: Attached scsi generic sg2 type 0
scsi 23:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
sd 24:0:0:0: [sdb] 15564800 512-byte logical blocks: (7.96 GB/7.42 GiB)
sd 24:0:0:0: [sdb] Write Protect is off
sdb: sdb1
sd 24:0:0:0: [sdb] Attached SCSI removable disk
sr1: scsi-1 drive
sr 23:0:0:0: Attached scsi generic sg3 type 5

CD-ROM? Ach ja, das ZeroCD-Verfahren, bei dem der Stick dem Rechner vorgaukelt, es wäre ein Laufwerk mit eingelegtem Medium, um direkt Treiber und Software für die eigentliche Funktion des Sticks zur Verfügung zu stellen. Der MMC-Storage entspricht der Micro-SDHC-Karte, die am Stick eingesteckt werden kann. Um an die eigentliche UMTS-Modem-Funktioninalität des Sticks zu gelangen, muss der Kernel diesen erst umschalten. Bei Kerneln vor Version 2.6.20(?) war dazu ein Programm wie usb_modeswitch, ozerocdoff oder huaweiAktBbo notwendig.

Wie man an den „GSM-Modem converter now attached to ttyUSB0/1“- Meldungen erkennen kann, hat der Kernel den Stick bereits als UMTS-Modem erkannt und aktiviert. Warum aber stellt ein Stick zwei serielle Schnittstellen bereit? /dev/ttyUSB0 stellt den PPP-Port dar; hierüber laufen bei stehender Verbindung die Daten. /dev/ttyUSB1 dagegen ist der AT- oder Control-Port, über den man dem Modem Anweisung erteilen kann oder davon Statusmeldung lesen kann. Was hier so simpel und einfach klingt, hat mich zu Beginn der Arbeit sicherlich zwei Stunden Zeit gekostet: Ein auf /dev/ttyUSB0 eingebenes Kommando gibt zwar noch das dazugehörige OK oder ERROR über den gleichen Port aus, aber das spätere Ergebnis einer Netzabfrage bekommt man nur auf /dev/ttyUSB1 zu sehen…

Um also mit dem Modem in Kontakt zu treten, muss man das passende Device öffnen und kann dann darüber im Dialog Kommandos absetzen und die Antworten dazu auslesen. Das Tool der Wahl dazu war picocom, da es den Vorteil hat, sich vollkommen aus der Kommunikation zwischen Programmierer und Modem herauszuhalten. Lediglich eine Log-Funktion habe ich mir manchmal gewünscht, aber mit Copy&Paste gibt es einen einfachen Workaround.

ALso frohen Mutes „picocom /dev/ttyUSB1“ eingeben und – Kontakt! Alle paar Sekunden laufen Meldungen wie

^BOOT:31610740,0,0,0,75

^RSSI:15

^BOOT:31610740,0,0,0,75

^BOOT:31610740,0,0,0,75

^RSSI:15

^MODE:5,5

durch’s Terminal. Ein zaghaftes „AT“ beantwortet das Modem auch mit „OK„, die Anfrage nach Modeminformationen („ATI„) beantwortet es mit

Manufacturer: huawei
Model: E160
Revision: 11.608.06.00.52
IMEI: 123456789012345
+GCAP: +CGSM,+DS,+ES

OK

Schön zu wissen: lsusb meldete das Modem als E220, da Huawei ein und dieselbe USB-ID für mehrere Modemserien verwendet… Na, denn mal die USSD-Abfrage stellen:

AT+CUSD=1,“*100#“,15
ERROR

Nanu? Laut Webrecherche und GSM-Standard hätte das klappen sollen. Den entscheidenden Hinweis brachte ein Thread im technischen Forum bei Huawei selbst: Die für’s Netzwerk nötige Umkodierung des Strings kann beispielsweise ein E169 in der Firmware vornehmen, ein E160 dagegen nicht. Weitere Infos aus dem mwconn-Forum und von nobbi.com liessen das Bild dann klar werden. Folgendes war zu programmieren:

1. USSD-Code in anderen Zeichensatz überführen (GSM 03.38) und umkodieren
2. Generell mit dem Modem sprechen können, dabei aber irrelevante Statusmeldungen unterdrücken
3. Prüfen, ob überhaupt ein Modem angeschlossen ist
4. Prüfen, ob es eine PIN benötigt, falls ja, diese setzen. Klappt das nicht, abbrechen!
5. Abfrage stellen und das Ergebnis erwarten
6. Das Ergebnis wieder dekodieren (entpacken, nach UTF-8 umsetzen)

Und wieder einmal zeigte sich, dass blinder Aktionismus weh tut. Perl bringt seit Version 5.8 das Modul Encoding mit, welches auch eine Konvertierung aus/zu dem Zeichensatz GSM03.38 beherrscht. Das habe ich aber erst herausgefunden (genauer gesagt – überhaupt danach gesucht), als ich eigene Routinen schon geschrieben hatte…

Die Kommunikation mit dem Modem erledigt das Modul Expect. Dieses Modul implementiert die Funktionalität des TCL-Tools expect in Perl; man kann es sich als ein ultimativ flexibles Mittel zur Programmierung von Chat-Skripten vorstellen.

Mit dieser Infrastruktur ist grundsätzlich schon eine gute Kommunikation mit dem Modem möglich, wenn da nicht noch das Umpacken der Daten in die Netzwerkrepräsentation wäre, die das E160 benötigt. Also noch ein wenig Bitschiebereien implementieren; das Packverfahren wird übrigens auf http://www.nobbi.com/sms_pdu.html unter „User Data:“ prima dargestellt.

Und dann kommen noch die äußeren Begleitumstände dazu: Da ich ja schon immer mal den Umgang mit git oder Mercurial lernen wollte, gab dieses Projekt dafür das Versuchskaninchen ab. Und wenn nun auch andere an so einem Tool Interesse haben, dann sollte man auch direkt eine Website dazu anlegen, bei github.com ein öffentliches Repository anlegen, die Dokumentation nicht nur auf Deutsch, sondern auch auf Englisch schreiben, dabei auch Ausgaben & Kommentare auf Englisch umstellen… Die Liste ließe sich problemfrei noch erweitern. Aber dazu werde ich später noch mehr schreiben.

Grüße,
Jochen

Hey, World!

Thanks to the friendly help of gsm-ussd users in this debianforum.de thread (Attention: German spoken there), there’s a new release of gsm-ussd: v0.2.0 is out.

A few modems were tested in addition to my crappy E160. As a result, other modems with a bit more brain than my retarded E160 should work for real this time. To be exact: Better modems don’t need to encode the USSD query as a Hexstring of packed seven bit values (and don’t need to decode teh answer out of several encodings…). If gsm-ussd recognizes a Non-E160, it will use cleartext. You can use the options „–cleartext“ or „–no-cleartext“ at your own risk.

If you prefer clicking to typing, xussd is for you. xussd is a shellscript which runs gsm-ussd, too, but beautifies its input and output with kdialog (if you’re running KDE) or zenity (if GNOME is your DE of choice). There are input boxes for USSD query and PIN, the modem device still has to be set by option „-m /dev/my-modem-ctrl-port“ at run time. Just create a desktop icon which runs xussd and specify your modem device there.

Here are the downloadable files:
http://linux.zum-quadrat.de/downloads/gsm-ussd_0.2.0-0.tar.gz
http://linux.zum-quadrat.de/downloads/gsm-ussd-0.2.0-0.noarch.rpm
http://linux.zum-quadrat.de/downloads/gsm-ussd_0.2.0-0_all.deb

As usual the reminder that the real project is on github.com:
http://github.com/JochenHoch2/gsm-ussd.git
or
git://github.com/JochenHoch2/gsm-ussd.git

Good to see that there’s some interest in my little script!

Have fun,
Jochen

Hi, Welt!

Aufgrund der tatkräftigen Unterstützung von gsm-ussd Anwendern in diesem Thread auf debianforum.de gibt es eine neue Release von gsm-ussd: v0.2.0 ist raus.

Ein paar Modems wurden zusätzlich getestet. Als Ergebnis sollten diesmal wirklich
auch andere Modems als das E160 funktionieren. Um genau zu sein: Modems mit ein bisschen mehr Grips als das E160 benötigen keine Umkodierung der USSD-Abfrage in einen Hexstring aus gepackten 7-Bit-Werten (und auch keine Dekodierung der Antwort aus verschiedenen Kodierungen…). Erkennt gsm-ussd ein solches Nicht-E160, verwendet es direkt Klartext. Man kann die Erkennung auch auf eigene Gefahr über die Optionen „–cleartext“ bzw. „–no-cleartext“ übergehen.

Wer nicht so gerne tippt, sondern lieber klickt, für den gibt es jetzt zusätzlich xussd. Das ist ein Shellskript, welches letzten Endes auch nur wieder gsm-ussd aufruft, dies aber über kdialog (unter KDE) bzw. zenity (unter GNOME) anhübscht. USSD-Abfrage und PIN werden abgefragt, Modemgerät muss ggf. mit Parameter „-m /dev/mein-modem-ctrl-port“ beim Aufruf mitgegeben werden. So sollte es kein Problem sein, sich ein Icon auf den Desktop zu legen, über das man per Mausklick die Abfrage starten kann.

Hier die Dateien zum Download:
http://linux.zum-quadrat.de/downloads/gsm-ussd_0.2.0-0.tar.gz
http://linux.zum-quadrat.de/downloads/gsm-ussd-0.2.0-0.noarch.rpm
http://linux.zum-quadrat.de/downloads/gsm-ussd_0.2.0-0_all.deb

Wie üblich liegt das eigentliche Projekt auf github.com:
http://github.com/JochenHoch2/gsm-ussd.git
bzw.
git://github.com/JochenHoch2/gsm-ussd.git

Schön, dass sich auch ein paar Leute für das interessieren, was ich mir so zusammenklöppel!.

Viel Spass damit,
Jochen