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

Chargement de la ofono Le paquet a probablement bien fonctionné, mais apparemment votre modèle de modem, le ZTE MF193E, ne figure pas sur la liste ZTE. En le comparant à d'autres modems ZTE, par exemple le MF190J, il est probable que ce modem ait besoin des mêmes accessoires spéciaux. udev règle, pour exécuter usb_modeswitch lorsque le dongle est inséré, et pour cela vous pouvez, en tant que root, ajouter une nouvelle udev 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 vierge, pour que le tout soit 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, je suis en eaux profondes, mais si cela ne fonctionne toujours pas, un autre journal de débogage de ModemManager serait nécessaire, pour une autre hypothèse.

EDIT:

Je regarde maintenant les deux lignes dans modemmanager.txt :

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

y

[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 installation à large bande, tandis que le second fait référence à la liaison interne à un "contexte PDP" (quel qu'il soit). Apparemment, le modem offre 9 contextes alternatifs, dont un avec une adresse IP. apn='WAP' mais le ModemManager se contente d'une correspondance insensible à la casse.

La différence de cas peut être la cause du problème ultérieur : par exemple, que ppp veut une 'wap' (plutôt que 'WAP' ) et ne le trouve pas, ou que l'extrémité distante s'attend à ce que apn='WAP' mais il reçoit du "wap" qui l'étouffe.

La première option peut facilement être testée (et probablement exclue) en modifiant votre configuration pour utiliser "wap" au lieu de "WAP". Vous avez peut-être déjà essayé, mais à l'époque sans l'option ofono donc un autre test ne fera pas de mal, bien que la deuxième option soit plus probable.

La deuxième option pose également plus de problèmes, étant donné que le modem dispose d'une correspondance en majuscules avec le "contexte PDP". En cherchant sur Google, il apparaît que la correspondance insensible à la casse est correcte selon la spécification (apparemment pertinente) "3GPP TS 23.003 chapter 9.1", et qu'un correctif a été ajouté à l'article suivant ModemManager en novembre de l'année dernière (dans sa version mm-1-4, si j'ai bien compris). Donc dans ce cas, votre modem n'a pas été informé, et il s'attend à une correspondance sensible à la casse, alors que ModemManager utilise malheureusement la correspondance insensible à la casse directement plutôt que comme solution de rechange.

Une solution pour le second problème est bien sûr d'utiliser une autre ModemManager soit en trouvant et en installant une version antérieure à ce correctif, soit (avec suffisamment de temps libre) en créant sa propre version. ModemManager . Mais ce n'est pas non plus quelque chose que l'on peut faire sur un coup de tête, alors peut-être que nous devons naviguer 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 s'y connaît passe par là...

EDIT 2

Oui, le retour en arrière de la version n'est pas facile à cause des dépendances. Et rouler sa propre version est loin d'être une partie de plaisir.

Deux outils utiles possibles : la 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' alors qu'il devrait choisir le contexte PDP 9 avec apn='WAP'. Peut-être que cela peut être résolu en utilisant un de ces outils. Soit pour pouvoir forcer une sélection de 9 pendant la connexion, soit en supprimant les mauvais contextes 'wap' du modem, ce que l'outil module-tester est censé pouvoir faire.

L'outil de test de modem semble être un outil java dans le navigateur, donc vous devez configurer votre navigateur pour savoir où se trouve votre java, et vous avez besoin que ce java soit connu. Alors explorez 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 comme l'onglet 'Data Calls', où vous prenez d'abord note de tout ce qu'il montre, et ensuite éditez les entrées 'wap' pour déformer les étiquettes apn 'wap' pour qu'elles soient, disons, 'wap1' et 'wap2' (afin de les 'cacher' quand vous cherchez 'WAP'). Ensuite, sauvegardez et fermez, et recommencez à jongler avec le dongle. Prenez un journal ; il semble que syslog soit suffisant maintenant, au cas où il refuse toujours de jouer.

El mmcli semble également utile dans cette histoire ; faites man mmcli pour lire à ce sujet, mais je n'ai rien vu sur les contextes du PDP là-bas.

EDIT 3

Bien vu ! de 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 sera mon nouvel arbre sur lequel je pourrai aboyer.

Tout d'abord, nous notons qu'il y a 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 tous les utilisateurs de dongle auraient participé à cette excursion.

Hmm, ppp ; j'ai besoin de remuer mes souvenirs du dernier millénaire :-). Malheureusement, je suis occupé aujourd'hui, mais je vous contacterai la prochaine fois que j'aurai le temps, pour voir où vous en êtes. Mes premières pistes à explorer seraient les suivantes : 1) l'utilisateur est-il dans le bon groupe ? 2) Les informations d'identification sont-elles correctes ? 3) Les mods du fichier de configuration de ppp/chat sont-ils corrects ? Le journal de débogage de ppp sort dans nm.txt (comme il y a quelques jours), mais il devrait aussi y avoir un moyen de demander un journal plus détaillé.

EDIT 4

Assurer /etc/ppp/pap-secrets y /etc/ppp/chap-secrets avoir un groupe dip (en utilisant chgrp si nécessaire) et le mode 740 (o -rw-r----- ) (en utilisant chmod si nécessaire). Le mien ne l'a pas fait.

EDIT 5

Que diriez-vous de cet arbre, alors : En comparant le travail wvdial syslog avec un syslog qui ne fonctionne pas, il semble que pour une raison quelconque wvdial utilisé ttyUSB3 tandis que les non-travailleurs ModemManager continue à utiliser ttyUSB1 . Je ne sais pas si c'est important, mais apparemment ttyUSB1 y ttyUSB3 les deux répondent comme des modems compatibles AT.

Donc, comme un test, peut-être que vous pouvez éditer /etc/wvdial.conf donc sous [Dialer Defaults] comprend la ligne :

Modem = /dev/ttyUSB1

pour le premier 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. En particulier, si vous utilisez ttyUSB1 est un problème alors que l'utilisation de ttyUSB3 ne l'est pas, alors il serait bon de chercher comment faire en sorte que ModemManager utilise également ttyUSB3. Pour tout autre résultat de test, je dirais que nous allons retourner à la chasse aux furets dans le pays de 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 nous pouvons peut-être supposer que la vie s'améliore si NetworkManager On peut penser à utiliser ttyUSB3 et ignorer ttyUSB1 (pour ce modem).

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

L'apparemment applicable udev la règle en /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 de la udev magique, j'envisagerais de toute façon de remettre en question sa 4ème ligne, qui dit :

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

Je pense que cette ligne a besoin d'une initiale # afin d'être commenté. 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 bonnes parties, 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 pour le moment.

EDIT 7

Après avoir passé un peu de temps avec mon moteur de recherche préféré, je crois un peu plus que le choix de ttyUSB est un problème de base ici. La règle udev que j'ai indiquée est correcte, et vous devriez revenir sur 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é dispositif de mémoire du dongle, alors que le côté modem a l'id de produit "1232". Vous pouvez tester cela en reproduisant les deux règles "2003" pour l'identifiant 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é de celui-ci, par exemple nommé 78-ralph.rules mais vous devez également ajouter la protection du SUBSYSTEM et des SUBSYSTEMS autour de lui.

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

Le problème réel, cependant, est que ModemManager rejette le plugin libmm-plugin-zte.so lors de la vérification préalable, et finit par utiliser un gestionnaire de modem générique. Si j'ai raison au sujet de l'identifiant du produit, alors cela pourrait être la raison ; que le pré-probing recherche un ID_MM_ZTE_PORT_TYPE_MODEM et cela manque pour l'id de produit "1232" (avant le patch), avec pour effet que le plugin zte est écarté.

EDIT 8

El syslog Le journal est un peu court ; il manque le début où ModemManager ne parvient pas à installer le plugin zte. Cependant, il est clair que le plugin 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 erronée ; elle décide d'échanger à "2003" quand je pensais qu'il avait changé de "2003". Mais, man usb_modeswitch (que j'aurais dû regarder avant) suggèrent en quelque sorte qu'il déplace à un identifiant de produit plutôt que de ça. En tout cas, le journal montre que cela s'est produit. Veuillez donc modifier cette règle pour utiliser "1232" à la place, et réessayez.

Au moins, j'ai pu apprendre un peu plus sur udev.

EDIT 9

Bien. Le problème est toujours (ou aussi) que ModemManager laisse tomber le plugin ZTE lors du pré-sondage. Les journaux de débogage de ModemManager pour 15.10 (ensembles de journaux "debuglogs*") racontent tous l'histoire que le plugin ZTE est rejeté à cause du test vendor-id/product-id.

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

Ou peut-être qu'il y a un problème de timing ici. Par exemple, que le ModemManager exécute le pre-probing alors que le périphérique est 19d2/1232. Cette pensée est alignée avec l'observation que le fait d'avoir les règles udev 78-mm-zte-port-types-RALPH.rules rend ModemManager un peu plus heureux avec le périphérique. Mais alors, pourquoi ne reste-t-il pas heureux et n'utilise-t-il pas ce plugin lorsque le périphérique passe en 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-le 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 reboot. Je veux dire.

1. configuration /lib/udev/rules.d avec ou sans le *-RALPH.rules fichier
2. sortir l'appareil
3. redémarrer
4. configurer ModemManager pour le débogage et configurer udevadm capture
5. branchez l'appareil et attendez une minute
6. emballer les fichiers journaux
7. répétez à partir de 1 avec le test suivant

Ce journal devrait indiquer où le plugin ZTE est déposé, et si j'ai bien compris, il indiquera également la gestion des événements udev.

EDIT 10

(Je suis presque au bout du rouleau ici, mais il me reste encore un ou deux souffles :-)

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

Je pense pouvoir en tirer quelque chose, mais je ne sais pas exactement comment le corriger. 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 "early" :

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

ce qui provoque le usb_serial à charger, et /dev/ttyUSB1 à paraître. Cela, en particulier, provoque 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 aussi ModemManager . Vous devez aller à syslog pour en avoir la preuve, car il n'y a pas de corrélation stricte entre les journaux. L'événement est horodaté 3867.435102 y syslog présente son suivant le plus proche ModemManager ligne de journal 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)

qui a joint les attributs de ZTE.

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

ModemManager puis est terminé avec son pré-profilage à 1449934745.450398 c'est-à-dire 87 ms plus tard, ce qui, en termes de temps kernel, correspondrait à peu près à 3867.524519 et 55ms avant ce "bon" rapport d'événement UDEV ci-dessus.

Notez que dans syslog , ModemManager dépose des plaintes selon lesquelles ttyUSB1 n'a pas ses attributs définis, et peut-être que cette plainte est liée au "marquage" qui se produit dans le module 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.

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

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

Dans mon esprit, cela garantirait que le ID_MM_CANDIDATE est retardé jusqu'à ce que les attributs ZTE soient définis. Le site .ID_PORT est un effet d'une 60-serial.rules (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 de ZTE, seulement pour que la règle reste plus générique. Une étape plus spécifique consisterait à exiger plutôt ENV{.MM_USBIFNUM}="?*" à la place, puisque cette affectation se fait ici par 77-mm-zte-port-types.rules .

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

EDIT 21

soupir. Probablement pas pertinent, mais vous pouvez vérifier votre 7-zte-mutil_port_device.rules Est-ce un vestige d'une autre expérience ? Quoi qu'il en soit, ce n'est pas pertinent ici.

Il y a encore presque une seconde entre 515.558184 y 516.381549 donde ModemManager s'empare avec empressement et à tort /dev/ttyUSB1 et, tout en se plaignant qu'il n'a pas été mis en place, il passe quand même par le pré-probing et rejette le plugin ZTE. En d'autres termes, le correctif de règle ne fait pas de la ZTE un plugin. ModemManager attendre.

Je suppose que vous avez également testé l'utilisation de ENV{.MM_USBIFNUM}="?*" 代わりに ENV{.ID_PORT}=="?*" .

En fait, pour confirmer si oui ou non le réglage ENV{ID_MM_CANDIDATE}=1 est d'une quelconque importance, vous devez temporairement vous éloigner 80-mm-candidate.rules puis voir (dans syslog ) si alors ModemManager ignore /dev/ttyUSB1 ou pas. Je soupçonne que "non".

Et puis, eh bien, peut-être que vous pouvez utiliser une version de travail, comme 14.04, et si vous 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.

Après avoir jeté un coup d'œil à ce document, il apparaît que ce n'est pas la première fois que ce dragon est traité correctement. Il s'agissait d'un bogue dans les versions 12.10 et 13.04. Peut-être que le bogue n'a jamais été corrigé ou qu'un nouveau patch a cassé quelque chose qui fonctionnait correctement auparavant.

Si je lis correctement vos spécifications techniques, je devrais vous indiquer cette direction (MF190J) :

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

Avez-vous essayé ceci :

 rfkill list up

et ensuite faire ce script et l'exécuter :

 #/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 ça pourrait marcher comme ça.