natty1
Anmeldungsdatum: 11. Juli 2011
Beiträge: 122
|
Hallo, ich wollte unter 12.04 einmal umtsmon ausprobieren. Ist das ein sinnloses Unterfangen oder gibt es jemand der unter 12.04 das schon geschafft hat ? Der Stick ist immer noch ident mit diesem Beitrag hier: http://forum.ubuntuusers.de/topic/internetstick-funktioniert-nicht/ Bei meinem Versuch ist es so: Der Stick wird erkannt. Wenn man die Verbindung aufbaut, kommt eine Fehlermeldung: Using interface ppp0
Connect: ppp0 <--> /dev//ttyUSB0
CHAP authentication succeeded
CHAP authentication succeeded
Could not determine remote IP address: defaulting to 10.64.64.64
local IP address 10.60.75.200
remote IP address 10.64.64.64
primary DNS address 194.48.139.254
secondary DNS address 194.48.124.200 Der Stick leuchtet so, als wär ich damit im Internet. Trotzdem funktioniert der Zugriff aufs Internet irgendwie nicht. Bin für jede Hilfe dankbar.
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
Hallo natty1, Ist das ein sinnloses Unterfangen oder gibt es jemand der unter 12.04 das schon geschafft hat ?
da hast du etwas Glück mit dem Zeitpunkt deiner Anfrage. Erst vor kurzem habe ich das Problem, das UMTSmon mit neueren Ubuntuversionen wie 12.04 hat, lokalisieren können und UMTSmon lauffähig bekommen. UMTSmon ist mit dem Programm pppd aus dem Paket ppp nicht mehr kompatibel. Version 2.4.5-5ubuntu1 funktioniert nicht mehr, bei Version 2.4.5~git20081126t100229-0ubuntu3 ging es noch. Ich hab mir daher diese Version von hier geholt, dieses Paket entpackt (nicht installiert, weil sonst Abhängigkeiten zerstört werden) und nur die Datei pppd ins Verzeichnis /sbin gestellt. Dort wird sie vor der installierten Datei pppd verwendet, die sich unter /usr/sbin befindet. Für die 64-Bit-Version wären dies die Befehle fürs Terminal dazu, bei 32-Bit einfach "amd64" durch "i386" ersetzen.
wget http://de.archive.ubuntu.com/ubuntu/pool/main/p/ppp/ppp_2.4.5~git20081126t100229-0ubuntu3_amd64.deb
sudo dpkg -x ppp_2.4.5~git20081126t100229-0ubuntu3_amd64.deb /tmp/ppp
sudo mv /tmp/ppp/usr/sbin/pppd /sbin/pppd
Für den Notfall: Deinstallation geht mit:
sudo rm /sbin/pppd
❗ Achtung! Auch, wenn die Standard-Ubuntuprogramme bei mir auch mit der alten Version von pppd funktioniert haben, kann ich natürlich nicht garantieren, dass es durch Inkompatibiltäten doch zu einem instabilen System kommt. edit: Generell ist es aber trotzdem so, dass UMTSmon aufgrund der fehlenden Weiterentwicklung, nicht mehr empfehlenswert ist.
|
natty1
(Themenstarter)
Anmeldungsdatum: 11. Juli 2011
Beiträge: 122
|
Danke, dein Lösungsvorschlag hat bei mir funktioniert. Trotzdem die Frage: Gibt es vielleicht irgendwo ein .deb-Paket für Ubuntu, wo man diesen "Übertrick" nicht anwenden muss ?
So ganz "sauber" scheint es ja nicht zu sein: ❗ Achtung! Auch, wenn die Standard-Ubuntuprogramme bei mir auch mit der alten Version von pppd funktioniert haben, kann ich natürlich nicht garantieren, dass es durch Inkompatibiltäten doch zu einem instabilen System kommt.
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
hakunamatata schrieb: Version 2.4.5-5ubuntu1 funktioniert nicht mehr, bei Version 2.4.5~git20081126t100229-0ubuntu3 ging es noch.
Hast Du zufällig eine Spur, welche Änderung die Ursache sein könnte?
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
natty1 schrieb: Gibt es vielleicht irgendwo ein .deb-Paket für Ubuntu, wo man diesen "Übertrick" nicht anwenden muss ?
Möglich wäre es, aber zentral erstellte deb-Pakete für Ubuntu gibt es meines Wissens nicht und bei den deb-Paketen, die ich probiert habe, gab es das von dir geschilderte Problem. So ganz "sauber" scheint es ja nicht zu sein:
Die "sauberste" Lösung wäre die Inkompatibilität in UMTSmon zu beseitigen und aus dem Sourcecode selbst ein Paket zu bauen. Die Frage ist nur wie sinnvoll es ist, ein Programm, das auch sonst nicht mehr weiterentwickelt wird so am Leben zu erhalten, wenn es eine Reihe von Alternativprogrammen gibt. fredl99 schrieb: Hast Du zufällig eine Spur, welche Änderung die Ursache sein könnte?
IMHO wird ab 2.4.5-5ubuntu1 ein Child-Prozess erstellt, mit dem UMTSmon nicht klar kommt. UMTSmon erkennt, dass der Child-Prozess beendet wurde, wundert sich aber, dass noch ein Prozess (wahrscheinlich der Parent-Prozess) läuft und sieht das als Fehler. Kommentar im Sourcecode von UMTSmon unter src/model/pppConnection.cpp an dieser Stelle: // euh? finished *and* still running?
// that means we have a zombie
// - process is dead, we have to reap it...
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
Hmm,
da bin ich mir nicht sicher. Nach dem Log, daß uns der TE hier gepostet hat, meint der (neue) pppd daß das Modem aufgelegt hat und räumt wieder alles weg. Und zwar, nachdem er bereits IP, DNS, usw. erhalten hat, aber noch bevor er sich abklemmt und an umtsmon übergibt. Ich bin also nicht sicher, ob umtsmon da tatsächlich etwas dafür kann.
Man müsste das einmal mit einem manuellen Aufruf des pppd mit den gleichen Optionen ausprobieren.
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
fredl99 schrieb: Und zwar, nachdem er bereits IP, DNS, usw. erhalten hat, aber noch bevor er sich abklemmt und an umtsmon übergibt.
Nur mit dem gelieferten Log würde ich dir auf jeden Fall zustimmen. Bei den Logs von UMTSmon aus meinen Versuchen, sind aber noch andere Unterschiede zwischen alten und neuen pppd sichtbar, die ich auch beim TE vermute. Im neuen pppd gehört die PID des ersten protokollierten Prozesses einem Child-Prozess, während beim alten pppd diese PID dem Parent-Prozess gehört. d.h.: der neue pppd lagert den ersten Teil in einen Child-Prozess aus. Den Status dieses Prozesses prüft UMTSmon aktiv in regelmäßigen Zeitintervallen. Meint UMTSmon, dass dieser Prozess beendet ist, startet es die Folgeschritte. Meine Vermutung ist, dass UMTSmon bereits zwischen diesen Zeilen fortfährt, weil der Child-Prozess (beim TE mit PID 2050) hier bereits zu Ende ist, während dies bei einem Parent-Prozess nicht der Fall ist: /var/log/syslog:Jul 14 22:53:34 ubuntu pppd[2050]: secondary DNS address 194.48.124.200
/var/log/syslog:Jul 14 22:53:34 ubuntu pppd[2056]: Script /etc/ppp/ip-up started (pid 2057)
Und in der Folgeverarbeitung dann bemerkt wird, dass doch noch ein Prozess aktiv ist, aber die Fehlerbehandlung darin besteht, noch aktive pppd-Prozesse zu beenden. Wohl oder übel muss ich jetzt wohl diese Theorie in der Praxis überprüfen 😕 . Sourcecode von UMTSmon ändern, kompilieren und nachsehen, ob das den Fehler beseitigt. Ich hoffe nur, dass der TE auch so viel Interesse an der lückenlosen Aufklärung hat, der Thread ist ja schon auf gelöst gesetzt. edit: Zwischenergebnis: So ganz stimmig ist meine Vermutung nach Tests mit Änderungen im Sourcecode leider nicht; damit wird es doch umfangreicher. 😢
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
hakunamatata schrieb:
Meine Vermutung ist, dass UMTSmon bereits zwischen diesen Zeilen fortfährt, weil der Child-Prozess (beim TE mit PID 2050) hier bereits zu Ende ist, während dies bei einem Parent-Prozess nicht der Fall ist: /var/log/syslog:Jul 14 22:53:34 ubuntu pppd[2050]: secondary DNS address 194.48.124.200
/var/log/syslog:Jul 14 22:53:34 ubuntu pppd[2056]: Script /etc/ppp/ip-up started (pid 2057)
Das gleiche Bild zeigt er aber mit der alten Versin auch:
/var/log/syslog:Jul 14 23:00:57 ubuntu pppd[2181]: secondary DNS address 194.48.124.200
/var/log/syslog:Jul 14 23:00:57 ubuntu pppd[2184]: Script /etc/ppp/ip-up started (pid 2185)
Da stört's den umtsmon scheinbar aber nicht. Oder hab ich etwas übersehen? Muss allerdings zugeben, daß ich den umtsmon selbst nicht probiert habe und daher dessen zugehörige Logs nicht kenne.
Aus dem vorliegenden Log vermute ich aber, daß der neue pppd aus irgendeinem Grund ein Auflegen/Verschwinden des Modems zu erkennen glaubt und entsprechend reagiert. Das könnte ein Bug/Feature dieser Version sein oder eine anders interpretierte Einstellung in /etc/ppp/options. Und da ginge mein Verdacht in Richtung "lcp-echo-failure". Deshalb wäre mein Vorschlag auch gewesen, anstatt Sourcecode von UMTSmon ändern, kompilieren und nachsehen
Erstmal den neuen pppd manuell mit den gleichen Optionen (wie von umtsmon übergeben) aufrufen und als Gegenprobe diese Option herauszunehmen. Vielleicht bekommst Du das schneller hin, als ich es dem TE erklärt habe...
Ich hoffe nur, dass der TE auch so viel Interesse an der lückenlosen Aufklärung hat, der Thread ist ja schon auf gelöst gesetzt.
Im anderen Forum wäre das eher ein "erledigt", da das Problem nicht gelöst sondern umgangen wird. Aber siehst Du das etwa nicht auch ein wenig sportlich? 😊
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
fredl99 schrieb: Und da ginge mein Verdacht in Richtung "lcp-echo-failure".
Ich habe es nochmals ausprobiert, diese Option in alle möglichen Richtungen zu ändern. Weglassen, den Wert von
lcp-echo-failure 4 erhöhen oder verkleinern, leider alles negativ. Wobei ich bevor ich noch festgestellt habe, dass die alte Version von pppd funktioniert, schon sehr viele Änderungen in der /etc/ppp/options erfolglos getestet habe. Die lcp-Optionen hatte ich auch schon in Verdacht. Darum habe ich mich einmal auf UMTSmon konzentriert, der Teil des UMTSmon-Logs, der nur bei der neuen pppd-Version ausgegeben wird, schien mir ein guter Einstiegspunkt:
##P5 t=549: Runner::runCommand(1, list[25 items], 0)
##P3 t=549: INSIDE CHILD, uid=1000, pid=3231
##P5 t=549: INSIDE CHILD, Prog: /usr/sbin/pppd
##P5 t=549: INSIDE CHILD, arg00: 'idle'
##P5 t=549: INSIDE CHILD, arg01: '7200'
##P5 t=549: INSIDE CHILD, arg02: 'asyncmap'
##P5 t=549: INSIDE CHILD, arg03: '0'
##P5 t=549: INSIDE CHILD, arg04: 'updetach'
##P5 t=549: INSIDE CHILD, arg05: 'dump'
##P5 t=549: INSIDE CHILD, arg06: 'debug'
##P5 t=549: INSIDE CHILD, arg07: 'debug'
##P5 t=549: INSIDE CHILD, arg08: 'debug'
##P5 t=549: INSIDE CHILD, arg09: '460800'
##P5 t=549: INSIDE CHILD, arg10: 'lock'
##P5 t=549: INSIDE CHILD, arg11: 'crtscts'
##P5 t=549: INSIDE CHILD, arg12: 'modem'
##P5 t=549: INSIDE CHILD, arg13: '/dev//ttyUSB2'
##P5 t=549: INSIDE CHILD, arg14: 'noipx'
##P5 t=549: INSIDE CHILD, arg15: 'novj'
##P5 t=549: INSIDE CHILD, arg16: 'nobsdcomp'
##P5 t=549: INSIDE CHILD, arg17: 'noccp'
##P5 t=549: INSIDE CHILD, arg18: 'defaultroute'
##P5 t=549: INSIDE CHILD, arg19: 'replacedef9f98 acquired MUTEX
##P4 t=546: Query sends the following mesage: 'AT+COPS?'
...und wollte klären:
Warum wird dieser Teil nur bei der neuen pppd-Version aufgerufen/ausgegeben ? Warum bricht die Ausgabe mitten in "replacedefaultroute" ab und ein zeitlich vorher erstelltes Log (t=546 statt t=549) wird angefügt ?
Deshalb wäre mein Vorschlag auch gewesen, anstatt Sourcecode von UMTSmon ändern, kompilieren und nachsehen
Erstmal den neuen pppd manuell mit den gleichen Optionen (wie von umtsmon übergeben) aufrufen und als Gegenprobe diese Option herauszunehmen. Vielleicht bekommst Du das schneller hin, als ich es dem TE erklärt habe...
Werde ich noch machen. Zur Info, diesen Optionen werden bei mir von pppd verwendet. Die von UMTSmon sind als "from command line" ausgewiesen. Im Fehlerfall wird das im Nachhinein von der pppd-Ausgabe ins UMTSmon-Log übernommen:
##P4 t=552: * pppd options in effect:
##P4 t=552: * debug debug debug # (from command line)
##P4 t=552: * updetach # (from command line)
##P4 t=552: * idle 7200 # (from command line)
##P4 t=552: * dump # (from command line)
##P4 t=552: * noauth # (from /etc/ppp/options)
##P4 t=552: * user egal # (from command line)
##P4 t=552: * password ?????? # (from command line)
##P4 t=552: * /dev//ttyUSB2 # (from command line)
##P4 t=552: * 460800 # (from command line)
##P4 t=552: * lock # (from command line)
##P4 t=552: * crtscts # (from command line)
##P4 t=552: * modem # (from command line)
##P4 t=552: * asyncmap 0 # (from command line)
##P4 t=552: * lcp-echo-failure 4 # (from /etc/ppp/options)
##P4 t=552: * lcp-echo-interval 30 # (from /etc/ppp/options)
##P4 t=552: * hide-password # (from /etc/ppp/options)
##P4 t=552: * novj # (from command line)
##P4 t=552: * defaultroute # (from command line)
##P4 t=552: * replacedefaultroute # (from command line)
##P4 t=552: * usepeerdns # (from command line)
##P4 t=552: * noccp # (from command line)
##P4 t=552: * nobsdcomp # (from command line)
##P4 t=552: * noipx # (from command line) Aber siehst Du das etwa nicht auch ein wenig sportlich? 😊
Natürlich. 😉
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
Erstmal den neuen pppd manuell mit den gleichen Optionen (wie von umtsmon übergeben) aufrufen
In der einfachsten Variante gemacht:
echo -e 'ATD*99***1#\r' > /dev/ttyUSB2
pppd idle 7200 asyncmap 0 updetach dump debug debug debug 460800 lock crtscts modem /dev//ttyUSB2 noipx novj nobsdcomp noccp defaultroute replacedefaultroute usepeerdns user egal password egal
Was soll ich sagen? Funktioniert.
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
Lustig. Und wie sieht da die entsprechende Stelle im Log aus? Werden die Scripts in ip-up abgearbeitet? Bleibt das Modem Online und wurde die Route gesetzt? Wahrscheinlich, oder? Es gibt noch einen Unterschied in der default-Konfiguration zwischen altem und neuem pppd. Hat zwar auf den ersten Blick nichts damit zu tun, aber früher wurde proxy-arp gesetzt und jetzt nicht mehr (oder umgekehrt, weiß jetzt nicht). Die Konfig wird zwar von beiden eingelesen, aber vielleicht kommt einer der beiden dabei aus dem Tritt. Und irgendwo in den Changelogs steht was davon, daß "auth" jetzt default wäre. Allerdings steht ja in der options "noauth" drinnen und hätte vordergründig wieder nichts damit zu tun, zumal beim TE ja vorher nicht einmal eine default-Route vorhanden ist so daß das zur Anwendung käme.
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
fredl99 schrieb: Lustig.
Du sagst es. Und wie sieht da die entsprechende Stelle im Log aus? Werden die Scripts in ip-up abgearbeitet?
/var/log/syslog sieht genauso aus wie bei UMTSmon, abgesehen von der Meldung, dass das Modem auflegt. ip-up wird abgearbeitet. Bleibt das Modem Online und wurde die Route gesetzt? Wahrscheinlich, oder?
Ja, das Modem bleibt online. Route ist gesetzt. Der Zugriff aufs Internet funktioniert problemlos.
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
Hmm, Ich werde mir doch auch einen Versuchsaufbau mit umtsmon machen, um beide Seiten zu sehen. Vielleicht können wir das Rätsel gemeinsam knacken. Seltsam ist das ja schon irgendwie. Welches Modem hast Du dazu verwendet?
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
Welches Modem hast Du dazu verwendet?
Ein ZTE MF 112. edit: Da der TE ein Huawei E1552 hat, scheint das aber nur für den PPP-Port (Huawei immer /dev/ttyUSB0, während ZTE meist die Schnittstelle mit der höchsten Nummer - bei mr /dev/ttyUSB2) relevant.
|
fredl99
Anmeldungsdatum: 27. Juli 2008
Beiträge: 34
|
Ich habe ein E220 zum Testen, also zumindest Marke und Port kommen näher ☺ Werde das die Tage in Angriff nehmen und berichten...
|