Blog Image

Linux^2

What you may find here

In this blog you'll mainly find all things Linux - problems, solutions, reports, rants, tips & tricks etc. with the occasional off-topic entry thrown in. You never would have guessed looking at the URL, huh?
In diesem Blog findet ihr hauptsächlich Themen rund um Linux - Probleme, Lösungen, Berichte, Meinungen, Tips & Tricks und dazwischen ein paar überhaupt nicht dazu passende Einträge. Wärt ihr bei der URL nie drauf gekommen, ne?

Mailt mal! Email me!

Ein Blick auf ussdq

gsm-ussd Posted on So, Mai 09, 2010 19:21:14

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.



Wie man gsm-ussd debuggt

gsm-ussd Posted on So, Mai 09, 2010 12:30:29

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