Fehler „ip-config-unavailable“, wenn das USB-Modem versucht, eine Verbindung herzustellen?

Bei all diesen Tools muss der Benutzer zum Herstellen einer Wählverbindung
Mitglied der Gruppen „dip“ und „dialout“ sein, also ordnen Sie alle Benutzer, die
sich per Wählverbindung verbinden sollen, diesen Gruppen zu .

Aber wie wir feststellen 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. Welcher zusätzlicher Gruppe muss der Benutzer angehören?
2. Wie führen wir den Einrichtungsprozess für die mobile Breitbandverbindung als Root aus? (Sicherheitsprobleme?)

Aktualisierung 11 – 9. Dezember 2015

wvdial funktioniert mit USB3 und nicht arbeiten mit USB1.

Das Syslog finden Sie hier.

Ebenfalls enthalten ist die Ausgabe von dmesg | grep tty > /tmp/dmesg.tty.txt . Aber sehen Sie diese vier Zeilen am Anfang der Datei?

Aktualisierung 12 – 10. Dezember 2015

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

2. Meine Maschine neu gestartet. Soft hat das Kabel abgezogen und das Modem eingesteckt.

3. Versucht zu verbinden. Nicht erfolgreich.

Die Syslog-Datei ist hier.

Aktualisierung 13 – 10. Dezember 2015

Aus purer Verzweiflung, um zu sehen, ob irgendwelche lokalen Änderungen die Verbindung beeinträchtigen, habe ich die Maschine mit Ubuntu 15.04 und 15.10 DVDs getestet.

1. Bootte die Maschine mit Xubuntu 15.04 64-Bit-DVD. Die Verbindung war erfolgreich wie ein Zauber.
2. Die Maschine mit Ubuntu 15.10 64-Bit-DVD gebootet. Die Verbindung ist nach wie vor fehlgeschlagen.

Was ist zwischen dem 15.04 und dem 15.10 passiert?

So frustrierend.

Aktualisierung 14 – 10. Dezember 2015

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

2. Meine Maschine neu gestartet (oder sudo udevadm control --reload ausgeführt , eigentlich beides versucht). Modem eingefügt.

3. Das Modem wurde erkannt.

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

4. Soft hat das Kabel getrennt und versucht, eine Verbindung über das Modem herzustellen. Nicht erfolgreich.

5. Modem ausgeworfen.

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

Die Syslog-Datei und die erstellten Regeldateien befinden sich hier.

Aktualisierung 15 – 11. Dezember 2015

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

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

2. Verließ die Datei /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intakt.

3. Meine Maschine neu gestartet. Modem eingefügt.

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. Nicht erfolgreich.

6. Modem ausgeworfen.

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

8. Neustart und den ganzen Vorgang nochmal probiert. Wieder erfolglos.

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

Aktualisierung 16 – 11. Dezember 2015

1. Nur noch eine 1232-Regel in
   /lib/udev/rules.d/40-usb_modeswitch.rules übrig , das andere entfernt
   .

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

3. Modem eingefügt.

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. Nicht erfolgreich.

6. Modem ausgeworfen.

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

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

Aktualisierung 17 – 11. Dezember 2015

1. Die 1232-Regel in
   /lib/udev/rules.d/40-usb_modeswitch.rules auskommentiert , 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. sudo udevadm control --reload ausgeführt .

3. Modem eingefügt.

4. Das Modem wurde als 1232 erkannt Gerät. Mir wird nicht angeboten, eine Verbindung herzustellen (soweit ich weiß, wird es nicht im Breitbandnetz registriert, es sei denn, es wurde auf 2003 umgeschaltet)

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

5. Modem ausgeworfen.

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

Aktualisierung 18 – 11. Dezember 2015

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

2. lsusb beobachtet Ausgabe jede Sekunde mit einem Shell
   -Skript. Erfasste Ausgabe in Dateien mit Zeitstempel.

3. Habe das Modem eingefügt. (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 klar, dass es von einem 1232er-Gerät auf ein
   2003er-Gerät umschaltet.

4. Versucht zu verbinden. Nicht erfolgreich.

5. Modem ausgeworfen.

Die Syslog-Datei mit dem Zeitstempel lsusb Ausgaben und die erwähnten Regeldateien sind hier.

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

Aktualisierung 19 – 11. Dezember 2015

Habe diesen Test in einer völlig neuen Richtung durchgeführt mit dem Wunsch, dass ich
die Probleme isolieren könnte.

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

2. Die Maschine mit Xubuntu 15.04 64-Bit-DVD gebootet.

3. 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 ist die gespeicherte
   vom 15.10.

   Die Untersuchung der Diff-Datei zeigt kein idProduct 1232 oder 2003.

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

   Auch hier zeigt die Untersuchung der Diff-Datei kein idProduct 1232 oder 2003.

5. Habe das Modem eingefügt. Das Modem wurde als Modem erkannt.

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

6. Konnte nach dem Einrichten einer mobilen Breitbandverbindung problemlos eine Verbindung herstellen.

7. Modem ausgeworfen.

8. Den neusten USB_ModeSwitch installiert.

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

   Gibt jetzt wie erwartet NULL zurück.

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

10. Habe das Modem eingefügt. Das Modem wurde als Modem erkannt.

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

11. Könnte problemlos eine Verbindung herstellen.

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

Alle oben erwähnten Diff-Dateien sind hier.

Aktualisierung 20 – 12. Dezember 2015

Test 1

1. Die Datei /lib/udev/rules im Originalzustand.

2. Das Modem wurde in dieser Sitzung noch nicht eingefügt.

3. Richten Sie ModemManager zum Debuggen ein und richten Sie 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. Stecken Sie das Modem ein und warten Sie, bis es sagt, dass es im Breitbandnetz registriert ist.

5. Verbindungsversuch erfolglos.

6. Modem ausgeworfen.

7. Protokolldateien gepackt.

Test 2

Wiederholte den obigen Test mit
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules vorhanden.

Die Namen der Protokolldateien sind selbsterklärend.

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

Ich wünschte, alle Protokolldateien hätten Zeitstempel, was den Abgleich erleichtert.

Aktualisierung 21 – 15. Dezember 2015

1. Änderte die Regeldatei wie vorgeschlagen.
2. Meinen Rechner neu gestartet.
3. Das Modem eingesteckt und versucht, eine Verbindung herzustellen. Es hat nicht funktioniert.

Die Regeldatei und das syslog sind hier.

Aktualisierung 22 – 16. Dezember 2015

Wie in einem Kommentar empfohlen, installierte er verschiedene Kernel von
http://kernel.ubuntu.com/~kernel-ppa/mainline/ und versuchte, sich
mit dem Modem zu verbinden, nachdem er in jedem gebootet hatte.

1. 4.2.8-040208-generisch, Fehler.

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 funktioniert seit Ubuntu 16.04. Diese Version befindet sich noch in Alpha 1, funktioniert aber problemlos auf meinem Laptop.

Akzeptierte Antwort:

Laden des ofono Paket war wahrscheinlich gut, aber anscheinend ist Ihr Modemmodell, ZTE MF193E, nicht auf der ZTE-Liste. Im Vergleich zu anderen ZTE-Modems, z. B. MF190J, benötigt dieses Modem wahrscheinlich denselben speziellen udev Regel, um usb_modeswitch auszuführen wenn der Dongle eingesteckt ist, und um dies zu erreichen, können Sie als root einen neuen udev hinzufügen Regel in die Datei
/lib/udev/rules.d/40-usb_modeswitch.rules
mit den folgenden zwei Zeilen z. B. irgendwo in der Nähe des # ZTE MF190J Kommentar:

# 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 festzustellen, dass alles wie von Zauberhand funktioniert 🙂

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

BEARBEITEN:

Ich schaue 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, dass sich das erste auf Ihre Breitbandeinrichtung bezieht, während sich das letztere auf die interne Bindung an einen „PDP-Kontext“ (was auch immer das ist) bezieht. So wie es aussieht, bietet das Modem 9 alternative Kontexte, darunter einen mit apn='WAP' , sondern der ModemManager gibt sich mit einer Übereinstimmung ohne Berücksichtigung der Groß-/Kleinschreibung zufrieden.

Der Fallunterschied könnte die Ursache für das nachfolgende Problem sein:z. B. dass ppp ein 'wap' will Konfiguration (statt 'WAP' ) und es nicht findet, oder dass die Gegenstelle apn='WAP' erwartet , bekommt aber „wap“, an dem es erstickt.

Die erste Option könnte leicht getestet (und wahrscheinlich ausgeschlossen) werden, indem Sie Ihre Konfiguration so ändern, dass sie „wap“ anstelle von „WAP“ verwendet. Vielleicht haben Sie das schon einmal versucht, aber damals ohne ofono Paket, also schadet ein weiterer Test nicht, obwohl die zweite Option wahrscheinlicher ist.

Die zweite Option ist auch eher ein Problem, da vom Modem eine Großbuchstaben-„PDP-Kontext“-Übereinstimmung verfügbar ist. Wenn Sie dieses Problem googeln, scheint es, dass die Übereinstimmung ohne Berücksichtigung der Groß-/Kleinschreibung durch die (anscheinend relevante) Spezifikation „3GPP TS 23.003 Kapitel 9.1“ korrekt ist, und ein Patch, um dies zu tun, wurde zu ModemManager hinzugefügt im November letzten Jahres (in seiner Version mm-1-4, soviel ich weiß). In diesem Fall wurde Ihrem Modem also nichts mitgeteilt, und es erwartet eine Übereinstimmung zwischen Groß- und Kleinschreibung, während ModemManager Leider wird die Groß-/Kleinschreibung nicht als Fallback verwendet.

Eine Lösung für das zweite Problem ist natürlich die Verwendung eines anderen ModemManager :entweder indem Sie eine Version vor diesem Patch finden und installieren, oder (mit genügend Freizeit) Ihren eigenen ModemManager erstellen . Aber beides ist nicht aus einer Laune heraus zu tun, also müssen wir vielleicht ein bisschen herumstöbern, um mehr Beweise dafür zu finden, dass dies (jetzt) ​​das Problem ist, und wenn möglich andere Wege finden, um es zu umgehen. Oder mit etwas Glück kommt jemand vorbei, der sich auskennt…

BEARBEITEN 2

Ja, Versions-Rollback ist aufgrund von Abhängigkeiten nicht einfach. Und selbst zu rollen ist alles andere als ein Vergnügen.

Zwei mögliche nützliche Tools:Befehl mmcli und
(http://m2msupport.net/m2msupport/module-tester/).

Das Problem, denke ich, ist, dass ModemManager PDP-Kontext 1 mit apn=’wap’ auswählt, wo er PDP-Kontext 9 mit apn=’WAP’ auswählen sollte. Vielleicht kann dies mit einem dieser Tools behoben werden. Entweder um während der Verbindung eine Auswahl von 9 erzwingen zu können, oder indem die schlechten „wap“-Kontexte aus dem Modem gelöscht werden, wozu das Modul-Tester-Tool beworben wird.

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 erkunden Sie bitte diesen Ansatz; Ich habe es selbst nicht verwendet, aber wenn ich die Screenshots sehe, vermute ich, dass es die PDP-Kontexte als die Registerkarte „Datenanrufe“ darstellen wird, wo Sie zuerst alles notieren, was es zeigt, und dann die „wap“-Einträge bearbeiten verzerren Sie die 'wap'-apn-Bezeichnungen, sagen wir, 'wap1' und 'wap2' (um sie zu "verstecken", wenn Sie nach 'WAP' suchen). Speichern und schließen Sie dann und jonglieren Sie erneut mit dem Dongle. Schnappen Sie sich ein Protokoll; es scheint, dass Syslog jetzt ausreicht, falls es sich immer noch weigert zu spielen.

Die mmcli Befehl scheint auch in dieser Geschichte nützlich zu sein; mach man mmcli darüber zu lesen, aber ich habe dort nichts über PDP-Kontexte gesehen.

BEARBEITEN 3

Guter Anruf! von der DVD zu testen. Das hat uns gesagt, dass ich mit dem APN auf dem falschen Weg bin und dass alles daran liegt, ppp zum Auftauchen zu bringen. Zumindest wäre das mein neuer Baum, den ich anbellen könnte.

Zunächst nehmen wir zur Kenntnis, dass es einen Versionsunterschied für pppd gibt (von 2.4.5 zu 2.4.6), aber das ist wahrscheinlich kein Problem, da dann jeder mit einem Dongle auf dieser Exkursion gewesen wäre.

Hm, ppp; Ich muss meine Erinnerungen an das letzte Jahrtausend aufwecken :-). Leider bin ich heute beschäftigt, aber ich melde mich, wenn ich das nächste Mal Zeit habe, um zu sehen, wie weit du gekommen bist. Meine ersten zu untersuchenden Hintergassen wären:1) Ist der Benutzer in der richtigen Gruppe? 2) Sind die Anmeldeinformationen richtig? 3) Sind die PPP/Chat-Konfigurationsdatei-Mods richtig? Das ppp-Debug-Log erscheint in nm.txt (wie vor ein paar Tagen), aber es sollte auch eine Möglichkeit geben, es um ein detaillierteres Log zu bitten.

BEARBEITEN 4

Stellen Sie /etc/ppp/pap-secrets sicher und /etc/ppp/chap-secrets Gruppe dip haben (mit chgrp nach Bedarf) und Modus 740 (oder -rw-r----- ) (mit chmod wie benötigt). Meins nicht.

BEARBEITEN 5

Wie wäre es dann mit diesem Baum:Vergleichen des funktionierenden wvdial syslog mit nicht funktionierendem syslog, es scheint, dass aus irgendeinem Grund wvdial verwendet ttyUSB3 während der nicht funktionierende ModemManager verwendet weiterhin ttyUSB1 . Ich bin mir nicht sicher, ob es überhaupt von Bedeutung ist, aber anscheinend aber ttyUSB1 und ttyUSB3 beide reagieren als AT-fähige Modems.

Testweise können Sie also vielleicht /etc/wvdial.conf bearbeiten so unter [Dialer Defaults] enthält die Zeile:

Modem = /dev/ttyUSB1

für den einen Test und ttyUSB3 für einander; beide laufen als root; nur um zu sehen, ob es ein anderes Verhalten gibt. Besonders, wenn ttyUSB1 verwendet wird ein Problem ist, während die Verwendung von ttyUSB3 dies nicht ist, dann wäre es gut zu prüfen, wie ModemManager dazu gebracht werden kann, ttyUSB3 ebenfalls zu verwenden. Für alle anderen Testergebnisse würde ich sagen, dass wir wieder Frettchen im PPP-Land jagen werden.

BEARBEITEN 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 NetworkManager kann man lernen, ttyUSB3 zu verwenden und ttyUSB1 zu ignorieren (für dieses Modem).

Ich fand auch (https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784) mit besonders Post #10 beunruhigend 🙁

Das scheinbar zutreffende udev Regel in /lib/udev/rules.d/77-mm-zte-port-types.rules trifft nicht zu, wäre aber angeblich der richtige Ort. Und das mit nur einem sehr rudimentären, pre-101 Einblick in udev Magic, ich würde jedenfalls in Betracht ziehen, ihre vierte Zeile in Frage zu stellen, in der es heißt:

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

Ich denke, diese Zeile braucht ein anfängliches # um auskommentiert zu werden. Im Detail habe ich die Datei so gelesen, dass sie einen Aufrufstatus von SUBSYSTEM==“tty“ und SUBSYSTEMS=“usb“ erfordert, um die guten Teile zu verwenden, einschließlich der „2003“-Produktregeln, und zumindest zum Testen. Es sollte sicher sein, die „tty“-Filterung zu überspringen. Und etwas Besseres fällt mir gerade nicht ein.

BEARBEITEN 7

Nachdem ich einige Zeit mit meiner Lieblingssuchmaschine verbracht habe, glaube ich etwas mehr, dass die ttyUSB-Wahl 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 habe jedoch begonnen zu glauben, 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 Speichergeräteseite 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 /lib/udev/rules.d/77-mm-zte-port-types.rules replizieren

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 daneben eine neue Datei hinzu, z.B. namens 78-ralph.rules , aber dann müssen Sie auch den Schutz SUBSYSTEM und SUBSYSTEMS darum herum hinzufügen.

Ziehen Sie dann den Dongle heraus und führen Sie udevadm control --reload aus (oder neu starten) und den Dongle einstecken. Und dann noch ein syslog erfassen, es sei denn, es funktioniert jetzt zufällig.

Das eigentliche Problem ist jedoch, dass ModemManager das Plugin libmm-plugin-zte.so verwirft beim Pre-Probing und endet mit der Verwendung eines generischen Modem-Handlers. Wenn ich mit der Produkt-ID richtig liege, könnte dies der Grund sein; dass die Vorabprüfung nach einem ID_MM_ZTE_PORT_TYPE_MODEM sucht Namensnennung, und diese fehlt für die Produkt-ID „1232“ (vor dem Patch), was zur Folge hat, dass das zte-Plugin verworfen wird.

BEARBEITEN 8

Das syslog log ist etwas kurz; fehlender Anfang, an dem ModemManager das zte-Plug-in nicht installiert. Es ist jedoch klar, dass das generische Modem-Plugin sowieso verwendet wird. Nun kann es sein, dass der usb_modeswitch Regel, die ich dir früh gegeben habe, ist auch falsch; es beschließt, zu zu wechseln „2003“, als ich dachte, es wechselte von „2003“. Aber, man usb_modeswitch (was ich mir vorher hätte ansehen sollen) deutet darauf hin, dass es sich zu verschiebt eine Produkt-ID statt von es. Jedenfalls zeigt das Log das an. Ändern Sie diese Regel daher bitte so, dass stattdessen „1232“ verwendet wird, und versuchen Sie es noch einmal.

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

BEARBEITEN 9

Gut. Das Problem ist immer noch (oder auch), dass ModemManager das ZTE-Plugin beim Pre-Probing verwirft. Die ModemManager-Debugging-Protokolle für 15.10 (Protokollsätze „debuglogs*“) erzählen alle, dass das ZTE-Plug-in aufgrund des Anbieter-ID-/Produkt-ID-Tests verworfen wurde.

Geh zur Quelle, Luke! Ich habe diese Gelegenheit genutzt, um mir kurz den ModemManager-Quellcode anzusehen, und er weist darauf hin, dass das Plugin eine Tabelle von vid/pid ist, die 19d2/2003 nicht enthält … obwohl ich diese Tabellenquelle nicht gefunden habe, also konnte ich es nicht überprüfen.

Oder vielleicht gibt es hier ein Timing-Problem. Zum Beispiel, dass der ModemManager Pre-Probing durchführt, während das Gerät 19d2/1232 ist. Dieser Gedanke stimmt mit der Beobachtung überein, dass ModemManager mit den 78-mm-zte-port-types-RALPH.rules udev-Regeln 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?

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

Führen Sie dies zweimal durch:einmal ohne 78-mm-zte-port-types-RALPH.rules und einmal mit den Regeln… beide Male von einem frischen Neustart. D.h.

1. setup /lib/udev/rules.d mit oder ohne *-RALPH.rules Datei
2. Ziehen Sie das Gerät heraus
3. Neustart
4. ModemManager zum Debuggen einrichten und udevadm-Erfassung einrichten
5. Schließen Sie das Gerät an und warten Sie eine Minute
6. Protokolldateien packen
7. Wiederholen Sie ab 1 mit dem nächsten Test

Diese Protokollierung sollte Aufschluss darüber geben, wo das ZTE-Plug-in abgelegt wird, und wie ich es verstanden habe, wird es auch über die Behandlung von udev-Ereignissen Auskunft geben.

BEARBEITEN 10

(Ich bin hier fast am Ende meiner Kräfte, aber ich habe noch ein, zwei Atemzüge übrig:-)

Zuerst das ganze udev Die Dekorationen scheinen so zu enden, wie sie sollten, mit nur ein paar Fragezeichen in einigen Attributen. Insbesondere die 78-*-RALPH.rules sollte weggeworfen werden; es ist nicht nützlich.

Ich glaube, ich kann daraus etwas herauslesen, bin mir aber nicht ganz sicher, wie das behoben werden soll. Grundsätzlich gibt es, wie ich es sehe, wenn der Dongle eingesteckt ist, eine Flut von udev-Ereignissen. Was ttyUSB1 betrifft, so gibt es ein „frühes“ Ereignis:

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

was den usb_serial verursacht zu ladender Treiber und /dev/ttyUSB1 erscheinen. Das verursacht insbesondere ein anderes 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 ModemManager aus . Sie müssen zu syslog gehen um Beweise dafür zu sehen, da es keine strikte Korrelation zwischen den Protokollen gibt. Das Ereignis hat den Zeitstempel 3867.435102 und syslog präsentiert den nächstfolgenden ModemManager log-Zeile direkt nach einer Kernel-Log-Zeile mit dem Stempel 3867.437412 .

Meiner Meinung nach ModemManager sollte noch nicht ausgelöst werden, sondern erst nach dem nachfolgenden ttyUSB1-Event:

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

die die ZTE-Attribute angehängt hat.

Im MM-Protokoll wären wir bei der Zeile mit dem Stempel 1449934745.363291 , der anscheinend eher ein „Echtzeit“-Zeitstempel als ein „Kernel-Zeit“-Stempel ist.

ModemManager dann ist die Vorabprüfung unter 1449934745.450398 abgeschlossen , d. h. 87 ms später, was in Bezug auf die Kernelzeit in der Nähe von 3867.524519 wäre und 55 ms vor diesem „guten“ UDEV-Ereignisbericht oben.

Beachten Sie das in syslog , ModemManager beschwert sich, dass ttyUSB1 hat keine gesetzten Attribute, und möglicherweise hängt diese Beschwerde mit der „Markierung“ in 80-mm-candidate.rules zusammen . Durch den Kommentar in dieser Datei scheint diese Markierung ein Versuch zu sein, genau dieses Problem zu lösen, aber wenn ja, scheint es in diesem Fall nicht zu funktionieren.

Vielleicht wäre eine Möglichkeit, dies zu lösen, die „tty“-Regel in 80-mm-candidate.rules zu ändern sein:

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

Meiner Meinung nach würde das sicherstellen, dass die ID_MM_CANDIDATE Die Einstellung wird verzögert, bis die ZTE-Attribute eingestellt sind. Der .ID_PORT Einstellung ist ein Effekt von 60-serial.rules Regel (genannt 60-persistent-serial.rules vorher), und die hinzugefügte Bedingung zur Markierungsregel ist einfach, dass sie einen Wert hat.

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

Im Allgemeinen bin ich mir bei udev nicht sehr sicher Regelreihenfolge, und ich bin mir auch überhaupt nicht sicher, ob dies wirklich ModemManager stoppt davon ab, zu schnell zu handeln. Wenn dies jedoch nicht der Fall ist, dann 80-mm-candidate.rules würde wenig bis gar keine Funktion haben, und vielleicht würde dann alles auf die „Verbesserungen“ von ModemManager hinauslaufen ab 15.04.

BEARBEITEN 21

seufzen. Wahrscheinlich irrelevant, aber Sie sollten Ihre 7-zte-mutil_port_device.rules überprüfen Datei; Ist das ein Überbleibsel von anderen Experimenten? Jedenfalls hier nicht relevant.

Zwischen 515.558184 liegt noch fast eine Sekunde und 516.381549 wobei ModemManager eagerly and erroneously grabs /dev/ttyUSB1 , and whilst complaining about it not being set up, still goes through pre-probing and discards the ZTE plugin. In other words, the rule patch doesn’t make ModemManager wait.

I suppose you also tested using ENV{.MM_USBIFNUM}="?*" instead of ENV{.ID_PORT}=="?*" .

Actually, to confirm whether or not setting ENV{ID_MM_CANDIDATE}=1 is of any importance, you should temporarily move away 80-mm-candidate.rules , then see (in syslog ) if then ModemManager ignores /dev/ttyUSB1 oder nicht. I suspect “not”.

And then, well, maybe you can use a working version, such as 14.04, and if you need, perhaps run 15.10 in a virtualbox, unless of course it’s already all is in a virtualbox.

I think I need to claim defeat at this point.