web-dev-qa-db-fra.com

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

J'ai un modem ZTE MF-193E qui fonctionnait bien auparavant. Lorsque j'ai acheté ce modem il y a plus d'un an, il fonctionnait rapidement. Maintenant, alors qu'Ubuntu progresse dans sa version, les choses deviennent de plus en plus difficiles pour moi.

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

J'ai configurer une connexion haut débit mobile . J'ai essayé différentes chaînes pour APN, mais cela ne posait pas de problème auparavant.

(le modem fonctionne correctement sous Windows 10, il ne s'agit donc pas d'un problème matériel. En outre, l'interface graphique du gestionnaire de modem détecte parfaitement ce périphérique. Les SMS peuvent être envoyés et reçus. sans aucun probléme.)

Lorsque j'insère le modem, la détection est correcte, une icône de CD s'affiche dans Unity avec le nom du modem. Quelques secondes plus tard, je reçois un message

Mobile Broadband Network: you are registered on the home network

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

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

La ligne que je pourrais isoler de /var/log/syslog est la suivante:

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

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

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


Mise à jour 1 - 06 décembre 2015

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

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 essayé mon modem, le même échec. Pas de changement discernable 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é here .


Mise à jour 3 - 06 décembre 2015

Installé ofono et ensuite essayé à nouveau le modem.

S'il vous plaît voir 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é here .


Mise à jour 5 - 06 décembre 2015

Changement de "refuser" à "permettre" dans /etc/dbus-1/system.d/nm-dispatcher.conf.

Essayé de se 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.

Modem brancher et brancher.

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 d'exécuter mm-test.py en raison de plusieurs erreurs. Avez-vous trouvé le fichier à l'emplacement indiqué? Vous l'avez obtenu de, 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ée à nouveau (après la modification suggérée dans /lib/udev/rules.d/40-usb_modeswitch.rules et redémarrez)

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

  1. Cette fois, l'ordinateur a été démarré à partir d'un DVD 32 bits Ubuntu 14.04. Dès que l'ordinateur a démarré, la capture du journal MM a commencé.

  2. Inséré le modem. lsusb a montré qu'il était reconnu en tant que périphérique 19d2: 1232 et devait être remplacé par un périphérique 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 ai basculé le modem en 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 sur Mobile Broadband Network et qu'une nouvelle connexion à large bande a été ajoutée dans le menu du gestionnaire de réseau.

  4. J'ai configuré la connexion ci-dessus de la manière habituelle (le nom de l'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 syslog du début de la session pour 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 constaté que si wvdial est exécuté en tant que root, nous obtenons une connexion réussie .

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 numérotation, l'utilisateur doit être membre des groupes "dip" et "dialout". Vous devez donc placer tous les utilisateurs qui sont supposés se connecter via une numérotation dans ces groupes.

Mais comme on peut le trouver,

$ 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 la question se résume à l'un de ces points,

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

Mise à jour 11 - 09 décembre 2015

wvdial fonctionne avec USB3 et pas avec USB1.

S'il vous plaît trouver le syslog ici .

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


Mise à jour du 12 au 10 décembre 2015

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

  2. Redémarré ma machine. Soft 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

En désespoir de cause, pour voir si des modifications locales affectent la connexion, a testé la machine avec les DVD Ubuntu 15.04 et 15.10.

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

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

  2. Redémarrage de ma machine (ou exécution de Sudo udevadm control --reload, réellement 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 déconnecte le câble et tente 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 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

  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. A laissé le fichier /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intact.

  3. Redémarré 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 déconnecte le câble et tente 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 a essayé le processus entier encore. Échec à nouveau.

Le fichier syslog (complet, je n’ai pas pris le risque de rater une 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 règle 1232 dans /lib/udev/rules.d/40-usb_modeswitch.rules, a supprimé l'autre règle.

  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 déconnecte le câble et tente de se connecter. Infructueux.

  6. Éjecté le modem.

Mais n'avons-nous pas testé le système par défaut ci-dessus? Voulez-vous dire laisser /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 rater une partie importante) et le fichier de règles mentionné (40) sont ici


Mise à jour 17 - 11 décembre 2015

  1. Commenté la règle 1232 dans /lib/udev/rules.d/40-usb_modeswitch.rules, en a ajouté 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 . Je ne suis pas proposé pour essayer de me connecter (pour autant que je sache, il ne sera pas enregistré sur un réseau haut débit sauf si la commutation a 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 originale.

  2. Regardé lsusb produire toutes les secondes en utilisant 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, horodaté lsusb sorties et les fichiers de règles mentionnés sont ici .

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


Mise à jour 19 - 11 décembre 2015

Effectué ce test dans une nouvelle direction complète avec le souhait que je puisse isoler les problèmes.

  1. Enregistré sur un support portable /lib/udev/rules.d/40-usb-media-players.rules et /lib/udev/rules.d/77-mm-zte-port-types.rules (à partir de la machine Ubuntu 15.10).

  2. Démarrez la machine avec un DVD 64 bits Xubuntu 15.04.

  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 provient de celui enregistré à partir de 15.10.

    L’examen du fichier diff ne montre aucun idProduct 1232 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.

    De nouveau, l’examen du fichier diff ne montre aucun idProduct 1232 ni 2003.

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

    $ lsusb
    Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
    
  6. Pourrait se connecter facilement après avoir établi une connexion haut débit mobile.

  7. Éjecté le modem.

  8. Installé le dernier USB_ModeSwitch.

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

    Retourne maintenant NULL, comme prévu.

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

  10. Inséré le modem. Le modem a été reconnu comme un 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, histoire de voir où ça casse. J'ai effectivement essayé mais j'ai abandonné à cause 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/rules dans son é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é dans le modem et attendu jusqu'à ce qu'il indique qu'il est enregistré dans le réseau haut débit.

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

  6. Éjecté le modem.

  7. Emballé les fichiers journaux.

Test 2

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

Les noms de fichier journal sont explicites.

Tous les fichiers journaux ci-dessus, ainsi que syslog et les 78 fichiers de règles sont here .

Je souhaite que tous les fichiers journaux soient livrés avec des horodatages, ce qui facilite l'appariement.


Mise à jour 21 - 15 décembre 2015

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

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


Mise à jour 22 - 16 décembre 2015

Comme indiqué dans un commentaire, a installé divers noyaux à partir de http://kernel.ubuntu.com/~kernel-ppa/mainline/ et a essayé de se connecter à l'aide du modem après le démarrage de chacun d'eux.

  1. 4.2.8-040208-generic, échec.

  2. 4.1.15-040115-generic, échec.

  3. 4.0.9-040009-generic, échec.

Nous pouvons donc peut-être éliminer 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.

12
Masroor

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

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

1
Masroor

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

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

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

0
John75077