Bisecting mesa - bug 446632

Bug 446632 is responsible for the segfaulting blender on start-up on machines with ATI graphics cards running Ubuntu Karmic.

Analysis showed that the segfault originated in the mesa library. The code of the mesa contains the OpenGL implementation under Linux, and is used by Blender and various other programs.

During the pre-release process of Karmic, various builds of the mesa package have been made and are still available online. Tests showed that the last build without the bug was 7.6.0~git20090817.7c422387-0ubuntu8. The next one was 7.6.0-1ubuntu1.

To determine which patch between those two releases is responsible for the bug, a process called git-bisecting is used. For this, you give git the id of a version with and without the bug. Git chooses a version in the middle. You check it out, compile it and test it. After that you tell git if this version was good or bad. After that git chooses another version halfway between the last good and the first bad one. This process is repeated until you find the bad commit.

Sounds simple enough.... but it raises the following questions:

• What Git repository does Ubuntu use for the mesa package?
• Which commits correspond to the above mentioned builds?
• And once you have the source, how do you compile, package and use it?

Within the Ubuntu project there is no git repository that describes the way from 7.6.0~git20090817.7c422387-0ubuntu8 to 7.6.0-1ubuntu1. Therefore we use the upstream git repository at git://anongit.freedesktop.org/mesa/mesa (browseable: http://cgit.freedesktop.org/mesa/mesa) on which the Ubuntu version is based.

7c422387 is the commit id within the freedesktop repository (well, not quite. The real commit ID is 7c4223876b4f8a78335687c7fcd7448b5a83ad10, but the first few digits are usually sufficient to find it).

The last commit of the 7.6.0 branch in this repository has the label mesa_7_6

The way to compile the source is described later in this post. As you will see, packaging is not necessary. The compiled drivers can be used directly.

"Git"ting started

You need git-core - and also download gitk (which is not really necessary, but makes a nice graphical representation).

sudo apt-get install git-core gitk

choose a directory and download the entire repository (in this tutorial I use my home directory).

cd ~
git clone git://anongit.freedesktop.org/mesa/mesa

This will create the subdirectory mesa, and a subdirectory .git, that contains the content of the cloned repository.

Be patient. After counting the elements to be transferred it takes some time before the actual download begins. All in all around 100 MB.

The code that we are going to compile needs some additional source files:

sudo apt-get build-dep mesa
sudo apt-get install libx11-dev libxt-dev libxmu-dev libxi-dev

Further preparations

make clean
./autogen.sh
./configure --prefix=/usr --mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info --sysconfdir=/etc \
--localstatedir=/var --build=i486-linux-gnu --disable-gallium --with-driver=dri \
--with-dri-drivers="r200 r300 radeon" --with-demos=xdemos --libdir=/usr/lib/glx \
--with-dri-driverdir=/usr/lib/dri --enable-glx-tls --enable-driglx-direct --disable-egl \
--disable-glu --disable-glut --disable-glw CFLAGS="-Wall -g -O2"

make clean removes the "debris" from previous compilations. But we haven't created any yet... Do it anyway - it's good practice :-)

./autogen.sh verifies that all prerequisites are met. If anything is missing, it will complain.

./configure sets up what is compiled, where and how.

During the tests remove -O2 (under CFLAGS). This disables compiler optimisations. The resulting code is a bit larger and a little bit slower, but it is easier to use during debugging.

--with-dri-drivers="..." determines which drivers are compiled. As the original bug only affects ATI machines, we only need the drivers we use. That saves a lot of compile time. If yours is not among them, check out ~/mesa/src/mesa/drivers/dri/ and add it.

You can find out which driver you are using with:

xdriinfo driver 0

Verify the good build

We know that build 7c4223876b4f8a78335687c7fcd7448b5a83ad10 still works with Blender. So let's check it out, compile it and test it. If Blender does not crash, we know that the process so far is working correctly.

git checkout 7c422387
make

We could enter the entire ID, but the first few digits are usually sufficient.

make should finish without errors. Now we start Blender using:

LD_LIBRARY_PATH="~/mesa/glx" LIBGL_DRIVERS_PATH="~/mesa/src/mesa/drivers/dri/radeon" Blender

LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH make Blender (and only Blender, or any other program you specify) use the just compiled libraries. No need to reboot or to restart X. No effects to the remaining programs.

Please note, that you may need to replace the radeon part of the driver path with r200 or r300 depending on the driver you use.

Blender should run correctly.

Bisecting

We now officially start the bisecting process:

git bisect start

... and tell git that this was a "good" build.

git bisect good

Checking out the bad build

As we can not pinpoint which git version corresponds to first bad Ubuntu build (7.6.0-1ubuntu1) we simply start at the newest commit in the mesa_7_6 branch:

git checkout mesa_7_6

This replaces the files in the mesa directories and its subdirectories (except .git) with the new ones.

We compile it:

make

and test it:

LD_LIBRARY_PATH="~/mesa/glx" LIBGL_DRIVERS_PATH="~/mesa/src/mesa/drivers/dri/radeon" Blender

This time Blender should crash. We notify git:

git bisect bad

With this command, git chooses a commit approx. in the middle:

Bisecting: 482 revisions left to test after this (roughly 9 steps)
[ee066eaf6d0dd3c771dc3e37390f3665e747af2a] llvmpipe: Allow to dump the disassembly byte code.

The make, test, bisect process is repeated until git displays the first bad commit.

bfbad4fbb7420d3b5e8761c08d197574bfcd44b2 is first bad commit
commit bfbad4fbb7420d3b5e8761c08d197574bfcd44b2
Author: Pauli Nieminen 
Date: Fri Aug 28 04:58:50 2009 +0300
r100/r200: Share PolygonStripple code.
:040000 040000 1b1f09ef26e217307a5768bb9806072dc50f2a14 eb20bf89c37b2f59ce2c243b361587918d3c9021 M src

As an interesting side note, the driver from this commit does crash Blender, but not with a segfault. There is even an output on the console: "drmRadeonCmdBuffer: -22".

The next commit in this branch 4322181e6a07ecb8891c2d1ada74fd48c996a8fc makes Blender crash the way we have come to know.

The previous commit (e541845959761e9f47d14ade6b58a32db04ef7e4) would be a good candidate to keep Blender running until mesa is fixed:

git checkout e541845959761e9f47d14ade6b58a32db04ef7e4
make
LD_LIBRARY_PATH="~/mesa/glx" LIBGL_DRIVERS_PATH="~/mesa/src/mesa/drivers/dri/radeon" Blender

Ackowledgements
Tormod Volden for creating and updating https://wiki.ubuntu.com/X/BisectingMesa and various other info.

References
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/446632
http://bugs.freedesktop.org/show_bug.cgi?id=25354
https://wiki.ubuntu.com/X/Bisecting
https://wiki.ubuntu.com/X/BisectingMesa
https://launchpad.net/~xorg-edgers/+archive/ppa
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
http://cgit.freedesktop.org/mesa/mesa

Update zum "Blender"-Bug

Bei den Abstürzen von Blender unter Ubuntu Karmic scheint es sich nicht um einen Fehler in Blender zu handeln, sondern um einen Bug im Paket mesa, das für die OpenGL-Implementierung unter Linux zuständig ist.

Der Bug-Report ist unterdessen upstream gemeldet.

Blender-Absturz in Karmic

Blender 2.5 Alpha 0 ist gerade erschienen, und dass dies nicht auf Anhieb funktioniert erwartet man fast.

Dass allerdings die ältere Version von Blender (2.49a) aus den Ubuntu-Repositories nicht funktioniert, ist dann schon ärgerlicher, zumal sich wahrscheinlich das nächste halbe Jahr nichts daran ändern wird.

Blender stürzt nach dem Aufruf mit einem Segfault ab.

Probleme scheinen mal wieder nur die ATI-Karten zu haben.

Bug-Report in Ubuntu's Launchpad

itrackutil 0.1 veröffentlicht

Seit einigen Wochen bin ich Besitzer eines XAiOX iTrackU GPS Loggers.

Das Gerät verwendet den SirfIII Chipsatz, besitzt Bluetooth und kann bis zu 250.000 Wegpunkte speichern, das sind, wenn man einen Punkt pro Sekunde aufzeichnet, fast drei Tage.

So lange hält der eingebaute Akku zwar nicht, aber die - laut Prospekt - immerhin 17 Stunden sind reichlich bemessen.

Außerdem hat er eine Sprachansage, zur Quittierung verschiedener Betriebszustände (Bluetooth ein/aus, Satellitensuche, Fix).

Die Sprachansage ist wohl eher dem (bis auf die Firmware) baugleichen Gerät mit dem Namen TrapScout zu verdanken, das als "Speed Camera Detector" per USB eine Datenbank mit Koordinaten programmiert bekommt und dann an den "Points of Interest" die Ansage "Sie fahren zu schnell." ausgibt.

Für OSM-Tracker ist natürlich die erste Variante interessanter.

Und zunächst sah es so aus, als hätte ich nach längerer Zeit ein Gerät gefunden, für das es unter Linux keine Software gab. Aber auch hier war mir jemand zuvorgekommen. Harmut Schimmel hatte bereits vor einiger Zeit ein paar Perl-Skripte geschrieben, mit denen das Gerät von der Kommandozeile aus programmiert und ausgelesen werden konnte und diese auf seiner Site veröffentlicht.

Ein paar offene Fragen gab es dann aber doch noch. Die Ergebnisse von USB Sniffer und ein wenig Knobelei habe ich dokumentiert und sie sind in meine Utility itrackutil, das auf SourceForge in der Version 0.1 veröffentlicht worden ist, eingeflossen.

Viele Stellen in den vom Logger gesendeten Daten sind noch unklar, und können nur durch Vergleich mit anderen XAiOX iTrackU mit SirfIII Chipsatz vielleicht weiter entschlüsselt werden.

Außerdem berichtet Hartmut, dass weitere Geräte "kompatibel" sind. Tester mit diesen Geräten suche ich auch:

• XAiOX iTrackU mit Nemerix Chipsatz
• Gisteq PhotoTrackr
• Gisteq PhotoTrackr Lite (DPL700)

Das Programm läuft zurzeit unter Linux (Ubuntu Karmic), stellt aber von den weiteren Abhängigkeiten keine allzu großen Hürden auf.

Und obwohl diese Pakete auch unter Windows verfügbar sind, haben erste Versuche gezeigt, dass die zur USB-Kommunikation eingesetzte Bibliothek libusb dann doch nicht 100%ig ihrem Linux-Pendant entspricht.

USB Sniffing unter Linux

USB Sniffing – also das „Belauschen“ der USB-Kommunikation zwischen Computer und Endgerät – wird gerne eingesetzt, wenn für ein Gerät zwar ein Windows-Treiber aber kein Linux-Treiber vorhanden ist. Man versucht dabei herauszubekommen, welche Aktionen in der Windows-Anwendung welche USB-Kommunikation nach sich zieht, um dies dann in einer Linux-Anwendung nachzubilden.

Hierzu wird normalerweise ein Treiber im Windows-System installiert, der die Daten abfängt und protokolliert, bevor Sie an die USB-Schnittstelle weitergeleitet werden.

Auch unter Linux gibt es eine derartige Einrichtung. Sie nennt sich:

usbmon

Das Aktivieren ist unter Ubuntu Jaunty denkbar einfach:

sudo mount -t debugfs none_debugs /sys/kernel/debug

Unter Hardy ist usbmon noch ein separates Kernelmodul, das zusätzlich mit

sudo modprobe usbmon

eingebunden werden muss.

Danach erscheinen unter /sys/kernel/debug/usbmon diverse Dateien. Zum Beispiel:

$ls /sys/kernel/debug/usbmon

 0s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u

Die Zahl im Namen bezeichnet die Nummer des USB-Busses (hier 1, 2 und 3). Der virtuelle „Bus 0“ liefert die Events aller Busse. Der Buchstabe hinter der Zahl (s, t, u) beschreibt, was ausgegeben werden soll:

u – der mitgeschnittene Datenverkehr
s – Statusmeldungen
t – eine Teilmenge von „u“ (dieser Eintrag wird in absehbarer Zeit nicht mehr unterstützt).

Was bleibt, ist diese Datei auszugeben und/oder in eine Datei umzuleiten, z.B.:

cat /sys/kernel/debug/usbmon/0u > usbmon.txt

Wireshark

Ganz ohne dieses Modul kommt Wireshark aus. Mit „Capture – Interfaces“ kann auch ein USB-Bus ausgewählt werden. Hierzu sind natürlich root-Rechte notwendig.

Wireshark stellt die USB-Kommunikation in ähnlicher Weise wie sonst den Netzwerkverkehr dar. Außerdem werden die diversen Konstanten und Strukturen, wie bei Wireshark üblich, schon dekodiert und mit Klartext ausgegeben.

Was bringt's?

Virtuelle Maschinen (z.B. VirtualBox, Vmware) haben unterdessen die Möglichkeit, USB-Geräte im virtualisierten System laufen zu lassen, die über das Gast-System auf die USB-Schnittstelle zugreifen.

Kombiniert man diese beiden Möglichkeiten, so lassen sich z.B. Geräte in einer virtualisierten Windows-Umgebung betreiben, und „von außen“ belauschen.

Licht im Tunnel

Um die meist textbasierten Internet-Protokolle von Hand auszuprobieren verwendet man häufig Telnet. So kann man sich mit


telnet www.google.de 80

mit einem Web-Server verbinden und eine Seite mit

GET / HTTP/1.0

abrufen.

In ähnlicher Weise kann man andere Protokolle ausprobieren.Wenn Sie also immer schon wissen wollen, was der Befehl UIDL bei POP3-Servern bewirkt, telnet bringt Sie Ihrem POP3-Server näher.

Wenn die Verbindung mit SSL verschlüsselt ist, hilft telnet nicht mehr weiter.

In einem Artikel bei Heise wird der Einsatz von openssl beschrieben. Die Unterfunktion s_client stellt das SSL-Pendant zum guten alten telnet dar.

openssl s_client -connect www.heise.de:443

Nachdem die SSL-Verbindung aufgebaut ist, werden diverse Informationen angezeigt (chain of trust, Serverzertifikat, verwendete Verschlüsselungsalgorithmen usw.).

Danach kann man sich - wie bei Telnet - mit dem Server unterhalten.

Der lange Marsch nach Huawei

Das UMTS-Modem

Zurzeit gibt es bei Aldi-Süd den „Internet-USB-Stick S4011“ für knapp 60 €.

Die von lsusb ausgegebene USB-ID sowie die „Selbstauskunft“ des Sticks zeigen aber, dass es sich um ein Huawei E160 handelt, wie sie im Augenblick zu Tausenden in Startersets von diversen Mobilfunkanbietern unter die Leute gebracht werden.

Unter der Glasabdeckung des Lebensmitteldiscounters war jedoch die Rückseite nicht zu erkennen, die auf das hauseigene Starterset hinweist. Ganz unten findet sich dann aber dann der Hinweis, dass dieses Starterset nicht im Lieferumfang enthalten ist.

Und in der Tat hat dieser Stick, im Gegensatz zu vielen anderen (teilweise teureren) „Startersets“, keinen Sim-Lock und ist hier schon mit den SIM-Karten der unterschiedlichsten Mobilfunkanbieter gelaufen.

Eine kurze Recherche zeigte, dass der Stick vom (noch) aktuellen Ubuntu Jaunty unterstützt wird, und in der Tat läuft er mit dem Network-Manager ohne Probleme.

Der Datentarif

Ohne SIM-Karte läuft aber auch dieses Modem nicht. Da der Stick nur gelegentlich eingesetzt werden soll, fiel die Wahl - nach einiger Suche - auf die Prepaid-Karte von Fonic.

Auch dort gibt es ein Starterset – 69,95 € mit 5 Tagen freies Surfen. Der Stick, ein – wer hätte es gedacht – Huawai E160, hat jedoch, nach Auskunft der Hotline, einen Simlock.

Da ich ja nun bereits ein simlock-freies E160 habe war die Alternative die normale SIM-Karte von Fonic (mit 111 Freiminuten). Da die Freiminuten bzw. die „Frei-Tage“ als Guthaben auf das Prepaid-Konto gutgeschrieben werden besteht zwischen den Angeboten kein großer Unterschied.

Der normale Datentarif kostet zurzeit 0,24 €/MB und kann von der Hotline vom Volumentarif auf die Tagesflatrate zu 2,50 € umgestellt werden. Bei der Flatrate wird nach 1 GB am Tag die Geschwindigkeit gedrosselt.

UMTSmon

Wie bereits erwähnt läuft der Stick unter Network-Manager ohne Probleme. Bei meiner Recherche bin ich aber auf das Programm UMTSmon gestoßen.

UMTSmon gab es schon bevor die Funktion in den Network-Manager integriert wurde. Es hat ein paar nützlich Zusatzfunktionen, wie das Anzeigen der Empfangsfeldstärke, SMS-Versand und das Nachhalten der verbrauchten Zeit und des verbrauchten Datenvolumens.

UMTSmon ist leider nicht in den Ubuntu-Repositories verfügbar. Ein i386 Binary ist jedoch im Download-Bereich des Projekts zu finden.

usb_modeswitch

UMTSmon verlangt nach einem weiteren Progamm: usb_modeswitch. Das Programm ist auf der Seite des Autors erhältlich. Das Debian-Projekt hält es als .deb-Paket vor. Bei neueren Kernels ist usb_modeswitch eigentlich nicht mehr notwendig, da der Kernel diese Funktion übernimmt.

Die Huawai-Sticks melden sich nämlich zunächst als USB-Massenspeicher an. Dieser Massenspeicher enthält Software und Treiber, die unter Windows per Autorun gestartet und installiert werden. Diese Treiber schalten dann den Stick in den „Modem-Modus“ um. Unter Linux übernimmt diese Funktion usb_modeswitch, und seit einiger Zeit der Kernel. Diese Technik ist auch als ZeroCD bekannt.

… und die Problemchen

Beim ersten Aufruf prüft UMTSmon diverse Abhängigkeiten. Zunächst bemängelte es das fehlende SUID-Bit bei usb_modeswitch. usb_modeswitch braucht für seine Aufgabe Root-Rechte. Diese waren schnell nachgetragen mit:

sudo chmod u+s /usr/sbin/usb_modeswitch

Das nächste Problem bestand darin, dass sich das Modem in kein Netz einwählen konnte. Der Network Operator Wizard (Verbindung – Netzbetreiber auswählen) zeigte zwar diverse Netze an, nur ansprechen konnte ich sie nicht. Dieses Problem löste sich aber mit der Zeit von selbst. Man sollte bei neuen SIM-Karten warten bis sie freigeschaltet sind... :-)

Nach der Freischaltung fand das Modem auch das von Fonic verwendete O2-Netz.



Danach habe ich eine neues Profil für Fonic angelegt (Verbindung – Profile bearbeiten – Add Profile). Als APN (Zugangspunkt) habe ich die im Netz angegebene Adresse „pinternet.interkom.de“ verwendet (ohne Gewähr). Ansonsten habe ich die Standardeinstellungen belassen.

pppd

Der Versuch, sich mit dem Internet zu verbinden (2. Icon von links - „Connect to default profile“), scheiterte mit der Fehlermeldung:



und den vielsagenden Erklärungen:

• << ppp did not provide any stdout information >> und
• << ppp did not provide any stderr information >>

Leider brachte mich der gutgemeinte Hinweis auf die Kommandozeilen-Option -v4 nicht viel weiter. Sie bewirkt, dass UMTSmon Debug-Informationen ausgibt. Unter anderem sieht man die Kommunikation mit dem Modem.

Zum Einbinden des Internets ruft UMTSmon den pppd Daemon auf. Sehen wir uns die Datei pppd mal genauer an:

$ ls -l /usr/sbin/pppd
-rwsr-xr-- 1 root dip 277352 2009-02-20 18:25 /usr/sbin/pppd

Das Programm kann nur von root oder einem Mitglied der Gruppe dip gestartet werden – und das bin ich „normalerweise“ nicht. Der Grund, weshalb UMTSmon keine Informationen von ppp erhält ist, dass das pppd mangels fehlender Rechte nicht gestartet wurde.

Wo ist dip?

Natürlich könnte man UMTSmon einfach mit root-Rechten aufrufen, aber das gehört sich nicht. Die einfachste Variante zum Mitglied der Gruppe dip zu werden ist der Befehl:

sudo adduser user_name dip

Der Versuch dies über die GUI (System – Systemverwaltung – Benutzer und Gruppen) zu erledigen läuft zunächst ins Leere. Ruft man nach dem „Entsperren“ den Punkt „Gruppen verwalten“ auf, so sucht man dort die Gruppe dip vergebens. Diese Gruppe versteckt sich bei den Benutzerrechten.

Also: Benutzer anklicken – Eigenschaften – Benutzerrechte – „Internet-Verbindung mit Modem aufbauen“ ankreuzen.

Eigentlich logisch – aber das muss man wirklich erst einmal wissen. Die Option „Modems verwenden“ muss ebenfalls aktiv sein, was sie jedoch standardmäßig ist. Sie macht einem zum Mitglied der Gruppe dialout.

Dann muss man sich erst einmal ab- und wieder anmelden, bevor diese neue Einstellung aktiv ist. Ein Neustart ist jedoch nicht nötig.

Ein neuer Versuch

Der nächste Versuch, ins Internet zu kommen, scheiterte auch. Diesmal war die Fehlermeldung (stdout) etwas umfangreicher. Hier ein gekürzter Ausschnitt:

pppd options in effect:
debug debug debug # (from command line)
...
/dev/ttyUSB1 # (from command line)
460800 # (from command line)
lock # (from command line)
crtscts # (from command line)
...
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB1
...
LCP: timeout sending Config-Requests
Connection terminated.
Receive serial link is not 8-bit clean:
Problem: all had bit 7 set to 0
Modem hangup

Im Rahmen der Fehlersuche hatte ich mit dmesg das Boot-Protokoll abgefragt. Dort findet man u.a.:

[ 11.424602] USB Serial support registered for GSM modem (1-port)
[ 11.424737] option 2-2:1.0: GSM modem (1-port) converter detected
[ 11.425007] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 11.425071] option 2-2:1.1: GSM modem (1-port) converter detected
[ 11.425322] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 11.425405] usbcore: registered new interface driver option
[ 11.425452] option: v0.7.2:USB Driver for GSM modems

Hier ist zu erkennen, dass der Kernel für das Modem zwei serielle Devices einrichtet: /dev/ttyUSB0 und /dev/ttyUSB1

Startet man umtsmon mit den Optionen -v4 und --force-autodetect kann man schön verfolgen, wie

• zunächst das Modem als solches erkannt wird
• die beiden seriellen Devices gefunden und
• nacheinander getestet werden (ein Modem antwortet auf „AT“ mit „OK“)
• und dann sowohl für die AT-Befehle als auch für die PPP-Verbindung /dev/ttyUSB1 ausgewählt wird.

Hier die interessanten Ausgaben:

##P3 t=372: Start iterating through all AutoDetectors
…
##P3 t=372: Let's continue with the next AutoDetector

##P3 t=372: AutoDetectBase::go() for 'USB ZeroCD Autodetection'
##P3 t=372: AutoDetect_USB::traverseTrees()
##P4 t=372: Checking USB device on 001:006
##P3 t=372: AutoDetect_USB::matchIDs(0x12d1, 0x1003)
##P3 t=372: This is a known ZeroCD Device: "Huawei E220 / E800"
##P3 t=372: AutoDetect_USB_ZeroCD::findPortNames()
##P3 t=372: AutoDetect_USB::findPortNames()
##P4 t=372: looking for ttyUSB ports
##P4 t=372: Found serial port number 1 with name 'ttyUSB0'
##P4 t=372: Found serial port number 2 with name 'ttyUSB1'
##P3 t=372: INFO: 'There are 2 ports available'
…
##P3 t=372: AutoDetect_USB::traverseTrees()
##P4 t=372: Checking USB device on 001:006
##P3 t=372: AutoDetect_USB::matchIDs(0x12d1, 0x1003)
##P2 t=372: GOOD: 'A 'Huawei E220 / E800' modem detected'
##P3 t=372: AutoDetect_USB::findPortNames()
##P4 t=372: looking for ttyUSB ports
##P4 t=372: Found serial port number 1 with name 'ttyUSB0'
##P4 t=372: Found serial port number 2 with name 'ttyUSB1'
##P3 t=372: INFO: 'There are 2 ports available'
...
##P3 t=372: Device: probing port '/dev/ttyUSB0' for AT commands
##P3 t=372: TempSerialPort::TempSerialPort()
##P3 t=372: Serial::openDev('/dev/ttyUSB0') as FD 7 - Serial instance 0xbfa4eec0
##P4 t=372: Query sends the following mesage: 'AT'
##P2 t=372: Device port '/dev/ttyUSB0': no response to "AT", return code 5
##P3 t=372: Device: probing port '/dev/ttyUSB0' failed
##P3 t=372: TempSerialPort::~TempSerialPort()
##P3 t=372: SerialPort::closeDev() for FD 7
##P3 t=372: Device: probing port '/dev/ttyUSB1' for AT commands
##P3 t=372: TempSerialPort::TempSerialPort()
##P3 t=372: Serial::openDev('/dev/ttyUSB1') as FD 7 - Serial instance 0xbfa4eec0
##P4 t=372: Query sends the following mesage: 'AT'
##P4 t=372: answer 1:'AT'
##P4 t=372: answer 2:'OK'
##P3 t=372: Got Query::OK from port
##P3 t=372: Device: probing port '/dev/ttyUSB1' successful
…
##P3 t=372: TempSerialPort::~TempSerialPort()
##P3 t=372: SerialPort::closeDev() for FD 7
##P3 t=372: set AT serial to '/dev/ttyUSB1'
##P3 t=372: set PPP serial to '/dev/ttyUSB1'
##P3 t=373: Serial::openDev('/dev/ttyUSB1') as FD 7 - Serial instance 0x9ff3b70
##P2 t=373: GOOD: 'Device created successfully'
##P1 t=373: Found hardware configuration stored to disk
##P3 t=373: TheDeviceManagerSingleton::writeToConfigFile()
##P3 t=373: Everything done - device created

Könnte es also sein, dass man für die PPP-Verbindung /dev/ttyUSB0 statt 1 verwenden sollte? Die entsprechende Option beim Aufruf lautet:

umtsmon -s/dev/ttyUSB1,/dev/ttyUSB0

Und siehe da... Internet!

Damit man dies nicht andauernd eingeben muss, kann man es auch in der Konfiguration von UMTSmon dauerhaft ändern (zu finden unter ~/.umtsmon/umtsmonrc):

[device]
ATPortName=/dev/ttyUSB1
PPPPortName=/dev/ttyUSB0

Happy surfing.