Erreur 'ip-config-unavailable' lorsque le modem USB essaie de se connecter ?

J'ai un modem ZTE MF-193E qui fonctionnait bien avant. Lorsque j'ai acheté ce modem il y a plus d'un an, il fonctionnait immédiatement.
Maintenant, à mesure que la version d'Ubuntu progresse, les choses deviennent de plus en plus difficiles pour moi.

Ce modem a même fonctionné il y a quelques mois avec Ubuntu 15.04 (64 bits). Maintenant, dans Ubuntu 15.10 (64 bits), il ne peut pas se connecter.

J'ai configuré une connexion haut débit mobile. J'ai essayé différentes chaînes pour APN, mais cela n'a pas été un problème auparavant.

(Le modem fonctionne bien sous Windows 10, il ne s'agit donc pas du tout d'un problème matériel. De plus, l'interface graphique de Modem Manager détecte bien ce périphérique. Les SMS peuvent être envoyés et reçus sans aucun problème.)

Lorsque j'insère le modem, il est bien détecté, une icône de CD s'affiche dans Unity avec le nom du modem. Quelques secondes plus tard,
je reçois une boîte de message

Mobile Broadband Network: you are registered on the home network

près de l'icône de réseau.

Lorsque j'essaie de me connecter, l'icône sans fil de l'applet du gestionnaire de réseau déclenche ces mouvements centrifuges, mais la connexion échoue finalement et un message m'indique que je suis hors ligne.

La ligne que j'ai pu isoler de /var/log/syslog est-ce,

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

Cependant, je ne suis pas sûr que ce soit le cas pertinent.

Plus de lignes de
/var/log/syslog peut être trouvé ici.

Mise à jour 1 – 06 décembre 2015

Comme l'a souligné un membre aimable, a essayé le nf_conntrack_pptp approche modulaire.

Exécuté les commandes suivantes,

$ 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

Puis j'ai essayé mon modem, même échec. Aucun changement perceptible dans le journal non plus.

Mise à jour 2 – 06 décembre 2015

Exécuté en tant que root,

systemctl restart network-manager.service

Aucune sortie à l'écran (terminal).

Le journal correspondant du point ci-dessus à une tentative de connexion à l'aide du modem peut être trouvé ici.

Mise à jour 3 – 06 décembre 2015

ofono installé puis réessayez le modem.

Veuillez consulter le journal ici.

Mise à jour 4 – 06 décembre 2015

Encore une fois exécuté en tant que root,

systemctl restart network-manager.service

Le journal correspondant du point ci-dessus à une tentative de connexion à l'aide du modem peut être trouvé ici.

Mise à jour 5 – 06 décembre 2015

Changement de tous les "refuser" en "autoriser" dans /etc/dbus-1/system.d/nm-dispatcher.conf .

J'ai essayé de me connecter. Pas de chance.

Quelques réseaux se connectent et se déconnectent avec une connexion Ethernet.

Suivi de sudo systemctl restart network-manager.service .

Débranchez et branchez le modem.

J'ai essayé de me connecter à nouveau. Ne se connecte pas.

Le journal est ici.

Mise à jour 6 – 06 décembre 2015

Exécuté

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

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

Impossible d'exécuter mm-test.py en raison de multiples erreurs. A trouvé le fichier à l'emplacement indiqué. Je l'ai obtenu sur https://github.com/openshine/ModemManager/blob/master/test/mm-test.py.

Les commandes ci-dessus sont quelque peu différentes de celles du Wiki.

Les fichiers journaux sont ici.

Mise à jour 7 – 07 décembre 2015

Exécuté à nouveau (après la modification suggérée dans /lib/udev/rules.d/40-usb_modeswitch.rules et redémarrer)

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

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

Le /var/log/syslog est également inclus.

Les fichiers journaux sont ici.

Mise à jour 8 – 08 décembre 2015

L'ensemble de journaux mis à jour est ici.

Mise à jour 9 – 08 décembre 2015

Test 1

Cette fois, l'ordinateur a démarré à partir d'un DVD Ubuntu 14.04 32 bits. Dès que l'ordinateur a démarré, a commencé à capturer le journal MM.
Inséré le modem. lsusb a montré qu'il était reconnu comme un appareil
19d2:1232 qui doit être remplacé par un appareil 19d2:2003
. Étant donné que l'installation de usb-modeswitch nécessite le redémarrage de la
machine (et donc la perte de l'installation pour l'exécution du DVD), j'ai préparé un
fichier de commutateur personnalisé et commuté le modem à partir de la ligne de commande (sudo usb_modeswitch -I -c 19d2:2003 ).
Dès que la commutation a été effectuée, j'ai été informé que j'étais
sur le Mobile Broadband Network et une nouvelle connexion haut débit s'affiche
dans le menu du gestionnaire de réseau.
J'ai configuré la connexion ci-dessus de la manière habituelle (le nom APN n'était pas
un problème), et la connexion a été établie automatiquement.
J'ai déconnecté et éjecté le modem.
Arrêt de la capture du journal MM.

Le journal MM complet et le journal système pour le démarrage de la session jusqu'à l'éjection du modem peuvent être trouvés ici.

Test 2

Le même test avec un DVD Ubuntu 14.04 64 bits.

Les journaux peuvent être trouvés ici.

Mise à jour 10 – 09 décembre 2015

Cette fois testé avec wvdial et trouvé que si wvdial est exécuté en tant que root,
nous obtenons un succès connexion.

Le wvdial conf et log, et le syslog correspondant sont ici

Conjecture principale :la situation pourrait avoir quelque chose à voir avec le groupe d'utilisateurs de l'utilisateur correspondant.

Mais comme indiqué ici,

Avec tous ces outils, pour établir une connexion par modem, l'utilisateur doit
être membre des groupes "dip" et "dialout", donc mettez tous les utilisateurs qui
sont censés se connecter via un modem dans ces groupes .

Mais comme nous pouvons le constater,

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

Ainsi, l'utilisateur est déjà
membre des groupes indiqués.

Maintenant, peut-être que le problème se résume à l'un ou l'autre de ces points,

À quel groupe supplémentaire l'utilisateur doit-il appartenir ?
Comment exécutons-nous le processus de configuration de la connexion haut débit mobile en tant qu'utilisateur racine ? (problèmes de sécurité ?)

Mise à jour 11 – 09 décembre 2015

wvdial fonctionne avec USB3 et pas fonctionne avec USB1.

Veuillez trouver le journal système ici.

La sortie de dmesg | grep tty > /tmp/dmesg.tty.txt . Mais voyez-vous ces quatre lignes près du début du fichier ?

Mise à jour 12 – 10 décembre 2015

Ligne 4 commentée (SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end" ) dans /lib/udev/rules.d/77-mm-zte-port-types.rules .
J'ai redémarré ma machine. Soft a déconnecté le câble et inséré le modem.
J'ai essayé de me connecter. Échec.

Le fichier syslog est ici.

Mise à jour 13 – 10 décembre 2015

En désespoir de cause, pour voir si certains changements locaux affectent la connexion, testez la machine avec les DVD Ubuntu 15.04 et 15.10.

Démarré la machine avec le DVD Xubuntu 15.04 64 bits. La connexion a réussi comme un charme.
Démarré la machine avec le DVD Ubuntu 15.10 64 bits. La connexion a échoué comme avant.

Que s'est-il passé entre le 15.04 et le 15.10 ?

Tellement frustrant.

Mise à jour 14 – 10 décembre 2015

Création d'un nouveau fichier /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules comme indiqué dans la réponse.
Redémarré ma machine (ou exécuté sudo udevadm control --reload , en fait essayé les deux). Inséré le modem.

Le modem a été reconnu.

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

Soft a déconnecté le câble et a essayé de se connecter à l'aide du modem. Échec.
A éjecté le modem.

La machine se bloque une fois, est-ce un événement aléatoire ? Ma machine ne se bloque généralement pas
une fois par an.

Le fichier syslog et les fichiers de règles créés sont ici.

Mise à jour 15 – 11 décembre 2015

Ajout des lignes suivantes à /lib/udev/rules.d/40-usb_modeswitch.rules .

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

A laissé le fichier /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intacte.
J'ai redémarré ma machine. Inséré le modem.

Le modem a été reconnu.

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

Soft a déconnecté le câble et a essayé de se connecter. Échec.
A éjecté le modem.
Suppression de /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules .
Redémarré et réessayé tout le processus. Échec à nouveau.

Le fichier syslog (complet, je n'ai pas pris le risque de manquer une partie
importante) et le fichier de règles mentionné (40) sont ici.

Mise à jour 16 – 11 décembre 2015

A laissé une seule règle 1232 dans
/lib/udev/rules.d/40-usb_modeswitch.rules , a supprimé l'autre
.
sudo udevadm control --reload exécuté .
Inséré le modem.

Le modem a été reconnu.

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

Soft a déconnecté le câble et a essayé de se connecter. Échec.
A éjecté le modem.

Mais n'avons-nous pas testé le système par défaut ci-dessus ? Vouliez-vous quitter /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules à sa place ?

Le fichier syslog (complet, je n'ai pas pris le risque de manquer une partie
importante) et le fichier de règles mentionné (40) sont ici

Mise à jour 17 – 11 décembre 2015

Mise en commentaire de la règle 1232 dans
/lib/udev/rules.d/40-usb_modeswitch.rules , en a ajouté un pour 2003.

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

sudo udevadm control --reload exécuté .
Inséré le modem.
Le modem a été reconnu comme un 1232 appareil. On ne me propose pas d'essayer de me connecter (pour autant que je sache, il ne sera pas enregistré sur le réseau haut débit à moins que la commutation ne se soit produite en 2003)
```
Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
```
A éjecté le modem.

Connexe :mise à niveau de 15.10 à 16.04 apt non installé ?

Le fichier syslog et le fichier de règles mentionné (40) sont ici

Mise à jour 18 – 11 décembre 2015

Mettez tous les fichiers de règles dans leur forme d'origine.
lsusb regardé sortie toutes les secondes à l'aide d'un script shell
. Sortie capturée dans des fichiers horodatés.
Inséré le modem. (Le modem apparaît d'abord dans le fichier
lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt ). Comme nous pouvons le constater
à partir des captures, il est clair qu'il passe d'un appareil 1232 à
un appareil 2003.
J'ai essayé de me connecter. Échec.
A éjecté le modem.

Le fichier syslog, horodaté lsusb les sorties et les fichiers de règles mentionnés sont ici.

Maintenant, vous pouvez faire correspondre les sorties syslog avec les horodatages.

Mise à jour 19 – 11 décembre 2015

J'ai effectué ce test dans une toute nouvelle direction en souhaitant
pouvoir isoler les problèmes.

Enregistré dans un support portable /lib/udev/rules.d/40-usb-media-players.rules et /lib/udev/rules.d/77-mm-zte-port-types.rules (depuis la machine Ubuntu 15.10).
Démarrage de la machine à l'aide du DVD Xubuntu 15.04 64 bits.
Exécuté diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt . Le premier fichier est celui enregistré
à partir du 15.10.

L'examen du fichier diff ne montre aucun idProduct 1232 ou 2003.
Exécuté diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt . Encore une fois, le premier fichier provient de celui
enregistré à partir de la version 15.10.

Encore une fois, l'examen du fichier diff ne montre aucun idProduct 1232 ou 2003.

Inséré le modem. Le modem a été reconnu comme modem.

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

Pourrait se connecter facilement après avoir configuré une connexion haut débit mobile.
A éjecté le modem.
Installé le dernier USB_ModeSwitch.
```
diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
```
Renvoie maintenant NULL, comme prévu.
sudo udevadm control --reload-rules exécuté .

Inséré le modem. Le modem a été reconnu comme modem.

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

Pourrait se connecter facilement.

J'aurais pu essayer de mettre à niveau MM et NM vers celui d'Ubuntu 15.10, juste pour voir où ça se casse. En fait, j'ai essayé mais j'ai abandonné en raison de problèmes de dépendance sans fin.

Tous les fichiers diff mentionnés ci-dessus sont ici.

Mise à jour 20 – 12 décembre 2015

Test 1

Le /lib/udev/rules dans son état d'origine.
Le périphérique modem n'a pas encore été inséré dans cette session.

Configurez ModemManager pour le débogage et configurez la capture udevadm.

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

Branché le modem et attendu jusqu'à ce qu'il dise qu'il est enregistré sur le réseau à large bande.
Tentative de connexion infructueuse.
A éjecté le modem.
Fichiers journaux emballés.

Test 2

Répété le test ci-dessus avec
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules en place.

Les noms des fichiers journaux sont explicites.

Tous les fichiers journaux ci-dessus ainsi que syslog et les 78 fichiers de règles se trouvent
ici.

J'aimerais que tous les fichiers journaux soient accompagnés d'horodatages, ce qui faciliterait la correspondance.

Mise à jour 21 – 15 décembre 2015

Modifié le fichier de règles comme suggéré.
J'ai redémarré ma machine.
A inséré le modem et essayé de se connecter. Cela n'a pas fonctionné.

Le fichier de règles et le syslog sont ici.

Mise à jour 22 – 16 décembre 2015

Comme conseillé dans un commentaire, j'ai installé plusieurs noyaux à partir de
http://kernel.ubuntu.com/~kernel-ppa/mainline/ et j'ai essayé de me connecter
à l'aide du modem après le démarrage de chacun.

4.2.8-040208-générique, échec.
4.1.15-040115-générique, échec.
4.0.9-040009-générique, échec.

Donc, peut-être pouvons-nous exclure le problème du noyau.

Mise à jour 23 – 16 février 2016

Le modem a commencé à fonctionner dans Ubuntu 16.04. Cette version est toujours en Alpha 1, mais fonctionne bien sur mon ordinateur portable.

Réponse acceptée :

Chargement du ofono Le package a probablement bien fonctionné, mais apparemment, votre modèle de modem, ZTE MF193E, ne figure pas sur la liste ZTE. En le comparant à d'autres modems ZTE, par exemple MF190J, ce modem aura probablement besoin du même udev spécial règle, pour exécuter usb_modeswitch lorsque le dongle est inséré, et pour cela vous pouvez, en tant que root, ajouter un nouveau udev rule dans le fichier
/lib/udev/rules.d/40-usb_modeswitch.rules
avec les deux lignes suivantes, par exemple quelque part près du # ZTE MF190J commentaire :

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

plus une ligne vide, pour que cela paraisse agréable à l'œil.

Il est probablement sage de redémarrer après cela, seulement pour constater que tout fonctionne comme par magie 🙂

Ou pas. Comme vous le savez, c'est une eau profonde pour moi, mais si cela ne fonctionne toujours pas, un autre journal de débogage de ModemManager serait nécessaire, pour une autre supposition folle.

MODIFIER :

Je regarde maintenant les deux lignes dans modemmanager.txt :

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

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

Je suppose que le premier fait référence à votre configuration haut débit, tandis que le second fait référence à la liaison interne à un "contexte PDP" (quel qu'il soit). Apparemment, le modem propose 9 contextes alternatifs, dont un avec apn='WAP' , mais le ModemManager se contente d'une correspondance insensible à la casse.

La différence de casse pourrait être la cause du problème suivant :par exemple, que ppp veut un 'wap' configuration (plutôt que 'WAP' ) et ne le trouve pas, ou que l'extrémité distante attend apn='WAP' , mais obtient "wap" sur lequel il s'étouffe.

La première option pourrait facilement être testée (et probablement écartée) en modifiant votre configuration pour utiliser « wap » au lieu de « WAP ». Vous avez peut-être déjà essayé cela auparavant, mais à ce moment-là sans le ofono package, donc un autre test ne fera pas de mal, bien que la deuxième option soit plus probable.

La deuxième option est également plus problématique, étant donné qu'il existe une correspondance de «contexte PDP» en majuscule disponible à partir du modem. En cherchant sur Google ce problème, il semble que la correspondance insensible à la casse soit correcte par la spécification (apparemment pertinente) "3GPP TS 23.003 chapitre 9.1", et un correctif pour ce faire a été ajouté à ModemManager en novembre de l'année dernière (dans sa version mm-1-4, je peux comprendre). Donc, dans ce cas, votre modem n'a pas été informé et il attend une correspondance sensible à la casse, tandis que ModemManager utilise malheureusement la correspondance insensible à la casse plutôt que comme solution de rechange.

Une solution pour le deuxième problème est bien sûr d'utiliser un autre ModemManager :soit en trouvant et en installant une version antérieure à ce correctif, soit (avec suffisamment de temps libre), lancez votre propre ModemManager . Mais ce n'est pas non plus quelque chose à faire sur un coup de tête, alors peut-être que nous devons parcourir un peu pour obtenir plus de preuves que c'est (maintenant) le problème, et si possible trouver d'autres moyens de le contourner. Ou avec un peu de chance, quelqu'un qui sait quelque chose passe…

MODIFIER 2

Oui, la restauration de version n'est pas facile en raison des dépendances. Et rouler le vôtre est loin d'être une joie aussi.

Deux outils utiles possibles :commande mmcli et
(http://m2msupport.net/m2msupport/module-tester/).

Le problème, je pense, est que ModemManager choisit le contexte PDP 1 avec apn='wap' là où il devrait choisir le contexte PDP 9 avec apn='WAP'. Peut-être que cela peut être résolu en utilisant l'un de ces outils. Soit pour pouvoir forcer une sélection de 9 lors de la connexion, soit en supprimant les mauvais contextes "wap" du modem, ce dont l'outil testeur de module est annoncé capable.

L'outil testeur de modem semble être un outil java dans le navigateur, vous avez donc besoin que votre navigateur soit configuré pour savoir où se trouve votre java, et vous avez besoin que java soit connu. Veuillez alors explorer cette approche; Je ne l'ai pas utilisé moi-même, mais en voyant les captures d'écran, je suppose qu'il présentera les contextes PDP sous l'onglet "Appels de données", où vous prenez d'abord note de tout ce qu'il affiche, puis modifiez les entrées "wap" pour déformer les étiquettes apn 'wap' pour qu'elles soient, par exemple, 'wap1' et 'wap2' (afin de les "masquer" lors de la recherche de 'WAP'). Ensuite, enregistrez et fermez, et jonglez à nouveau avec le dongle. Prenez un journal; il semble que syslog soit suffisant maintenant, au cas où il refuserait toujours de jouer.

Le mmcli command semble également utile dans cette histoire; faire man mmcli lire à ce sujet, mais je n'y ai rien vu sur les contextes PDP.

EDIT 3

Bon appel! à tester à partir du DVD. Cela nous a dit que je suis sur la mauvaise voie avec l'APN, et que tout réside dans l'apparition de ppp. Au moins, ce serait mon nouvel arbre à aboyer.

Connexe :Logiciel pour trouver la consommation d'énergie du bureau ?

Tout d'abord, nous prenons note qu'il existe une différence de version pour pppd (de 2.4.5 à 2.4.6), mais ce n'est probablement pas un problème, car alors tout le monde sur un dongle aurait été sur cette excursion.

Hum, ppp ; J'ai besoin de remuer mes souvenirs du dernier millénaire :-). Malheureusement, je suis occupé aujourd'hui, mais je vous rappellerai la prochaine fois que j'aurai le temps, pour voir où vous en êtes. Mes premières ruelles à examiner seraient :1) l'utilisateur est-il dans le bon groupe ? 2) les informations d'identification sont-elles correctes ? 3) est-ce que le mod du fichier de configuration ppp/chat est correct ? Le journal de débogage ppp sort dans nm.txt (comme il y a quelques jours), mais il devrait également y avoir un moyen de lui demander une journalisation plus détaillée.

MODIFIER 4

Assurez-vous que /etc/ppp/pap-secrets et /etc/ppp/chap-secrets avoir le groupe dip (en utilisant chgrp selon besoin) et mode 740 (ou -rw-r----- ) (en utilisant chmod comme requis). Le mien ne l'a pas fait.

MODIFIER 5

Que diriez-vous de cet arbre, alors :Comparer le travail wvdial syslog avec syslog qui ne fonctionne pas, il semble que pour une raison quelconque wvdial utilisé ttyUSB3 tandis que le ModemManager ne fonctionne pas continue d'utiliser ttyUSB1 . Je ne sais pas si c'est du tout significatif, mais apparemment mais ttyUSB1 et ttyUSB3 les deux répondent en tant que modems compatibles AT.

Donc, à titre de test, vous pouvez peut-être modifier /etc/wvdial.conf donc sous [Dialer Defaults] inclut la ligne :

Modem = /dev/ttyUSB1

pour le seul test, et ttyUSB3 pour un autre; tous deux exécutés en tant que root ; juste pour voir s'il y a un comportement différent. Surtout, si vous utilisez ttyUSB1 est un problème alors que l'utilisation de ttyUSB3 ne l'est pas, alors il serait bon d'examiner comment faire en sorte que ModemManager utilise également ttyUSB3. Pour tout autre résultat de test, je dirais que nous recommencerons à chasser les furets dans les terres ppp.

MODIFIER 6

Le journal dmesg peut être ignoré je pense; c'est comme ça dans tous les journaux.
Le nouveau syslog ne montre que le test ttyUSB3, mais peut-être pouvons-nous supposer que la vie s'améliore si NetworkManager on peut apprendre à utiliser ttyUSB3 et ignorer ttyUSB1 (pour ce modem).

J'ai aussi trouvé (https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784) avec surtout le post #10 déconcertant 🙁

Le udev apparemment applicable règle dans /lib/udev/rules.d/77-mm-zte-port-types.rules ne s'applique pas, mais serait censé être où aller. Et, avec seulement un aperçu très rudimentaire, pré-101 dans le udev magie, j'envisagerais de toute façon de remettre en cause sa 4ème ligne, qui dit :

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

Je pense que cette ligne a besoin d'un # initial afin d'être commenté. Dans le détail, ma lecture du fichier est qu'il nécessite un état d'appel de SUBSYSTEM==”tty” et SUBSYSTEMS="usb" afin d'utiliser les bons bits, y compris les règles du produit "2003", et au moins pour les tests, il devrait être prudent d'ignorer le filtrage "tty". Et je n'ai rien de mieux en ce moment.

MODIFIER 7

Après avoir passé du temps de qualité avec mon moteur de recherche préféré, je crois un peu plus que le choix ttyUSB est un problème racine ici. La règle udev que j'ai pointée est correcte, et vous devriez annuler cette modification.

Cependant, j'ai commencé à croire que les règles de configuration vers la fin de ce fichier, pour l'identifiant de produit "2003", sont trompeuses. D'après les journaux, il me semble que l'identifiant de produit "2003" est en fait le côté périphérique de mémoire du dongle, tandis que le côté modem a l'identifiant de produit "1232". Vous pouvez tester cela en reproduisant les deux règles "2003" pour l'ID de produit "1232", dans le fichier /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"

ou mieux, ajoutez un nouveau fichier à côté, par ex. nommé 78-ralph.rules , mais vous devez également ajouter la protection SUBSYSTEM et SUBSYSTEMS autour d'elle.

Ensuite, retirez le dongle, exécutez udevadm control --reload (ou redémarrez) et insérez le dongle. Et puis encore un autre syslog capture, à moins que cela ne fonctionne maintenant.

Le problème effectif, cependant, est que ModemManager supprime le plugin libmm-plugin-zte.so lors de la pré-vérification, et finit par utiliser un gestionnaire de modem générique. Si j'ai raison à propos de l'identifiant du produit, cela pourrait être la raison ; ce test préalable recherche un ID_MM_ZTE_PORT_TYPE_MODEM attribution, et cela manque pour l'identifiant de produit "1232" (avant le patch), avec pour effet que le plugin zte est supprimé.

MODIFIER 8

Le syslog log est un peu court; manque le début où ModemManager ne parvient pas à installer le plugin zte. Cependant, il est clair que le plug-in de modem générique est utilisé de toute façon. Maintenant, il se peut que le usb_modeswitch la règle que je vous ai donnée au début est également fausse ; il décide de passer à "2003" quand j'ai pensé qu'il avait changé de "2003". Mais, man usb_modeswitch (que j'aurais dû regarder avant) suggère en quelque sorte qu'il passe à un identifiant de produit plutôt que de ce. Dans tous les cas, le journal indique que cela se produit. Par conséquent, veuillez modifier cette règle pour utiliser "1232" à la place, et réessayez.

Si rien d'autre, je dois au moins en apprendre un peu plus sur udev.

ÉDITION 9

Bon. Le problème est toujours (ou aussi) que ModemManager abandonne le plugin ZTE lors du pré-test. Les journaux de débogage de ModemManager pour 15.10 (jeux de journaux "debuglogs*") racontent tous que le plug-in ZTE a été supprimé en raison du test de l'identifiant du fournisseur/de l'identifiant du produit.

Allez à la source, Luke ! J'en ai profité pour voir brièvement le code source de ModemManager, et il indique que le plugin est une table de vid/pid qui n'inclut pas 19d2/2003… cependant, je n'ai pas trouvé cette source de table, donc je ne pouvais pas vérifier.

Ou peut-être y a-t-il un problème de timing ici. Par exemple, que le ModemManager exécute une pré-vérification alors que le périphérique est 19d2/1232. Cette pensée est alignée sur l'observation selon laquelle le fait d'avoir les règles udev 78-mm-zte-port-types-RALPH.rules rend ModemManager un peu plus heureux avec l'appareil. Mais alors, pourquoi ne reste-t-il pas heureux et n'utilise-t-il pas ce plugin lorsque l'appareil passe à 19d2/2003 ?

Peut-être que plus de journaux sont nécessaires 🙂 Avec ModemManager débogué, et aussi une capture de la commande udevadm monitor --e |& tee udevadm.log (dans un autre terminal) lorsque vous branchez l'appareil. J'ai reçu cette commande de (https://wiki.ubuntu.com/DebuggingUdev)

Faites ceci deux fois :une fois sans 78-mm-zte-port-types-RALPH.rules et une fois avec les règles… les deux fois à partir d'un nouveau redémarrage. C'est-à-dire

configurer /lib/udev/rules.d avec ou sans les *-RALPH.rules fichier
retirez l'appareil
redémarrer
configurer ModemManager pour le débogage et configurer la capture udevadm
branchez l'appareil et attendez une minute
compressez les fichiers journaux
répéter à partir de 1 avec le test suivant

Cette journalisation devrait indiquer où le plug-in ZTE est déposé et, si j'ai bien compris, elle indiquera également la gestion des événements udev.

MODIFIER 10

(Je suis presque à bout de souffle ici, mais il me reste encore une ou deux respirations :-)

Tout d'abord, tous les udev les décorations semblent se terminer comme elles le devraient, avec seulement quelques points d'interrogation dans quelques attributs. En particulier, les 78-*-RALPH.rules devrait être jeté; ce n'est pas utile.

Je pense que je peux lire quelque chose à partir de cela, mais je ne sais pas exactement comment cela devrait être corrigé. Fondamentalement, comme je le vois, lorsque le dongle est branché, il y a une rafale d'événements udev. En se concentrant sur ceux concernant ttyUSB1, il y a un événement "précoce":

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

qui provoque le usb_serial pilote à charger, et /dev/ttyUSB1 apparaître. Cela provoque notamment un autre événement :

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

Je pense que cela déclenche également ModemManager . Vous devez aller dans syslog pour en voir la preuve, car il n'y a pas de corrélation stricte entre les journaux. L'événement est horodaté 3867.435102 , et syslog présente son ModemManager suivant le plus proche log ligne juste après une ligne de journal du noyau estampillée 3867.437412 .

Dans ma ligne de pensée, ModemManager ne doit pas encore être déclenché, mais seulement après l'événement ttyUSB1 suivant :

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

auquel sont attachés les attributs ZTE.

Dans le log MM, nous serions à la ligne estampillée 1449934745.363291 , qui est apparemment un horodatage "en temps réel" plutôt qu'un horodatage "noyau".

ModemManager puis se fait avec son pré-test à 1449934745.450398 , c'est-à-dire 87 ms plus tard, ce qui, en termes de temps du noyau, serait proche de 3867.524519 et 55 ms avant le "bon" rapport d'événement UDEV ci-dessus.

Notez que dans syslog , ModemManager dépose des plaintes que ttyUSB1 n'a pas ses attributs définis, et peut-être que cette plainte est liée au "marquage" qui se produit dans 80-mm-candidate.rules . D'après le commentaire dans ce fichier, ce marquage semble être une tentative de traiter exactement ce problème, mais si c'est le cas, cela ne semble pas fonctionner dans ce cas.

Connexe :système de fichiers en lecture seule après la mise à niveau vers 15.04 avec ?

Peut-être qu'une possibilité pour résoudre ce problème serait de changer la règle "tty" dans 80-mm-candidate.rules être :

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

Dans mon esprit, cela garantirait que le ID_MM_CANDIDATE le réglage est retardé jusqu'à ce que les attributs ZTE soient définis. Le .ID_PORT le paramètre est un effet d'un 60-serial.rules règle (appelée 60-persistent-serial.rules avant), et la condition ajoutée à la règle de marquage est simplement qu'elle ait une valeur.

La condition n'est pas exactement un attribut ZTE, uniquement pour garder la règle plus générique. Une étape plus spécifique serait plutôt d'exiger ENV{.MM_USBIFNUM}="?*" à la place, puisque cette affectation se produit ici par 77-mm-zte-port-types.rules .

En général, je ne suis pas très sûr de udev l'ordre des règles, et je ne suis pas du tout sûr non plus que cela arrête vraiment ModemManager d'agir trop vite. Cependant, si ce n'est pas le cas, alors 80-mm-candidate.rules aurait peu ou pas de fonction, et peut-être que tout se résumerait alors aux "améliorations" de ModemManager à partir du 15.04.

MODIFICATION 21

soupir. Probablement non pertinent, mais vous voudrez peut-être vérifier votre 7-zte-mutil_port_device.rules dossier; est-ce un vestige d'une autre expérimentation? Quoi qu'il en soit, pas pertinent ici.

Il reste encore presque une seconde entre 515.558184 et 516.381549 où ModemManager saisit avidement et par erreur /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 ou pas. 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.