Erreur «ip-config-non disponible» lorsque le modem USB tente 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 a fonctionné immédiatement. Maintenant, comme Ubuntu progresse en version, 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 dans Windows 10, donc ce n'est pas du tout un problème matériel. De plus, l' interface graphique du gestionnaire de modem détecte bien cet appareil. 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 du réseau.

Lorsque j'essaye de me connecter, l'icône sans fil dans l'applet du gestionnaire de réseau démarre ces mouvements centrifuges, mais finalement il ne parvient pas à se connecter et un message me dit que je suis hors ligne.

La ligne que je pourrais isoler /var/log/syslogest la suivante,

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.

Plus de lignes /var/log/syslogpeuvent être trouvées ici .

Mise à jour 1 - 06 décembre 2015

Comme l'a souligné un membre aimable, a essayé l' nf_conntrack_pptpapproche du module.

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

Ensuite, j'ai essayé mon modem, le 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

Pas de 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

Installé ofonopuis réessayé 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

Tout "refuser" a été remplacé par "autoriser" dans /etc/dbus-1/system.d/nm-dispatcher.conf.

Connexion éprouvée. Pas de chance.

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

Suivi par sudo systemctl restart network-manager.service.

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

Réalisé

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

et

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

Impossible de s'exécuter en mm-test.pyraison de plusieurs erreurs. J'ai 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 /lib/udev/rules.d/40-usb_modeswitch.ruleset le redémarrage)

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

et

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

Le /var/log/syslogest également inclus.

Les fichiers journaux sont ici .

Mise à jour 8 - 08 décembre 2015

Le jeu de journaux mis à jour est ici .

Mise à jour 9 - 08 décembre 2015

Test 1

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.

2. Inséré le modem. lsusba montré qu'il était reconnu comme un périphérique 19d2: 1232 qui doit être remplacé par un périphérique 19d2: 2003. Étant donné que l'installation de usb-modeswitch nécessite un redémarrage de la machine (et donc perdre l'installation pour l'exécution du DVD), j'ai préparé un fichier de commutation personnalisé et basculé le modem à partir de la ligne de commande ( sudo usb_modeswitch -I -c 19d2:2003).

3. Dès que la commutation a été effectuée, j'ai été informé que j'étais Mobile Broadband Networkallumé et une nouvelle connexion à large bande appreard dans le menu du gestionnaire de réseau.

4. 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.

5. J'ai déconnecté et éjecté le modem.

6. Arrêt de la capture du journal MM.

Le journal MM complet et le journal système du démarrage de la session pour l'éjection du modem se trouvent 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 wvdialet constaté que si wvdialest exécuté en tant que root, nous obtenons une connexion réussie .

La wvdialconf et le journal, 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 ligne commutée, l'utilisateur doit être membre des groupes "dip" et "dialout", alors mettez tous les utilisateurs qui sont censés se connecter via dialup 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 de ces points,

1. De quel groupe supplémentaire l'utilisateur doit-il être?
2. Comment exécuter le processus de configuration de la connexion haut débit mobile en tant que root? (les problèmes de sécurité?)

Mise à jour 11 - 09 décembre 2015

wvdialfonctionne avec USB3 et ne fonctionne pas avec USB1.

Veuillez trouver le syslog ici .

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

Mise à jour 12 - 10 décembre 2015

1. A commenté la ligne 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") dans /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Redémarrage de ma machine. Soft a déconnecté le câble et inséré le modem.

3. J'ai essayé de me connecter. Infructueux.

Le fichier syslog est ici .

Mise à jour 13 - 10 décembre 2015

Par désespoir, pour voir si certains changements locaux affectent la connexion, a testé la machine avec des DVD Ubuntu 15.04 et 15.10.

1. Démarrage de la machine avec Xubuntu 15.04 DVD 64 bits. La connexion a réussi comme un charme.
2. Démarrage de la machine avec Ubuntu 15.10 DVD 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

1. Créé un nouveau fichier /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulescomme indiqué dans la réponse.

2. Redémarré ma machine (ou exécuté sudo udevadm control --reload, en fait essayé les deux). Inséré le modem.

3. Le modem a été reconnu.

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

4. Soft a déconnecté le câble et tenté de se connecter à l'aide du modem. Infructueux.

5. Éjecté le modem.

La machine se bloque une fois, est-ce un événement aléatoire? Ma machine ne pend 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

1. 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'"
   

2. Laissé le fichier /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesintact.

3. Redémarrage de ma machine. Inséré le modem.

4. Le modem a été reconnu.

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

5. Soft a déconnecté le câble et a tenté de se connecter. Infructueux.

6. Éjecté le modem.

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

8. Redémarré et réessayé tout le processus. Échec à nouveau.

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

Mise à jour 16 - 11 décembre 2015

1. N'a laissé qu'une seule règle 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, a supprimé l'autre.

2. Exécuté sudo udevadm control --reload.

3. Inséré le modem.

4. Le modem a été reconnu.

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

5. Soft a déconnecté le câble et a tenté de se connecter. Infructueux.

6. Éjecté le modem.

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

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

Mise à jour 17 - 11 décembre 2015

1. A commenté la règle 1232 en a /lib/udev/rules.d/40-usb_modeswitch.rulesajouté une pour 2003.

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

2. Exécuté sudo udevadm control --reload.

3. Inséré le modem.

4. Le modem a été reconnu comme un périphérique 1232 . On ne me propose pas d'essayer de me connecter (pour autant que je sache, il ne sera pas enregistré sur un réseau à large bande à moins que la commutation n'ait eu lieu en 2003)

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

5. Éjecté le modem.

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

Mise à jour 18 - 11 décembre 2015

1. Mettez tous les fichiers de règles dans leur forme d'origine.

2. lsusbSortie surveillée toutes les secondes à l'aide d'un script shell. Sortie capturée dans des fichiers horodatés.

3. 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.

4. J'ai essayé de me connecter. Infructueux.

5. Éjecté le modem.

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

Maintenant, vous voudrez peut-être 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 avec le souhait de pouvoir isoler les problèmes.

1. Enregistré dans un support portable /lib/udev/rules.d/40-usb-media-players.ruleset /lib/udev/rules.d/77-mm-zte-port-types.rules(depuis la machine Ubuntu 15.10).

2. Démarrage de la machine à l'aide du DVD Xubuntu 15.04 64 bits.

3. 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 de 15.10.

   L'examen du fichier diff ne montre aucun idProduct1232 ou 2003.

4. 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 15.10.

   Encore une fois, l'examen du fichier diff ne montre pas idProduct1232 ou 2003.

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

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

6. Pourrait se connecter facilement après avoir configuré une connexion haut débit mobile.

7. Éjecté le modem.

8. Installation de la dernière clé USB_ModeSwitch.

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

   Renvoie maintenant NULL, comme prévu.

9. Exécuté sudo udevadm control --reload-rules.

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

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

11. Pourrait se connecter facilement.

J'aurais pu essayer de mettre à jour 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

1. Le /lib/udev/rulesen état d'origine.

2. Le périphérique modem n'a pas encore été inséré dans cette session.

3. 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
   

4. Branché le modem et attendu qu'il indique qu'il est enregistré dans le réseau à large bande.

5. J'ai essayé de me connecter sans succès.

6. Éjecté le modem.

7. Fichiers journaux emballés.

Test 2

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

Les noms des fichiers journaux sont explicites.

Tous les fichiers journaux ci-dessus plus syslog et les 78 fichiers de règles sont ici .

Je souhaite que tous les fichiers journaux soient fournis avec des horodatages, ce qui facilite la correspondance.

Mise à jour 21 - 15 décembre 2015

1. Modification du fichier de règles comme suggéré.
2. Redémarrage de ma machine.
3. Inséré le modem et essayé de se connecter. Cela n'a pas fonctionné.

Le fichier de règles et le syslogsont ici .

Mise à jour 22 - 16 décembre 2015

Comme conseillé dans un commentaire, installé divers noyaux à partir de http://kernel.ubuntu.com/~kernel-ppa/mainline/ et essayé de se connecter en utilisant le modem après le démarrage de chacun.

1. 4.2.8-040208-générique, échec.

2. 4.1.15-040115-générique, échec.

3. 4.0.9-040009-générique, échec.

Donc, peut-être, nous pouvons 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 dans mon ordinateur portable.

Le chargement du ofonopaquet a bien fonctionné, probablement, mais apparemment, votre modèle de modem, ZTE MF193E, n'est pas sur la liste ZTE. En le comparant à d'autres modems ZTE, par exemple MF190J, ce modem aura probablement besoin de la même udevrègle spéciale , pour s'exécuter usb_modeswitchlorsque le dongle est inséré, et pour y parvenir, vous pouvez, en tant que root, ajouter une nouvelle udevrègle au fichier
/lib/udev/rules.d/40-usb_modeswitch.rules
avec les deux suivantes par exemple, quelque part près du # ZTE MF190Jcommentaire:

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

plus une ligne vierge, donc ça a l'air agréable à l'œil.

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

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

ÉDITER:

Je regarde maintenant les deux lignes dans modemmanager.txt:

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

et

[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). De par son apparence, le modem propose 9 contextes alternatifs, dont un avec apn='WAP', mais le se ModemManagercontente d'une correspondance insensible à la casse.

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

La première option pourrait facilement être testée (et exclue, probablement) en modifiant votre configuration pour utiliser «wap» au lieu de «WAP». Vous avez peut-être déjà essayé cela, mais à ce moment-là sans le ofonopaquet, 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 en «majuscule PDP context» disponible à partir du modem. Googler 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 cela a été ajouté ModemManageren novembre de l'année dernière (dans sa version mm-1-4, Je peux rassembler). Donc, dans ce cas, votre modem n'a pas été informé et il s'attend à une correspondance sensible à la casse, alors qu'il ModemManagerutilise 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 avant ce correctif, ou (avec suffisamment de temps libre), lancez la vôtre 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 façons de le contourner. Ou avec un peu de chance, quelqu'un qui sait que quelque chose passe ...

EDIT 2

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

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

Le problème, je pense, est que ModemManager choisit le contexte PDP 1 avec apn = 'wap' 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 être en mesure de forcer une sélection de 9 lors de la connexion, soit en supprimant les mauvais contextes «wap» du modem, dont l'outil de test de module est censé être capable.

L'outil de testeur de modem semble être un outil java dans le navigateur, vous devez donc configurer votre navigateur pour savoir où se trouve votre java, et vous avez besoin que java soit connu. Veuillez ensuite 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 noterez d'abord tout ce qu'il montre, puis modifiez les entrées «wap» dans déformer les étiquettes d'apn «wap» pour être, disons, «wap1» et «wap2» (afin de les «masquer» lorsque vous recherchez «WAP»). Ensuite, enregistrez et fermez, puis jonglez à nouveau avec le dongle. Prenez un journal; il semble que syslog soit suffisant maintenant, au cas où il refuserait de jouer.

La mmclicommande semble également utile dans cette histoire; faire man mmclipour lire à ce sujet, mais je n'ai rien vu sur les contextes PDP là-bas.

EDIT 3

Bon appel! pour 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'obtention de ppp. Au moins, ce serait mon nouvel arbre à aboyer.

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.

Hmm, ppp; J'ai besoin de remuer mes souvenirs du dernier millénaire :-). Malheureusement, je suis occupé aujourd'hui, mais je toucherai la base la prochaine fois que j'aurai le temps, pour voir jusqu'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 exactes? 3) Le mod du fichier de configuration ppp / chat est-il correct? Le journal de débogage de 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.

EDIT 4

Assurez /etc/ppp/pap-secrets- vous d' /etc/ppp/chap-secretsavoir le groupe dip(en utilisant chgrpau besoin) et le mode 740(ou -rw-r-----) (en utilisant chmodau besoin). La mienne non.

EDIT 5

Que diriez-vous de cet arbre, alors: En comparant le wvdialSyslog de travail avec Syslog non fonctionnel, il semble que pour une raison quelconque wvdialutilisé ttyUSB3alors que le non-fonctionnement ModemManagercontinue à utiliser ttyUSB1. Je ne sais pas si c'est important du tout, mais apparemment, mais ttyUSB1et les ttyUSB3deux répondent en tant que modems capables d'AT.

Donc, à titre de test, vous pouvez peut-être le modifier /etc/wvdial.confpour qu'il [Dialer Defaults]inclue la ligne:

Modem = /dev/ttyUSB1

pour un test et ttyUSB3pour un autre; les deux s'exécutant en tant que root; juste pour voir s'il y a un comportement différent. Surtout, si l'utilisation ttyUSB1est un problème alors que l'utilisation de ttyUSB3 ne l'est pas, alors il serait bon de voir comment faire pour que ModemManager utilise ttyUSB3 également. Pour tout autre résultat de test, je dirais que nous allons recommencer à chasser les furets en ppp.

EDIT 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 NetworkManageron peut penser à 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 :-(

La udevrègle apparemment applicable /lib/udev/rules.d/77-mm-zte-port-types.rulesne s'applique pas, mais serait censée être où aller. Et, avec seulement un aperçu très rudimentaire de la udevmagie avant 101 , j'envisagerais de toute façon de remettre en question sa quatrième ligne, qui dit:

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

Je pense que cette ligne a besoin d'une initiale #pour être commentée. En 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 de produit "2003", et au moins pour les tests, il devrait être sûr de sauter le filtrage "tty". Et je n'ai rien de mieux en ce moment.

EDIT 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 devez annuler cette modification.

Cependant, j'ai commencé à croire que les règles de configuration vers la fin de ce fichier, pour l'ID de produit "2003" sont trompeuses. D'après les journaux, il me semble que l'ID 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'ID de produit "1232". Vous pouvez tester cela en répliquant 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 exemple nommé 78-ralph.rules, mais vous devez également ajouter la protection SUBSYSTEM et SUBSYSTEMS autour de lui.

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

Le problème efficace, cependant, est que ModemManager supprime le plug-in libmm-plugin-zte.solors de la pré-vérification et finit par utiliser un gestionnaire de modem générique. Si j'ai raison sur l'ID du produit, cela pourrait être la raison; cette pré-recherche recherche une ID_MM_ZTE_PORT_TYPE_MODEMattribution, et cela manque pour l'ID de produit "1232" (avant le patch), avec pour effet que le plugin zte est supprimé.

EDIT 8

Le syslogjournal 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 la usb_modeswitchrègle que je vous ai donnée dès le début soit également erronée; il décide de passer à "2003" quand je pensais qu'il était passé de "2003". Mais, man usb_modeswitch(que j'aurais dû examiner auparavant) suggère en quelque sorte qu'il passe à un identifiant de produit plutôt qu'à partir de celui-ci. Dans tous les cas, le journal montre que cela se produit. Par conséquent, veuillez modifier cette règle pour utiliser "1232" à la place et réessayer.

Au moins, je dois au moins en apprendre un peu sur udev.

EDIT 9

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

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

Ou peut-être qu'il y a un problème de timing ici. Par exemple, que le ModemManager exécute une pré-sonde alors que le périphérique est 19d2 / 1232. Cette pensée est conforme à l'observation selon laquelle les règles udev de 78 mm-zte-port-types-RALPH.rules rendent ModemManager un peu plus satisfait de l'appareil. Mais alors, pourquoi ne reste-t-il pas heureux et utilise-t-il ce plugin lorsque l'appareil est passé à 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 obtenu cette commande de ( https://wiki.ubuntu.com/DebuggingUdev )

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

1. configuration /lib/udev/rules.davec ou sans le *-RALPH.rulesfichier
2. retirer l'appareil
3. redémarrer
4. configurer ModemManager pour le débogage et configurer la capture udevadm
5. branchez l'appareil et attendez une minute
6. emballer les fichiers journaux
7. répéter de 1 avec le prochain test

Cette journalisation devrait indiquer où le plugin ZTE est déposé, et si je comprends bien, cela indiquera également la gestion des événements udev.

EDIT 10

(Je suis presque au bout de ma longe ici, mais il me reste un ou deux respirations :-)

Tout d'abord, toutes les udevdécorations semblent finir comme elles le devraient, avec seulement quelques points d'interrogation dans quelques attributs. En particulier, ils 78-*-RALPH.rulesdevraient être jetés; ce n'est pas utile.

Je pense que je peux lire quelque chose 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 vague 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)

ce qui provoque le usb_serialchargement et l'affichage du pilote /dev/ttyUSB1. 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 vous rendre sur syslogpour voir des preuves de cela, car il n'y a pas de corrélation stricte entre les journaux. L'événement est horodaté 3867.435102et syslogprésente sa ModemManagerligne de journal suivante la plus proche juste après une ligne de journal du noyau estampillée 3867.437412.

Dans ma ligne de pensée, ModemManagerne devrait 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)

qui a attaché les attributs ZTE.

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

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

Notez que dans syslog, ModemManagerdépose des réclamations qui ttyUSB1n'ont pas ses attributs définis, et peut-être que cette réclamation est liée au "marquage" qui se produit dans 80-mm-candidate.rules. Par 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.

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

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

Dans mon esprit, cela garantirait que le ID_MM_CANDIDATEparamètre est retardé jusqu'à ce que les attributs ZTE soient définis. Le .ID_PORTparamètre est un effet d'une 60-serial.rulesrègle (appelée 60-persistent-serial.rulesavant), et la condition ajoutée à la règle de marquage est simplement qu'elle a 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 à la ENV{.MM_USBIFNUM}="?*"place, puisque cette affectation se produit ici 77-mm-zte-port-types.rules.

En général, je ne suis pas très sûr de l'ordre des udevrègles, et je ne suis pas du tout sûr que cela empêche vraiment ModemManagerd'agir trop rapidement. Cependant, si ce n'est pas le cas, 80-mm-candidate.rulescela aurait peu ou pas de fonction, et peut-être que tout se résumerait aux "améliorations" à ModemManagerpartir de la version 15.04.

EDIT 21

soupir. Probablement hors de propos, mais vous voudrez peut-être vérifier votre 7-zte-mutil_port_device.rulesfichier; est-ce un vestige d'une autre expérimentation? De toute façon, pas pertinent ici.

Il y a encore près d'une seconde entre 515.558184et 516.381549où ModemManagers'empare avidement et par erreur /dev/ttyUSB1, et tout en se plaignant de ne pas être configuré, passe toujours par la pré-vérification et rejette le plugin ZTE. En d'autres termes, le patch de règles ne fait pas ModemManagerattendre.

Je suppose que vous avez également testé en utilisant ENV{.MM_USBIFNUM}="?*"au lieu de ENV{.ID_PORT}=="?*".

En fait, pour confirmer si le réglage ENV{ID_MM_CANDIDATE}=1est important ou non , vous devez vous éloigner temporairement 80-mm-candidate.rules, puis voir (in syslog) s'il ModemManagerignore /dev/ttyUSB1ou non. Je soupçonne "non".

Et puis, eh bien, vous pouvez peut-être utiliser une version de travail, comme 14.04, et si vous en avez besoin, peut-être exécuter 15.10 dans une boîte virtuelle, à moins bien sûr que tout soit déjà dans une boîte virtuelle.

Je pense que je dois revendiquer la défaite à ce stade.

Le modem a commencé à fonctionner dans Ubuntu 16.04. Cette version est toujours en phase de développement, mais fonctionne très bien sur mon ordinateur portable.

J'aimerais pouvoir fournir plus de détails techniques sur la façon dont il a commencé à fonctionner.

Après avoir jeté un coup d'œil à cela, il semble que ce n'est pas la première fois que ce dragon est traité correctement. C'était un bug avant en 12.10 et 13.04 peut-être que le bug n'a jamais été corrigé ou qu'un nouveau patch a cassé quelque chose qui fonctionnait correctement auparavant.

J'espère que si je lis correctement vos spécifications techniques, je devrai vous indiquer cette direction (MF190J):

Le modem 3G (ZTE MF190J) nécessite toujours un réglage manuel.

Avez-vous essayé ceci:

 rfkill list up

puis faites ce script et exécutez-le:

 #/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

et cela pourrait bien fonctionner de cette façon.