'ip-config-unavailable' Fehler, wenn das USB-Modem versucht, eine Verbindung herzustellen

Ich habe ein ZTE MF-193E-Modem, das zuvor einwandfrei funktioniert hat. Als ich dieses Modem vor mehr als einem Jahr gekauft habe, hat es sofort funktioniert. Jetzt, da Ubuntu Fortschritte in der Version macht, werden die Dinge für mich immer schwieriger.

Dieses Modem hat vor einigen Monaten sogar mit Ubuntu 15.04 (64-Bit) funktioniert. In Ubuntu 15.10 (64-Bit) kann keine Verbindung hergestellt werden.

Ich habe eine mobile Breitbandverbindung eingerichtet . Ich habe verschiedene Zeichenfolgen für APN ausprobiert, aber dies war bisher kein Problem.

(Das Modem funktioniert in Windows 10 einwandfrei , es handelt sich also überhaupt nicht um ein Hardwareproblem. Außerdem erkennt die grafische Benutzeroberfläche des Modem Managers dieses Gerät sehr gut. SMS können problemlos gesendet und empfangen werden.)

Wenn ich das Modem einsetze, wird es in Ordnung erkannt. In Unity wird ein CD-Symbol mit dem Namen des Modems angezeigt. Ein paar Sekunden später erhalte ich eine Nachrichtenbox

Mobile Broadband Network: you are registered on the home network

in der Nähe des Netzwerksymbols.

Wenn ich versuche, eine Verbindung herzustellen, startet das WLAN-Symbol im Netzwerkmanager-Applet diese Zentrifugalbewegungen, kann aber schließlich keine Verbindung herstellen. In einer Meldung wird darauf hingewiesen, dass ich offline bin.

Die Linie, von der ich isolieren könnte, /var/log/syslogist folgende:

NetworkManager[628]: <info>  (ttyUSB1): device state change: ip-config
> -> failed (reason 'ip-config-unavailable') [70 120 5]

Ich bin mir jedoch nicht sicher, ob dies der relevante ist.

Weitere Zeilen von /var/log/syslogfinden Sie hier .

Update 1 - 6. Dezember 2015

Wie von einem freundlichen Mitglied herausgestellt, versuchte das nf_conntrack_pptpModul Ansatz.

Führte die folgenden Befehle aus,

$ lsmod | grep nf_conntrack_pptp | wc -l
0

$ sudo modprobe nf_conntrack_pptp
lsmod | grep nf_conntrack_pptp
nf_conntrack_pptp      20480  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          106496  2 nf_conntrack_proto_gre,nf_conntrack_pptp

Dann versuchte mein Modem den gleichen Fehler. Auch keine erkennbare Änderung im Protokoll.

Update 2 - 6. Dezember 2015

Als root ausgeführt,

systemctl restart network-manager.service

Keine Ausgabe auf dem Bildschirm (Terminal).

Entsprechendes Protokoll vom oben genannten Punkt zu einem Verbindungsversuch über das Modem finden Sie hier .

Update 3 - 6. Dezember 2015

Installierte ofonound versuchte dann das Modem erneut.

Bitte sehen Sie das Protokoll hier .

Update 4 - 6. Dezember 2015

Wieder als root ausgeführt,

systemctl restart network-manager.service

Entsprechendes Protokoll vom oben genannten Punkt zu einem Verbindungsversuch über das Modem finden Sie hier .

Update 5 - 6. Dezember 2015

Alle "Verweigern" in "Zulassen" geändert /etc/dbus-1/system.d/nm-dispatcher.conf.

Es wurde versucht, eine Verbindung herzustellen. Kein Glück.

Einige Netzwerkverbindungen werden über eine Ethernet-Verbindung hergestellt und getrennt.

Gefolgt von sudo systemctl restart network-manager.service.

Modem ausstecken und einstecken.

Es wurde erneut versucht, eine Verbindung herzustellen. Verbindet nicht.

Das Protokoll ist hier .

Update 6 - 6. Dezember 2015

Hingerichtet

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

und

export NM_PPP_DEBUG=1
sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt

Konnte mm-test.pyaufgrund mehrerer Fehler nicht ausgeführt werden. Habe die Datei am angegebenen Ort gefunden. Ich habe dies von https://github.com/openshine/ModemManager/blob/master/test/mm-test.py erhalten .

Die obigen Befehle unterscheiden sich etwas von denen im Wiki.

Die Protokolldateien sind hier .

Update 7 - 7. Dezember 2015

Erneut ausgeführt (nach der vorgeschlagenen Änderung in /lib/udev/rules.d/40-usb_modeswitch.rulesund Neustart)

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

und

sudo NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --log-level=debug --no-daemon > /tmp/nm.log.txt

Das /var/log/syslogist auch dabei.

Die Protokolldateien sind hier .

Update 8 - 8. Dezember 2015

Die aktualisierten Protokolle finden Sie hier .

Update 9 - 8. Dezember 2015

Test 1

1. Dieses Mal bootete der Computer von einer Ubuntu 14.04 32-Bit-DVD. Sobald der Computer gestartet wurde, begann die Erfassung des MM-Protokolls.

2. Steckte das Modem ein. lsusbzeigten, dass es als 19d2: 1232-Gerät erkannt wurde, das auf ein 19d2: 2003-Gerät umgestellt werden muss. Da für die Installation von usb-modeswitch ein Neustart des Computers erforderlich ist (und daher die Installation für den DVD-Lauf verloren geht), habe ich eine benutzerdefinierte Switch-Datei erstellt und das Modem über die Befehlszeile ( sudo usb_modeswitch -I -c 19d2:2003) umgeschaltet .

3. Sobald die Umschaltung abgeschlossen war, wurde ich informiert, dass ich eingeschaltet war Mobile Broadband Networkund eine neue Breitbandverbindung im Menü des Netzwerkmanagers genehmigt wurde.

4. Ich habe die obige Verbindung wie gewohnt eingerichtet (APN-Name war kein Problem), und die Verbindung wurde automatisch hergestellt.

5. Ich habe das Modem getrennt und ausgeworfen.

6. Aufzeichnung des MM-Protokolls gestoppt.

Das vollständige MM-Protokoll und Syslog für den Sitzungsstart zum Auswerfen des Modems finden Sie hier .

Test 2

Der gleiche Test mit einer Ubuntu 14.04 64-Bit-DVD.

Die Protokolle finden Sie hier .

Update 10 - 9. Dezember 2015

Dieses Mal mit getestet wvdialund festgestellt, dass wenn wvdialals root ausgeführt wird, wir eine erfolgreiche Verbindung erhalten.

Das wvdialconf und log sowie das entsprechende syslog befinden sich hier

Primäre Vermutung: Die Situation könnte etwas mit der Benutzergruppe des entsprechenden Benutzers zu tun haben.

Aber wie hier angegeben ,

Bei all diesen Tools muss der Benutzer Mitglied der Gruppen "dip" und "dialout" sein, damit eine DFÜ-Verbindung hergestellt werden kann. Fügen Sie also alle Benutzer, die eine DFÜ-Verbindung herstellen sollen, in diese Gruppen ein.

Aber wie wir finden können,

$ groups masroor
masroor : masroor adm dialout cdrom sudo dip plugdev lpadmin sambashare family wireshark

Der Benutzer ist also bereits Mitglied der angegebenen Gruppen.

Nun, vielleicht läuft das Problem auf einen dieser Punkte hinaus,

1. Welche zusätzliche Gruppe muss der Benutzer sein?
2. Wie führen wir den Einrichtungsprozess für mobile Breitbandverbindungen als Root aus? (Sicherheitsprobleme?)

Update 11 - 9. Dezember 2015

wvdialfunktioniert mit USB3 und nicht mit USB1.

Den Syslog finden Sie hier .

Ebenfalls enthalten ist die Ausgabe von dmesg | grep tty > /tmp/dmesg.tty.txt. Aber sehen Sie diese vier Zeilen in der Nähe des Dateianfangs?

Update 12 - 10. Dezember 2015

1. Zeile 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") in auskommentiert /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Meine Maschine neu gestartet. Soft zog das Kabel ab und steckte das Modem ein.

3. Versucht, eine Verbindung herzustellen. Erfolglos.

Die Syslog-Datei ist hier .

Update 13 - 10. Dezember 2015

Aus purer Verzweiflung, um zu sehen, ob sich lokale Änderungen auf die Verbindung auswirken, testeten Sie den Computer mit Ubuntu 15.04- und 15.10-DVDs.

1. Bootete die Maschine mit Xubuntu 15.04 64-Bit-DVD. Die Verbindung war erfolgreich wie ein Zauber.
2. Bootete den Computer mit Ubuntu 15.10 64-Bit-DVD. Die Verbindung ist wie zuvor fehlgeschlagen.

Was ist zwischen 15.04 und 15.10 passiert?

So frustrierend.

Update 14 - 10. Dezember 2015

1. Erstellt eine neue Datei, /lib/udev/rules.d/78-mm-zte-port-types-RALPH.ruleswie in der Antwort angegeben.

2. Mein Computer wurde neu gestartet (oder ausgeführt sudo udevadm control --reload, tatsächlich beide ausprobiert). Steckte das Modem ein.

3. Das Modem wurde erkannt.

   $ lsusb
   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

4. Soft hat das Kabel abgezogen und versucht, über das Modem eine Verbindung herzustellen. Erfolglos.

5. Modem ausgeworfen.

Die Maschine hängt einmal, ist das ein zufälliges Ereignis? Meine Maschine hängt normalerweise nicht einmal im Jahr.

Die Syslog-Datei und die erstellten Regeldateien sind hier .

Update 15 - 11. Dezember 2015

1. Die folgenden Zeilen wurden hinzugefügt /lib/udev/rules.d/40-usb_modeswitch.rules.

   # ZTE MF193E
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
   

2. Lässt die Datei /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesintakt.

3. Meine Maschine neu gestartet. Steckte das Modem ein.

4. Das Modem wurde erkannt.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Soft hat das Kabel getrennt und versucht, eine Verbindung herzustellen. Erfolglos.

6. Modem ausgeworfen.

7. Entfernt /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.

8. Neustart und versuchte den gesamten Prozess erneut. Wieder erfolglos.

Die Syslog-Datei (vollständig, ich bin nicht das Risiko eingegangen, einen wichtigen Teil zu verpassen) und die erwähnte Regeldatei (40) sind hier .

Update 16 - 11. Dezember 2015

1. Lässt man nur eine 1232-Regel /lib/udev/rules.d/40-usb_modeswitch.rulesübrig, wird die andere entfernt.

2. Ausgeführt sudo udevadm control --reload.

3. Steckte das Modem ein.

4. Das Modem wurde erkannt.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Soft hat das Kabel getrennt und versucht, eine Verbindung herzustellen. Erfolglos.

6. Modem ausgeworfen.

Aber haben wir nicht das obige Standardsystem getestet? Wollten Sie an /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesseiner Stelle verlassen?

Die Syslog-Datei (vollständig, ich bin nicht das Risiko eingegangen, einen wichtigen Teil zu verpassen) und die erwähnte Regeldatei (40) sind hier

Update 17 - 11. Dezember 2015

1. Hat die 1232-Regel in /lib/udev/rules.d/40-usb_modeswitch.rulesauskommentiert und eine für 2003 hinzugefügt.

   # ZTE MFxxx
   # Added on December 11 2015
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
   

2. Ausgeführt sudo udevadm control --reload.

3. Steckte das Modem ein.

4. Das Modem wurde als 1232- Gerät erkannt . Es wird mir nicht angeboten, eine Verbindung herzustellen (soweit ich weiß, wird die Verbindung nicht im Breitbandnetz registriert, es sei denn, es wurde bis 2003 gewechselt).

   Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
   

5. Modem ausgeworfen.

Die Syslog-Datei und die erwähnte Regeldatei (40) sind hier

Update 18 - 11. Dezember 2015

1. Versetzen Sie alle Regeldateien in ihre ursprüngliche Form.

2. Überwachte lsusbAusgabe jede Sekunde mithilfe eines Shell-Skripts. Erfasste Ausgabe in Dateien mit Zeitstempel.

3. Steckte das Modem ein. (Das Modem erscheint zuerst in der Datei lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Wie wir den Aufnahmen entnehmen können, ist es klar, dass von einem 1232-Gerät auf ein 2003-Gerät umgeschaltet wird.

4. Versucht, eine Verbindung herzustellen. Erfolglos.

5. Modem ausgeworfen.

Die Syslog-Datei, die lsusbAusgaben mit Zeitstempel und die erwähnten Regeldateien sind hier .

Jetzt möchten Sie möglicherweise die Syslog-Ausgaben mit den Zeitstempeln abgleichen.

Update 19 - 11. Dezember 2015

Führen Sie diesen Test in einer völlig neuen Richtung mit dem Wunsch durch, dass ich die Probleme isolieren könnte.

1. Gespeichert in einem tragbaren Medium /lib/udev/rules.d/40-usb-media-players.rulesund /lib/udev/rules.d/77-mm-zte-port-types.rules(von der Ubuntu 15.10-Maschine).

2. Bootete den Computer mit einer 64-Bit-DVD von Xubuntu 15.04.

3. Ausgeführt diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. Die erste Datei stammt von der vom 15.10.

   Die Prüfung der Diff-Datei zeigt Nr. idProduct1232 oder 2003.

4. Ausgeführt diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Auch hier ist die erste Datei von der vom 15.10.

   Auch hier zeigt die Prüfung der Diff-Datei Nr. idProduct1232 oder 2003.

5. Steckte das Modem ein. Das Modem wurde als Modem erkannt.

   $ lsusb
   Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

6. Verbindung nach Einrichtung einer mobilen Breitbandverbindung problemlos möglich.

7. Modem ausgeworfen.

8. Installierte den neuesten USB_ModeSwitch.

   diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
   

   Gibt nun wie erwartet NULL zurück.

9. Ausgeführt sudo udevadm control --reload-rules.

10. Steckte das Modem ein. Das Modem wurde als Modem erkannt.

    $ lsusb
    Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
    

11. Konnte leicht verbinden.

Ich hätte versuchen können, MM und NM auf Ubuntu 15.10 zu aktualisieren, nur um zu sehen, wo es kaputt geht. Ich habe es tatsächlich versucht, aber aufgrund endloser Abhängigkeitsprobleme aufgegeben.

Alle oben genannten Diff-Dateien sind hier .

Update 20 - 12. Dezember 2015

Test 1

1. Der /lib/udev/rulesim Originalzustand.

2. Das Modemgerät wurde in dieser Sitzung noch nicht eingefügt.

3. Richten Sie ModemManager zum Debuggen und Einrichten von udevadm capture ein.

   sudo udevadm monitor --e |& tee udevadm.update20.WITHOUT78.log
   sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee MM.update20.WITHOUT78.log
   

4. Steckte das Modem ein und wartete, bis es anzeigt, dass es im Breitbandnetz registriert ist.

5. Es wurde versucht, keine Verbindung herzustellen.

6. Modem ausgeworfen.

7. Gepackte Protokolldateien.

Test 2

Wiederholen Sie den obigen Test mit /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesan Ort und Stelle.

Die Namen der Protokolldateien sind selbsterklärend.

Alle oben genannten Protokolldateien sowie Syslog und die 78 Regeldateien sind hier .

Ich wünschte, alle Protokolldateien wären mit Zeitstempeln versehen, um den Abgleich zu erleichtern.

Update 21 - 15. Dezember 2015

1. Die Regeldatei wurde wie vorgeschlagen geändert.
2. Meine Maschine neu gestartet.
3. Steckte das Modem ein und versuchte eine Verbindung herzustellen. Es hat nicht funktioniert.

Die Regeldatei und die syslogsind hier .

Update 22 - 16. Dezember 2015

Wie in einem Kommentar empfohlen, installierten Sie verschiedene Kernel von http://kernel.ubuntu.com/~kernel-ppa/mainline/ und versuchten, nach dem Booten jeweils eine Verbindung über das Modem herzustellen.

1. 4.2.8-040208-generic, failure.

2. 4.1.15-040115-generisch, Fehler.

3. 4.0.9-040009-generisch, Fehler.

Vielleicht können wir also das Kernel-Problem ausschließen.

Aktualisierung 23 - 16. Februar 2016

Das Modem hat in Ubuntu 16.04 begonnen zu funktionieren. Diese Version ist noch in Alpha 1, funktioniert aber in meinem Laptop einwandfrei.

Das Laden des ofonoPakets hat wahrscheinlich gut funktioniert, aber anscheinend ist Ihr Modem-Modell ZTE MF193E nicht auf der ZTE-Liste. Im Vergleich mit anderen ZTE Modems, zB MF190J, ist dieses Modem wahrscheinlich die gleiche besondere brauchen udevRegel zu laufen , usb_modeswitchwenn der Dongle eingesteckt ist, und zu erreichen , dass Sie können, als root, fügen Sie eine neue udevRegel in die Datei
/lib/udev/rules.d/40-usb_modeswitch.rules
mit den beiden folgenden Zeilen zB irgendwo in der Nähe des # ZTE MF190JKommentars:

# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"

plus eine Leerzeile, damit es für das Auge angenehm aussieht.

Es ist wahrscheinlich ratsam, danach neu zu starten, nur um herauszufinden, dass alles wie von Zauberhand funktioniert :-)

Oder nicht. Wie Sie wissen, ist dies tiefes Wasser für mich, aber wenn es immer noch nicht funktioniert, wäre ein weiteres ModemManager-Debug-Protokoll für eine weitere wilde Vermutung erforderlich.

BEARBEITEN:

Ich sehe mir jetzt die beiden Zeilen in modemmanager.txt an:

[mm-broadband-bearer.c:1254] connect(): Launching 3GPP connection attempt with APN 'WAP'

und

[mm-broadband-bearer.c:994] parse_pdp_list(): Found PDP context with CID 1 and PDP type ipv4 for APN 'wap'

Ich vermute, der erste bezieht sich auf Ihre Breitbandeinrichtung, während der zweite auf die interne Bindung an einen "PDP-Kontext" (was auch immer das ist) verweist. So wie es aussieht, bietet das Modem 9 alternative Kontexte, darunter einen mit apn='WAP', aber die ModemManagerSuche nach einer Übereinstimmung ohne Berücksichtigung der Groß- / Kleinschreibung ist erledigt.

Die Unterscheidung zwischen Groß- und Kleinschreibung könnte die Ursache für das nachfolgende Problem sein: z. B. dass ppp eine 'wap'Konfiguration wünscht (anstatt 'WAP') und diese nicht findet oder dass das Remote-Ende dies erwartet apn='WAP', aber "wap" erhält, woran es erstickt.

Die erste Option kann leicht getestet (und wahrscheinlich ausgeschlossen) werden, indem Sie Ihre Konfiguration so ändern, dass 'wap' anstelle von 'WAP' verwendet wird. Sie haben dies vielleicht schon einmal versucht, aber zu diesem Zeitpunkt ohne das ofonoPaket, sodass ein weiterer Test nicht schaden wird, obwohl die zweite Option wahrscheinlicher ist.

Die zweite Option ist ebenfalls problematischer, da vom Modem eine Übereinstimmung in Großbuchstaben "PDP-Kontext" verfügbar ist. Wenn Sie dieses Problem googeln, scheint die (anscheinend relevante) Spezifikation "3GPP TS 23.003, Kapitel 9.1" die Übereinstimmung zwischen Groß- und Kleinschreibung korrekt zu sein. Ein entsprechender Patch wurde ModemManagerim November letzten Jahres hinzugefügt (Version mm-1-4). Ich kann sammeln). In diesem Fall wurde Ihrem Modem nicht mitgeteilt, und es erwartet, dass zwischen Groß- und Kleinschreibung unterschieden wird. ModemManagerLeider wird die Zuordnung ohne Berücksichtigung der Groß- und Kleinschreibung direkt und nicht als Fallback verwendet.

Eine Lösung für das zweite Problem besteht natürlich darin, eine andere zu verwenden ModemManager: entweder indem Sie eine Version vor diesem Patch suchen und installieren oder (mit genügend Freizeit) Ihre eigene rollen ModemManager. Aber beides kann man nicht aus einer Laune heraus tun. Vielleicht müssen wir uns ein wenig umschauen, um mehr Beweise dafür zu erhalten, dass dies (jetzt) ​​das Problem ist, und wenn möglich, andere Möglichkeiten zu finden, es zu umgehen. Oder mit etwas Glück kommt jemand vorbei, der etwas weiß ...

BEARBEITEN 2

Ja, ein Versions-Rollback ist aufgrund von Abhängigkeiten nicht einfach. Und das eigene rollen ist auch keine Freude.

Zwei mögliche nützliche Tools: command mmcliund ( http://m2msupport.net/m2msupport/module-tester/ ).

Ich denke, das Problem ist, dass der ModemManager den PDP-Kontext 1 mit apn = 'wap' auswählt, wo er den PDP-Kontext 9 mit apn = 'WAP' auswählen sollte. Vielleicht kann dies mithilfe eines dieser Tools behoben werden. Entweder, um eine Auswahl von 9 während der Verbindung zu erzwingen, oder indem die fehlerhaften "WAP" -Kontexte aus dem Modem gelöscht werden, für die das Modultester-Tool angekündigt ist.

Das Modem-Tester-Tool scheint ein Java-Tool im Browser zu sein. Daher muss Ihr Browser so eingerichtet sein, dass er weiß, wo sich Ihr Java befindet, und Sie müssen über dieses Java Bescheid wissen. Dann erforschen Sie bitte diesen Ansatz; Ich habe es selbst nicht verwendet, aber ich vermute, dass die PDP-Kontexte auf der Registerkarte "Datenanrufe" angezeigt werden, auf der Sie zuerst alles notieren, was angezeigt wird, und dann die "WAP" -Einträge bearbeiten Verzerren Sie die 'WAP'-APN-Bezeichnungen, um beispielsweise' WAP1 'und' WAP2 'zu sein (um sie bei der Suche nach' WAP 'zu "verbergen"). Speichern und schließen Sie dann und jonglieren Sie erneut mit dem Dongle. Nimm ein Protokoll. Es scheint, dass Syslog jetzt ausreicht, falls es sich immer noch weigert zu spielen.

Der mmcliBefehl scheint auch in dieser Geschichte nützlich zu sein; tun man mmcli, um darüber zu lesen, aber ich habe dort nichts über PDP-Kontexte gesehen.

EDIT 3

Guter Anruf! von der DVD testen. Das hat uns gesagt, dass ich mit dem APN auf dem falschen Weg bin und dass alles darin liegt, ppp dazu zu bringen, dass es hochkommt. Zumindest wäre das mein neuer Baum, an dem ich bellen könnte.

Zunächst nehmen wir zur Kenntnis, dass es für pppd einen Versionsunterschied gibt (von 2.4.5 zu 2.4.6), aber das ist wahrscheinlich kein Problem, da dann jeder auf einem Dongle an diesem Ausflug teilgenommen hätte.

Hmm, ppp; Ich muss meine Erinnerungen an das letzte Jahrtausend wachrütteln :-). Leider bin ich heute beschäftigt, aber ich werde mich melden, wenn ich das nächste Mal Zeit habe, um zu sehen, wie weit du gekommen bist. Meine ersten Seitengassen, in die ich schauen müsste, wären: 1) Ist der Benutzer in der richtigen Gruppe? 2) Sind die Anmeldeinformationen richtig? 3) Stimmt der Mod der ppp / chat Konfigurationsdatei? Das ppp-Debug-Protokoll wird in der Datei nm.txt (wie vor ein paar Tagen) ausgegeben. Es sollte jedoch auch eine Möglichkeit geben, das Protokoll detaillierter anzufordern.

EDIT 4

Sicherzustellen /etc/ppp/pap-secretsund /etc/ppp/chap-secretshat Gruppe dip(unter Verwendung von chgrpnach Bedarf) und Modus 740(oder -rw-r-----) (unter Verwendung je chmodnach Bedarf). Meins nicht.

EDIT 5

Wie wäre es dann mit diesem Baum: Wenn man das funktionierende wvdialSyslog mit dem nicht funktionierenden Syslog vergleicht, sieht es so aus, als würde es aus irgendeinem Grund wvdialverwendet, ttyUSB3während das nicht funktionierende weiterhin ModemManagerverwendet wird ttyUSB1. Ich bin mir nicht sicher , ob es überhaupt bedeutsam ist, aber anscheinend aber ttyUSB1und ttyUSB3beide reagiert wie AT fähig Modem.

Als Test kannst du es /etc/wvdial.confalso vielleicht so bearbeiten, dass es [Dialer Defaults]die folgende Zeile enthält:

Modem = /dev/ttyUSB1

für den einen Test und ttyUSB3für den anderen; beide laufen als root; nur um zu sehen, ob es ein anderes Verhalten gibt. Insbesondere wenn die Verwendung ttyUSB1ein Problem darstellt, während die Verwendung von ttyUSB3 kein Problem darstellt, ist es hilfreich zu prüfen, wie ModemManager auch die Verwendung von ttyUSB3 veranlasst. Für jedes andere Testergebnis würde ich sagen, wir werden wieder Frettchen im PPP-Land jagen.

EDIT 6

Das Dmesg-Protokoll kann meiner Meinung nach ignoriert werden. das war in allen logs so. Das neue Syslog zeigt nur den ttyUSB3-Test, aber vielleicht können wir davon ausgehen, dass das Leben besser wird, wenn NetworkManagerman lernen kann, ttyUSB3 zu verwenden und ttyUSB1 (für dieses Modem) zu ignorieren.

Ich fand auch ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) mit besonders beunruhigendem Beitrag # 10 :-(

Die anscheinend geltende udevRegel in /lib/udev/rules.d/77-mm-zte-port-types.rulesgilt nicht, aber angeblich, wohin es gehen soll. Und mit einem sehr rudimentären Einblick in die udevMagie vor 101 Jahren würde ich auf jeden Fall in Betracht ziehen, die vierte Zeile in Frage zu stellen, in der es heißt:

SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"

Ich denke, dass diese Zeile eine Initiale benötigt #, um auskommentiert zu werden. Im Detail ist mein Lesen der Datei, dass es einen aufrufenden Zustand von SUBSYSTEM == "tty" und SUBSYSTEMS = "usb" erfordert, um die guten Bits, einschließlich der "2003" -Produktregeln, zu verwenden, und zumindest zum Testen. Es sollte sicher sein, die "tty" -Filterung zu überspringen. Und ich habe momentan nichts Besseres.

BEARBEITEN 7

Nachdem ich einige Zeit mit meiner Lieblingssuchmaschine verbracht habe, glaube ich etwas mehr, dass die Wahl von ttyUSB hier ein Grundproblem ist. Die udev-Regel, auf die ich hingewiesen habe, ist in Ordnung, und Sie sollten diese Änderung rückgängig machen.

Ich bin jedoch der Meinung, dass die Konfigurationsregeln gegen Ende dieser Datei für die Produkt-ID "2003" irreführend sind. Aus den Protokollen geht hervor, dass die Produkt-ID "2003" tatsächlich die Speicherseite des Dongles ist, während die Modemseite die Produkt-ID "1232" hat. Sie können dies testen, indem Sie die beiden "2003" -Regeln für die Produkt-ID "1232" in der Datei replizieren/lib/udev/rules.d/77-mm-zte-port-types.rules

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"

oder besser, fügen Sie eine neue Datei hinzu, z. B. named 78-ralph.rules. Dann müssen Sie jedoch auch den Schutz SUBSYSTEM und SUBSYSTEMS hinzufügen.

Ziehen Sie dann den Dongle heraus, führen Sie ihn aus udevadm control --reload(oder starten Sie ihn neu) und setzen Sie den Dongle ein. Und dann noch eine syslogAufnahme, es sei denn, es funktioniert jetzt.

Das effektive Problem ist jedoch, dass ModemManager das Plugin libmm-plugin-zte.sobeim Pre- Probing verwirft und einen generischen Modem-Handler verwendet. Wenn ich in Bezug auf die Produkt-ID recht habe, ist dies möglicherweise der Grund. ID_MM_ZTE_PORT_TYPE_MODEMDieses Pre-Probing sucht nach einem Attribut, und dieses fehlt für die Produkt-ID "1232" (vor dem Patch), so dass das ZTE-Plugin verworfen wird.

BEARBEITEN 8

Das syslogProtokoll ist etwas kurz. Es fehlt der Anfang, an dem ModemManager das ZTE-Plugin nicht installieren kann. Es ist jedoch klar, dass das generische Modem-Plugin auf jeden Fall verwendet wird. Nun kann es sein, dass die usb_modeswitchRegel, die ich Ihnen von Anfang an gegeben habe, auch falsch ist; es beschließt, zu "2003" zu wechseln , als ich dachte, dass es von "2003" gewechselt ist . Aber man usb_modeswitch(die ich auf , bevor ausgesehen haben sollte) Art lassen vermuten , dass es verschiebt sich auf eine Produkt - ID , anstatt von ihm. In jedem Fall zeigt das Protokoll, dass dies geschehen soll. Ändern Sie daher diese Regel, um stattdessen "1232" zu verwenden, und versuchen Sie es erneut.

Wenn nichts anderes, muss ich zumindest ein bisschen über udev lernen.

BEARBEITEN 9

Gut. Das Problem ist immer noch (oder auch), dass ModemManager das ZTE-Plugin beim Pre-Probing löscht. In den ModemManager-Debugging-Protokollen für 15.10 (Protokollsätze "debuglogs *") heißt es, dass das ZTE-Plug-in aufgrund des Herstellerkennung / Produktkennungstests verworfen wird.

Geh zur Quelle, Luke! Ich habe diese Gelegenheit genutzt, um den ModemManager-Quellcode kurz zu sehen, und es zeigt an, dass das Plugin eine Tabelle mit vid / pid ist, die 19d2 / 2003 nicht enthält. Allerdings habe ich diese Tabellenquelle nicht gefunden, sodass ich sie nicht finden konnte nicht verifizieren.

Oder vielleicht gibt es hier ein Timing-Problem. Zum Beispiel, dass der ModemManager die Voruntersuchung ausführt, während das Gerät auf 19d2 / 1232 eingestellt ist. Dieser Gedanke steht in Einklang mit der Beobachtung, dass mit den udev-Regeln von 78-mm-zte-port-types-RALPH.rules der ModemManager ein wenig zufriedener mit dem Gerät ist. Aber warum bleibt es dann nicht glücklich und nutzt dieses Plugin, wenn das Gerät auf 19d2 / 2003 umgestellt wird?

Vielleicht werden mehr Protokolle benötigt :-) Mit ModemManager debugged, und auch eine Erfassung des Befehls udevadm monitor --e |& tee udevadm.log(in einem anderen Terminal), wenn Sie das Gerät einstecken. Ich habe diesen Befehl von ( https://wiki.ubuntu.com/DebuggingUdev ) erhalten.

Tun Sie dies zweimal: einmal ohne 78-mm-zte-port-types-RALPH.rulesund einmal mit den Regeln ... beide Male nach einem Neustart. Dh

1. Setup /lib/udev/rules.dmit oder ohne die *-RALPH.rulesDatei
2. Ziehen Sie das Gerät heraus
3. neustarten
4. Richten Sie ModemManager zum Debuggen und Einrichten von udevadm capture ein
5. Schließen Sie das Gerät an und warten Sie eine Minute
6. Packen Sie die Protokolldateien
7. Wiederholen Sie ab 1 mit dem nächsten Test

Diese Protokollierung sollte Aufschluss darüber geben, wo das ZTE-Plug-In abgelegt wurde, und meines Wissens auch über die Behandlung von udev-Ereignissen.

BEARBEITEN 10

(Ich bin fast am Ende meines Seils, aber ich habe noch ein oder zwei Atemzüge übrig :-)

Erstens udevscheinen alle Dekorationen so zu enden, wie sie sollten, mit nur ein paar Fragezeichen in einigen Attributen. Insbesondere 78-*-RALPH.rulessollte das weggeworfen werden; es ist nicht nützlich.

Ich glaube, ich kann etwas daraus vorlesen, bin mir aber nicht ganz sicher, wie es behoben werden soll. Grundsätzlich, wie ich es sehe, gibt es, wenn der Dongle eingesteckt ist, eine Flut von udev-Ereignissen. Es gibt eine "frühe" Veranstaltung, die sich auf diejenigen konzentriert, die ttyUSB1 betreffen:

KERNEL[3867.310990] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1 (usb)

Dadurch wird der usb_serialTreiber geladen und /dev/ttyUSB1angezeigt. Dies führt insbesondere zu einem anderen Ereignis:

KERNEL[3867.435102] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

Ich denke das löst auch aus ModemManager. Sie müssen zu gehen, syslogum Beweise dafür zu sehen, da es keine strikte Korrelation zwischen den Protokollen gibt. Das Ereignis ist mit einem Zeitstempel versehen 3867.435102und syslogzeigt die nächste ModemManagerProtokollzeile unmittelbar nach einer gestempelten Kernel-Protokollzeile an 3867.437412.

Aus meiner ModemManagerSicht sollte noch nicht ausgelöst werden, sondern erst nach dem folgenden ttyUSB1-Ereignis:

UDEV  [3867.580427] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

welches die ZTE Attribute angehängt hat.

Im MM-Protokoll befinden wir uns in der mit einem Stempel versehenen Zeile 1449934745.363291, bei der es sich anscheinend eher um einen "Echtzeit" -Zeitstempel als um einen "Kernel-Zeit" -Stempel handelt.

ModemManagerDann erfolgt die Voruntersuchung bei 1449934745.450398, dh 87 ms später, was in Bezug auf die 3867.524519Kernelzeit in der Nähe und 55 ms vor dem obigen "guten" UDEV-Ereignisbericht liegen würde.

Beachten Sie, dass in syslog, ModemManagerlodge Beschwerden macht , die ttyUSB1nicht seine Attribute gesetzt hat, und vielleicht , dass Beschwerde an die in Beziehung steht „Markierung“ in geschieht 80-mm-candidate.rules. Nach dem Kommentar in dieser Datei scheint diese Markierung ein Versuch zu sein, genau mit diesem Problem umzugehen, aber wenn ja, scheint sie in diesem Fall nicht zu funktionieren.

Möglicherweise besteht eine Möglichkeit zur Lösung dieses Problems darin, die "tty" -Regel zu ändern 80-mm-candidate.rules:

ENV{.ID_PORT}=="?*", SUBSYSTEM=="tty", ENV{ID_MM_CANDIDATE}="1"

In meinen Augen würde dies sicherstellen, dass die ID_MM_CANDIDATEEinstellung verzögert wird, bis die ZTE-Attribute festgelegt sind. Die .ID_PORTEinstellung ist ein Effekt einer 60-serial.rulesRegel (die 60-persistent-serial.ruleszuvor aufgerufen wurde ), und die hinzugefügte Bedingung für die Markierungsregel ist einfach, dass sie einen Wert hat.

Die Bedingung ist nicht genau ein ZTE-Attribut, nur um die Regel allgemeiner zu halten. Ein Schritt spezifischer wäre, ENV{.MM_USBIFNUM}="?*"stattdessen eher zu verlangen , da diese Zuordnung hier durch geschieht 77-mm-zte-port-types.rules.

Im Allgemeinen bin ich mir bei der Regelbestellung nicht ganz sicher udev, und ich bin mir auch nicht sicher, ob dies wirklich aufhört ModemManager, zu schnell zu handeln. Sollte dies jedoch nicht der Fall sein, 80-mm-candidate.ruleshätte dies nur eine geringe bis gar keine Funktion, und möglicherweise würde dann alles auf die "Verbesserungen" ModemManagervom 15.04.

EDIT 21

Seufzer. Wahrscheinlich irrelevant, aber Sie möchten möglicherweise Ihre 7-zte-mutil_port_device.rulesDatei überprüfen . ist das ein Überrest von anderen Experimenten? Jedenfalls hier nicht relevant.

Es ist noch fast eine Sekunde zwischen 515.558184und 516.381549wo ModemManagereifrig und irrtümlich greift /dev/ttyUSB1, und während Sie sich darüber beschweren, dass es nicht eingerichtet ist, geht es noch durch die Voruntersuchung und verwirft das ZTE-Plugin. Mit anderen Worten, der Regel-Patch lässt nicht auf sich ModemManagerwarten.

Ich nehme an, du hast es auch mit ENV{.MM_USBIFNUM}="?*"anstatt getestet ENV{.ID_PORT}=="?*".

Eigentlich, um zu bestätigen, ob die Einstellung ENV{ID_MM_CANDIDATE}=1 von Bedeutung ist , sollten Sie sich vorübergehend entfernen und nachsehen 80-mm-candidate.rules, syslogob sie ModemManagerignoriert wird /dev/ttyUSB1oder nicht. Ich vermute "nicht".

Und dann können Sie vielleicht eine funktionierende Version wie 14.04 verwenden und, falls erforderlich, 15.10 in einer Virtualbox ausführen, es sei denn, es befindet sich bereits alles in einer Virtualbox.

Ich denke, ich muss mich jetzt geschlagen geben.

Das Modem hat in Ubuntu 16.04 begonnen zu funktionieren. Diese Version befindet sich noch in der Entwicklungsphase, funktioniert aber in meinem Laptop einwandfrei.

Ich wünschte, ich könnte mehr technische Details darüber liefern, wie es funktioniert hat.

Auf den ersten Blick scheint es nicht das erste Mal zu sein, dass mit diesem Drachen richtig umgegangen wird. Es war ein Fehler in den Jahren 12.10 und 13.04, vielleicht wurde der Fehler nie behoben oder ein neuer Patch hat etwas kaputtgemacht, was vorher korrekt funktionierte.

Wenn ich Ihre technischen Daten richtig lese, muss ich Sie hoffentlich in diese Richtung weisen (MF190J):

Das 3G-Modem (ZTE MF190J) muss noch manuell angepasst werden.

Haben Sie das versucht:

 rfkill list up

und dann mache dieses Skript und führe es aus:

 #/bin/sh

     Case [!$] in
        /bin/sh
        networkname="true"
        networkname="the ip adr type in here"
        nmcli nm networkname --force-yes
        resolve.conf the ip adr type in here
     endl

und es könnte gut so funktionieren.