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:
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()).
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. ...
pop :-)
Wie stellst Du denn die Handshake-Leitungen zum Modem ein?
Dass ein Terminalprogramm funktioniert, Dein Code aber nicht, lässt mich
das vermuten...
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 :/
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.
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).
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...
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.
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.
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.
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"