Linux- UMTS Einwahlscript

[Niklas G. (erlkoenig)]

Liebes Forum,
in meinem Besitz befindet sich ein Huawei E160 USB-Mobilfunk-Modem, 
welches ich gerne unter Linux nutzen würde. Dazu gibt es ja bereits 
vorgefertigte Möglichkeiten wie wvdial oder umtsmon. umtsmon will bei 
mir gar nicht, wvdial funktioniert prinzipiell auch, aber nur bei gutem 
Empfang - sobald die PIN gesendet wurde (mittels des AT+CPIN -Befehls), 
verbindet sich das Modem sehr schnell mit dem Netz, sodass der folgende 
"ATDT"-Befehl an das Modem funktioniert und die Verbindung aufgebaut 
werden kann.
Ich sitze jedoch momentan mehr oder weniger auf einem Berg fest mit sehr 
schlechtem Empfang. Nach der PIN-Eingabe braucht das Modem ca. eine 
halbe Minute bis es sich verbunden hat - erkennbar daran, dass der 
AT+CSQ -Befehl zur Abfrage der Signalstärke sinnvolle Werte liefert - 
und dann noch einige Sekunden, bis der AT+COPS? -Befehl einen 
Netzbetreiber anzeigt. Erst dann funktioniert der Einwahl-Befehl ATDT. 
Führt man den Befehl vorher aus, schlägt er immer mit "NO CARRIER" fehl. 
Daher habe ich mir ein eigenes Einwahl-Script in ruby (siehe Anhang) 
gebastelt, welches so etwas wie ein "intelligenter" Ersatz für das zu 
PPPD gehörende chat speziell für Mobilfunk-Modems werden sollte. Wenn 
ich dieses Script von PPPD aus starten lasse - genau wie das 
Original-chat - sollte es ja über stdin/stdout mit dem Modem 
kommunizieren können. Das funktioniert jedoch aus mysteriösen Gründen 
nicht, es kommen keine Antworten vom Modem bei meinem Programm an. Im 
Sourcecode des chat-Programms konnte ich keine magischen Befehle 
ausmachen, die nötig sind, um die Kommunikation zu ermöglichen. Daher 
habe ich die Hierarchie umgekehrt - mein Script öffnet direkt das 
Modem-Device (wie /dev/ttyUSB0), führt die Initialisierungs-Sequenz 
durch, wartet darauf dass ein gültiger Signalpegel sowie der 
Netzbetreiber angezeigt werden und startet dann PPPD. Der Signalpegel 
und der Netzbetreiber werden ausgegeben, sodass ich ggf. die Antenne 
justieren kann, falls der Empfang zu schlecht ist. Das funktioniert 
sogar (staun), hat aber noch ein Problem: Wird die Verbindung beendet 
(z.B. durch von Wurmlöchern verursachte Strahlung, die bewirkt, dass 
plötzlich kein Signal mehr empfangen wird, dafür aber an anderer Stelle, 
wo vorher kein Empfang war, oder durch manuelles Töten des 
PPPD-Prozesses) und wird danach das Script erneut gestartet, bekommt es 
keine Antworten mehr vom Modem - der read-Aufruf blockt ewig. Das 
seltsame ist, dass ich dann mit gtkterm ganz problemlos mit dem Modem 
"reden" kann - das ruby-Script aber nicht mehr, auch nicht nachdem ich 
mit gtkterm erfolgreich das Modem ansprechen konnte! Selbst 
Neu-anschließen des Modems bringt nichts, nur ein Komplett-reboot bringt 
es wieder zum funktionieren. Der Sourcecode von gtkterm sieht auch ganz 
"normal" aus (bis auf die französischen Funktionsnamen...), ich konnte 
keine "magischen" Funktionen finden, die offenbar die Kommunikation 
ermöglichen.
ruby selbst ist aber offenbar auch nicht schuld - mit C geht's auch 
nicht:

int fd = open ("/dev/ttyUSB0", O_APPEND | O_NOCTTY | O_RDWR);
// Klappt weder mit einkommentiert noch auskommentiert
/*      struct termios t;
        t.c_iflag = IGNBRK | IGNPAR;
        t.c_oflag = 0;
        t.c_cflag = CS8 | CREAD | CLOCAL;
        t.c_lflag = 0;
        t.c_cc[VMIN] = 1;
        t.c_cc[VTIME] = 100;
        cfsetospeed (&t, B115200);
        cfsetispeed (&t, B115200);
        int r = tcsetattr (fd, TCSANOW, &t);
        if (r == -1) { 
                printf("tcsetattr err: %s\n", strerror (errno));
                return 1;
        } */
        write (fd, "ATE0\n", 5);
        char buf [20];
        // Blockt ewig
        r = read (fd, &buf, 10);

Hat hier irgendjemand einen Schimmer, woran das liegen könnte? So 
langsam gehen mir die Ideen aus...
Den Source-Code der von mir verwendeten gtkterm-Version gibts z.B. hier: 
http://distfiles.gentoo.org/distfiles/gtkterm-0.99.5.tar.gz

[Klaus W. (mfgkw)]

also weder habe ich von ruby einen Schimmer, noch warum dein
C-Programm nicht geht.

Vielleicht wäre es aber hilfreicher, mal zu sehen, WAS nicht geht
als nur zu hören daß es nicht geht.
Z.B. liefert in deinem C-Program open() ggf. einen Fehler (-1),
ebenso wie read() und write(). Dann kann man mit errno jeweils
sehen, was schief gelaufen ist (perror(), strerror()).

[Niklas G. (erlkoenig)]

Ich zitiere mich jetzt mal selbst:
Niklas Gürtler schrieb:
> ... und wird danach das Script erneut gestartet, bekommt es
> keine Antworten mehr vom Modem - der read-Aufruf blockt ewig. ...

         // Blockt ewig
         r = read (fd, &buf, 10);

[Niklas G. (erlkoenig)]

push

[Gerry E. (micky01)]

pop :-)

Wie stellst Du denn die Handshake-Leitungen zum Modem ein?
Dass ein Terminalprogramm funktioniert, Dein Code aber nicht, lässt mich 
das vermuten...

[Niklas G. (erlkoenig)]

Das Terminal-Programm gtkterm lässt die Leitungen einfach auf Low, und 
es geht. Mein Script macht da gar nichts, ich hab aber mal in einem 
Test-C-Programm die Leitungen abgefragt (mit "ioctl (fd, TIOCMGET, 
&...);"), sie sind sowohl vor als auch nach der Einwahl mit PPPD auf 
Low, und auch wenn ich einmal mit gtkterm erfolgreich mit dem Modem 
kommuniziert habe während mein ruby-Script und C-Test-Programm dauerhaft 
blockt. Verstehe nicht, woran das liegt :/

[faustian (Gast)]

Also mit dem MC950D hab ich schon die Erfahrung gemacht dass man ein 
neues Modem erst ein mal mit der Windows Software vom Provider 
einwaehlen muss bevor es dann fuer immer mit "normalen" Skripten 
geht.... evtl ist das hier auch so.

[Gerry E. (micky01)]

Niklas, Du sagtest nach einem Rechnerneustart geht es wieder.
Irgendwas stimmt da ja wohl nicht. Hast Du es mal mit einer richtigen 
RS232 probiert? Ich habe den leisen Verdacht, dass der "Converter" ein 
kleines Problem darstellt (muss allerdings nicht sein).

[Niklas G. (erlkoenig)]

Habs mit Windows schon gemacht, da kann man sich problemlos zig mal 
hintereinander einwählen, aber unter Linux eben nicht...
Das ganze Konzept der RS232-Emulation ist ein Problem ;) Der Konverter 
ist allerdings auf dem Modem eingebaut, an die RS232-Drähte komm ich so 
nicht dran, falls sie denn überhaupt existieren, vermutlich hat's da 
einen einzelnen Chip/uC der die Emulation macht, und die RS232-Daten 
direkt verarbeitet, also sodass der RS232 nur in Software und virtuell 
existiert...

[Gerry E. (micky01)]

Niklas Gürtler schrieb:
> Habs mit Windows schon gemacht, da kann man sich problemlos zig mal
> hintereinander einwählen, aber unter Linux eben nicht...

Das sieht ja zuerst nach einem Treiberproblem aus. Was mich aber dennoch 
wundert ist Deine Aussage, dass es mit dem Terminalprogramm dann doch 
geht. Komisch.

Bei Programmen, die RS232 nutzen, gehe ich so vor:
1) Ich öffne die Schnittstelle mit open,
2) dann setze ich die Parameter,
3) dann kann ich lesen und schreiben.

Der mittlere Schritt ist wichtig, denn Du hast eventuell einen anderen 
Prozess laufen, der Dir garnicht bewusst ist, und der ebenfalls auf der 
Schnittstelle rumturnt. Unter Windows kommt das eher selten von, aber 
unter Linux gibt es zB getty. Schau mal zB in /etc/inittab nach.

[Niklas G. (erlkoenig)]

Die Parameter zu setzen war eigentlich nie notwendig, da es die RxD/TxD 
-Leitungen gar nicht gibt, sind Baudrate und Frame-Format eh egal. Also 
nach anschließen des Sticks kann ich den direkt sofort und ohne 
Parameter zu setzen einwählen, nur eben nicht mehrfach. Außerdem müssten 
die Einstellungen ja richtig sein, da es mit gtkterm ja geht.
In der inittab steht nichts von getty für das /dev/ttyUSB0, sollte da 
also nicht reinpfuschen, und da ich gentoo verwende, sind da auch, 
meines Wissens, keine Klicki-Bunti-Hotplug-Auto-Erkennungs-Programme die 
da rumwurschteln, wie man das schonmal unter Ubuntu oder so hat.

[Gerry E. (micky01)]

Seltsam ist es schon, momentan fällt mir leider auch nichts weiter dazu 
ein.
Außer dass vielleicht der Treiber noch nicht ganz ausgereift ist.
Also wenn der selbe Code unter Windows funktioniert, unter Linux aber 
nicht, so will das ja erstmal nichts heißen, da die APIs sich ja schon 
unterscheiden. Hmm....

Vielleicht wäre es dann doch angebracht wenn Du etwas Code postest?
Also der funktionierende und der, der es nicht tut.

[Niklas G. (erlkoenig)]

Das ruby-Script ist beim ersten Posting angehängt, und unten im selbigen 
befindet sich ein Link zum Sourcecode des funktionierenden 
gtkterm-Codes. Unter Windows verwende ich kein eigenes Script, sondern 
das in Windows eingebaute Einwählprogramm "DFÜ-Verbindung"

[Gerry E. (micky01)]

Was sagt denn

setserial -a /dev/ttyUSB0