Error 'ip-config-novailable' cuando el módem USB intenta conectarse

Tengo un módem ZTE MF-193E que funcionó bien antes. Cuando compré este módem hace más de un año, funcionó de inmediato. Ahora, a medida que Ubuntu avanza en la versión, las cosas se vuelven cada vez más difíciles para mí.

Este módem incluso funcionó hace un par de meses con Ubuntu 15.04 (64 bits). Ahora, en Ubuntu 15.10 (64 bits), no se puede conectar.

He configurado una conexión de banda ancha móvil . He intentado varias cadenas para APN, pero esto no ha sido un problema antes.

(El módem funciona bien en Windows 10, por lo tanto, esto no es un problema de hardware en absoluto. Además, la GUI de Modem Manager detecta muy bien este dispositivo. Los SMS se pueden enviar y recibir sin ningún problema).

Cuando inserto el módem, se detecta bien, se muestra un icono de CD en Unity con el nombre del módem. Unos segundos después, recibo un cuadro de mensaje

Mobile Broadband Network: you are registered on the home network

cerca del ícono de red.

Cuando intento conectarme, el ícono inalámbrico en el applet del administrador de red inicia esos movimientos centrífugos, pero finalmente no se conecta y un mensaje me dice que estoy desconectado.

La línea de la que podría aislarme /var/log/sysloges esta,

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

Sin embargo, no estoy seguro de si este es el relevante.

Más líneas de /var/log/syslogse pueden encontrar aquí .

Actualización 1 - 06 de diciembre de 2015

Como señaló un miembro amable, probé el nf_conntrack_pptpenfoque del módulo.

Ejecuté los siguientes comandos,

$ 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

Luego probé mi módem, el mismo fracaso. Ningún cambio perceptible en el registro tampoco.

Actualización 2 - 06 de diciembre de 2015

Ejecutado como root,

systemctl restart network-manager.service

No hay salida en pantalla (terminal).

El registro correspondiente del punto anterior a un intento de conexión usando el módem se puede encontrar aquí .

Actualización 3 - 06 de diciembre de 2015

Instalado ofonoy luego intentado el módem nuevamente.

Por favor vea el registro aquí .

Actualización 4 - 06 de diciembre de 2015

Nuevamente ejecutado como root,

systemctl restart network-manager.service

El registro correspondiente del punto anterior a un intento de conexión usando el módem se puede encontrar aquí .

Actualización 5 - 06 de diciembre de 2015

Cambió todo "negar" a "permitir" /etc/dbus-1/system.d/nm-dispatcher.conf.

Intenté conectar. Sin suerte.

Algunas redes se conectan y desconectan con la conexión Ethernet.

Seguido de sudo systemctl restart network-manager.service.

Módem enchufar y enchufar.

Intenté conectar de nuevo. No se conecta

El registro está aquí .

Actualización 6 - 06 de diciembre de 2015

Ejecutado

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

y

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

No se pudo ejecutar mm-test.pydebido a múltiples errores. Encontró el archivo en la ubicación indicada. Obtuve esto de https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

Los comandos anteriores son algo diferentes de los de Wiki.

Los archivos de registro están aquí .

Actualización 7 - 07 de diciembre de 2015

Ejecutado de nuevo (después del cambio sugerido /lib/udev/rules.d/40-usb_modeswitch.rulesy reiniciar)

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

y

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

El /var/log/syslogestá incluido también.

Los archivos de registro están aquí .

Actualización 8 - 08 de diciembre de 2015

El conjunto actualizado de registros está aquí .

Actualización 9 - 08 de diciembre de 2015

Prueba 1

1. Esta vez arrancó la computadora desde un DVD Ubuntu 14.04 de 32 bits. Tan pronto como la computadora arrancó, comenzó a capturar el registro MM.

2. Insertó el módem. lsusbdemostró que estaba siendo reconocido como un dispositivo 19d2: 1232 que debe cambiarse a un dispositivo 19d2: 2003. Dado que la instalación de usb-modeswitch requiere reiniciar la máquina (y, por lo tanto, perder la instalación para ejecutar DVD), preparé un archivo de interruptor personalizado y cambié el módem desde la línea de comandos ( sudo usb_modeswitch -I -c 19d2:2003).

3. Tan pronto como se realizó la conmutación, me informaron que estaba encendido Mobile Broadband Networky que aparecía una nueva conexión de banda ancha en el menú del administrador de red.

4. Configuré la conexión anterior de la forma habitual (el nombre APN no fue un problema), y la conexión se estableció automáticamente.

5. Desconecté y expulsé el módem.

6. Dejó de capturar el registro MM.

El registro MM completo y el registro del sistema para el inicio de la sesión para la expulsión del módem se pueden encontrar aquí .

Prueba 2

La misma prueba con un DVD Ubuntu 14.04 de 64 bits.

Los registros se pueden encontrar aquí .

Actualización 10 - 09 de diciembre de 2015

Esta vez probamos wvdialy descubrimos que si wvdialse ejecuta como root, obtenemos una conexión exitosa .

El wvdialconf y log, y el syslog correspondiente están aquí

Conjetura primaria: la situación podría tener algo que ver con el grupo de usuarios del usuario correspondiente.

Pero como se indica aquí ,

Con todas estas herramientas, para establecer una conexión de acceso telefónico, el usuario debe ser miembro de los grupos "dip" y "dialout", por lo tanto, coloque a todos los usuarios que se supone que deben conectarse mediante acceso telefónico en estos grupos.

Pero como podemos encontrar,

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

Entonces, el usuario ya es miembro de los grupos indicados.

Ahora, tal vez el problema se reduce a cualquiera de estos puntos,

1. ¿Qué grupo adicional necesita ser el usuario?
2. ¿Cómo ejecutamos el proceso de configuración de la conexión de banda ancha móvil como root? (¿temas de seguridad?)

Actualización 11 - 09 de diciembre de 2015

wvdialfunciona con USB3 y no funciona con USB1.

Encuentra el syslog aquí .

También se incluye la salida de dmesg | grep tty > /tmp/dmesg.tty.txt. ¿Pero ves esas cuatro líneas cerca del inicio del archivo?

Actualización 12 - 10 de diciembre de 2015

1. Comentó la línea 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") en /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Reinicié mi máquina. Soft desconectó el cable e insertó el módem.

3. Intenté conectarme. Fracasado.

El archivo syslog está aquí .

Actualización 13 - 10 de diciembre de 2015

Por pura desesperación, para ver si algunos cambios locales están afectando la conexión, probé la máquina con los DVD Ubuntu 15.04 y 15.10.

1. Arrancó la máquina con Xubuntu 15.04 64 bit DVD. La conexión fue exitosa como un encanto.
2. Arrancó la máquina con Ubuntu 15.10 64 bit DVD. La conexión falló como antes.

¿Qué pasó entre 15.04 y 15.10?

Muy frustrante.

Actualización 14 - 10 de diciembre de 2015

1. Creó un nuevo archivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulescomo se indica en la respuesta.

2. Reinicié mi máquina (o ejecuté sudo udevadm control --reload, realmente probé ambas). Insertó el módem.

3. El módem fue reconocido.

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

4. Soft desconectó el cable e intentó conectarse usando el módem. Fracasado.

5. Expulsó el módem.

La máquina se cuelga una vez, ¿es un evento aleatorio? Mi máquina no suele colgarse una vez al año.

El archivo syslog y los archivos de reglas creados están aquí .

Actualización 15 - 11 de diciembre de 2015

1. Se agregaron las siguientes líneas a /lib/udev/rules.d/40-usb_modeswitch.rules.

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

2. Dejó el archivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesintacto.

3. Reinicié mi máquina. Insertó el módem.

4. El módem fue reconocido.

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

5. Soft desconectó el cable e intentó conectarse. Fracasado.

6. Expulsó el módem.

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

8. Reinicié e intenté todo el proceso nuevamente. Sin éxito de nuevo.

El archivo syslog (completo, no corrí el riesgo de perder ninguna parte importante) y el archivo de reglas mencionado (40) están aquí .

Actualización 16 - 11 de diciembre de 2015

1. Dejó solo una regla 1232 adentro /lib/udev/rules.d/40-usb_modeswitch.rules, eliminó la otra.

2. Ejecutado sudo udevadm control --reload.

3. Insertó el módem.

4. El módem fue reconocido.

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

5. Soft desconectó el cable e intentó conectarse. Fracasado.

6. Expulsó el módem.

¿Pero no probamos el sistema predeterminado anterior? ¿Querías dejar /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesen su lugar?

El archivo syslog (completo, no corrí el riesgo de perder ninguna parte importante) y el archivo de reglas mencionado (40) están aquí

Actualización 17 - 11 de diciembre de 2015

1. Comentó la regla 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, agregó una para 2003.

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

2. Ejecutado sudo udevadm control --reload.

3. Insertó el módem.

4. El módem fue reconocido como un dispositivo 1232 . No se me ofrece intentar conectar (hasta donde yo sé, no se registrará en la red de banda ancha a menos que haya ocurrido el cambio a 2003)

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

5. Expulsó el módem.

El archivo syslog y el archivo de reglas mencionado (40) están aquí

Actualización 18 - 11 de diciembre de 2015

1. Ponga todos los archivos de reglas en su forma original.

2. lsusbSalida observada cada segundo usando un script de shell. Salida capturada en archivos con sello de tiempo.

3. Insertó el módem. (El módem aparece por primera vez en el archivo lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Como podemos encontrar en las capturas, está claro que cambia de un dispositivo 1232 a uno de 2003.

4. Intenté conectarme. Fracasado.

5. Expulsó el módem.

El archivo syslog, las lsusbsalidas con sello de tiempo y los archivos de reglas mencionados están aquí .

Ahora, es posible que desee hacer coincidir las salidas de syslog con las marcas de tiempo.

Actualización 19 - 11 de diciembre de 2015

Realicé esta prueba en una dirección completamente nueva con el deseo de poder aislar los problemas.

1. Guardado en un medio portátil /lib/udev/rules.d/40-usb-media-players.rulesy /lib/udev/rules.d/77-mm-zte-port-types.rules(desde la máquina Ubuntu 15.10).

2. Arrancó la máquina usando Xubuntu 15.04 64 bit DVD.

3. Ejecutado diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. El primer archivo es del que se guardó desde 15.10.

   El examen del archivo diff no muestra idProduct1232 o 2003.

4. Ejecutado diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Nuevamente, el primer archivo es del que se guardó desde 15.10.

   Nuevamente, el examen del archivo diff no muestra idProduct1232 o 2003.

5. Insertó el módem. El módem fue reconocido como un módem.

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

6. Podría conectarse fácilmente después de configurar una conexión de banda ancha móvil.

7. Expulsó el módem.

8. Instaló el último USB_ModeSwitch.

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

   Ahora devuelve NULL, como se esperaba.

9. Ejecutado sudo udevadm control --reload-rules.

10. Insertó el módem. El módem fue reconocido como un módem.

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

11. Podría conectarse fácilmente.

Podría haber intentado actualizar MM y NM a Ubuntu 15.10, solo para ver dónde se rompe. En realidad lo intenté pero me di por vencido debido a problemas de dependencia interminables.

Todos los archivos diff mencionados anteriormente están aquí .

Actualización 20 - 12 de diciembre de 2015

Prueba 1

1. El /lib/udev/rulesen estado original.

2. El dispositivo de módem aún no se ha insertado en esta sesión.

3. Configure ModemManager para depurar y configurar la captura de udevadm.

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

4. Conectó el módem y esperó hasta que diga que está registrado en la red de banda ancha.

5. Intenté conectar sin éxito.

6. Expulsó el módem.

7. Archivos de registro empaquetados.

Prueba 2

Repitió la prueba anterior con /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesen su lugar.

Los nombres de los archivos de registro se explican por sí mismos.

Todos los archivos de registro anteriores más syslog y los 78 archivos de reglas están aquí .

Deseo que todos los archivos de registro vengan con marcas de tiempo, haciendo más fácil la coincidencia.

Actualización 21 - 15 de diciembre de 2015

1. Cambió el archivo de reglas como se sugiere.
2. Reinicié mi máquina.
3. Insertó el módem e intentó conectarse. No funcionó.

El archivo de reglas y el syslogestán aquí .

Actualización 22 - 16 de diciembre de 2015

Como se aconseja en un comentario, instalé varios núcleos desde http://kernel.ubuntu.com/~kernel-ppa/mainline/ e intenté conectar usando el módem después de arrancar en cada uno.

1. 4.2.8-040208-genérico, falla.

2. 4.1.15-040115-genérico, falla.

3. 4.0.9-040009-genérico, falla.

Entonces, quizás, podemos descartar el problema del núcleo.

Actualización 23 - 16 de febrero de 2016

El módem ha comenzado a funcionar en Ubuntu 16.04. Esta versión todavía está en Alpha 1, pero funciona bien en mi computadora portátil.

Cargar el ofonopaquete fue bueno, probablemente, pero aparentemente su modelo de módem, ZTE MF193E, no está en la lista de ZTE. Comparándolo con otros módems ZTE, por ejemplo, MF190J, es probable que este módem necesite la misma udevregla especial , para ejecutarse usb_modeswitchcuando se inserta el dongle, y para lograr eso, como root, puede agregar una nueva udevregla al archivo
/lib/udev/rules.d/40-usb_modeswitch.rules
con los siguientes dos líneas, por ejemplo, en algún lugar cerca del # ZTE MF190Jcomentario:

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

más una línea en blanco, por lo que se ve agradable a la vista.

Probablemente sea aconsejable reiniciar después de eso, solo para descubrir que todo funciona como magia :-)

O no. Como saben, esto es profundo para mí, pero si aún no funciona, se necesitaría otro registro de depuración de ModemManager, para otra conjetura.

EDITAR:

Ahora estoy mirando las dos líneas en 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'

Supongo que el primero se refiere a su configuración de banda ancha, mientras que el segundo se refiere al enlace interno a un "contexto PDP" (sea lo que sea). Por lo que parece, el módem ofrece 9 contextos alternativos, incluido uno con apn='WAP', pero se ModemManagerconforma con una coincidencia entre mayúsculas y minúsculas.

La diferencia de mayúsculas y minúsculas podría ser la causa del problema posterior: por ejemplo, que ppp quiere una 'wap'configuración (en lugar de 'WAP') y no la encuentra, o que el extremo remoto espera apn='WAP', pero obtiene 'wap' que se ahoga.

La primera opción podría probarse fácilmente (y descartarse, probablemente) cambiando su configuración para usar 'wap' en lugar de 'WAP'. Es posible que haya intentado esto antes, pero en ese momento sin el ofonopaquete, por lo que otra prueba no le hará daño, aunque la segunda opción es más probable.

La segunda opción también es más problemática, dado que hay una coincidencia de "contexto PDP" en mayúsculas disponible desde el módem. Googleando este problema, parece que la coincidencia entre mayúsculas y minúsculas es correcta según la especificación (aparentemente relevante) "3GPP TS 23.003 capítulo 9.1", y se agregó un parche para hacerlo ModemManageren noviembre del año pasado (en su versión mm-1-4, Puedo reunir) Entonces, en este caso, su módem no ha sido informado, y espera una coincidencia entre mayúsculas y minúsculas, mientras que ModemManagerdesafortunadamente usa la coincidencia entre mayúsculas y minúsculas directamente en lugar de como una alternativa.

Una solución para el segundo problema es, por supuesto, usar una diferente ModemManager: ya sea buscando e instalando una versión anterior a este parche o (con suficiente tiempo libre), cree la suya propia ModemManager. Pero tampoco hay algo que hacer a su antojo, por lo que tal vez necesitemos navegar un poco para obtener más evidencia de que este es (ahora) el problema y, si es posible, encontrar otras formas de solucionarlo. O con un poco de suerte, alguien que sabe algo pasa por ...

EDITAR 2

Sí, la reversión de la versión no es fácil debido a las dependencias. Y rodar el tuyo está lejos de ser una alegría también.

Dos posibles herramientas útiles: comando mmcliy ( http://m2msupport.net/m2msupport/module-tester/ ).

El problema, creo, es que ModemManager elige el contexto PDP 1 con apn = 'wap' donde debería elegir el contexto PDP 9 con apn = 'WAP'. Tal vez esto pueda abordarse utilizando una de esas herramientas. Para poder forzar una selección de 9 durante la conexión, o eliminando los contextos 'wap' malos del módem, de los cuales se anuncia que la herramienta de prueba de módulos es capaz de hacerlo.

La herramienta de prueba de módem parece ser una herramienta de Java en el navegador, por lo que necesita configurar su navegador para saber dónde está su Java, y necesita que se conozca ese Java. Entonces, por favor explore ese enfoque; No lo he usado yo mismo, pero al ver las capturas de pantalla, supongo que presentará los contextos PDP como la pestaña 'Llamadas de datos', donde primero toma nota de todo lo que muestra y luego edita las entradas 'wap' en distorsione las etiquetas apn 'wap' para que sean, digamos, 'wap1' y 'wap2' (para "ocultarlas" cuando se busca 'WAP'). Luego guarde y cierre, y haga malabarismos con el dongle nuevamente. Agarra un tronco; parece que syslog es suficiente ahora, en caso de que todavía se niegue a jugar.

El mmclicomando también parece útil en esta historia; hago man mmclipara leer sobre ello, pero no vi nada de contextos PDP allí.

EDITAR 3

¡Buena llamada! para probar desde el DVD. Eso nos dijo que estoy en el camino equivocado con la APN, y que todo se basa en hacer que aparezca ppp. Al menos, ese sería mi nuevo árbol para ladrar.

En primer lugar, tomamos nota de que hay una diferencia de versión para pppd (de 2.4.5 a 2.4.6), pero eso probablemente no sea un problema, ya que todos en un dongle habrían estado en esta excursión.

Hmm, ppp; Necesito agitar mis recuerdos del último milenio :-). Desafortunadamente estoy ocupado hoy, pero tocaré la base la próxima vez que tenga tiempo, para ver qué tan lejos has llegado. Mis primeros callejones a considerar serían: 1) ¿el usuario está en el grupo correcto? 2) ¿son correctas las credenciales? 3) ¿son correctas las modificaciones del archivo de configuraciones ppp / chat? El registro de depuración de ppp sale en nm.txt (como hace unos días), pero también debería haber una manera de solicitar un registro más detallado.

EDITAR 4

Asegúrese /etc/ppp/pap-secretsy /etc/ppp/chap-secretstenga grupo dip(usando chgrpsegún sea necesario) y modo 740(o -rw-r-----) (usando chmodsegún sea necesario). El mío no lo hizo.

EDITAR 5

¿Qué tal este árbol? Entonces: al comparar el wvdialsyslog que funciona con el syslog que no funciona, parece que por alguna razón se wvdialusa ttyUSB3mientras el que no funciona ModemManagersigue usándose ttyUSB1. No estoy seguro si es del todo significativa, pero al parecer, pero ttyUSB1y ttyUSB3ambos responden como AT módems capaces.

Entonces, como prueba, tal vez pueda editar /etc/wvdial.confpara que [Dialer Defaults]incluya la línea:

Modem = /dev/ttyUSB1

para una prueba y ttyUSB3para otra; ambos corriendo como root; solo para ver si hay un comportamiento diferente. Especialmente, si usar ttyUSB1es un problema, mientras que usar ttyUSB3 no lo es, entonces sería bueno analizar cómo hacer que ModemManager use ttyUSB3 también. Para cualquier otro resultado de la prueba, diría que volveremos a perseguir hurones en tierra ppp.

EDITAR 6

El registro dmesg puede ser ignorado, creo; ha sido así en todos los registros. El nuevo syslog solo muestra la prueba ttyUSB3, pero tal vez podamos asumir que la vida mejora si NetworkManagerse puede usar ttyUSB3 e ignorar ttyUSB1 (para este módem).

También encontré ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) con especialmente la publicación # 10 desconcertante :-(

La udevregla aparentemente aplicable en /lib/udev/rules.d/77-mm-zte-port-types.rulesno se aplica, pero supuestamente sería a dónde ir. Y, con solo una visión muy rudimentaria, anterior a 101, de la udevmagia, consideraría cuestionar su cuarta línea, que dice:

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

Creo que esa línea necesita una inicial #para ser comentada. En detalle, mi lectura del archivo es que requiere un estado de llamada SUBSYSTEM == "tty" y SUBSYSTEMS = "usb" para usar los bits buenos, incluidas las reglas del producto "2003", y al menos para las pruebas, debería ser seguro omitir el filtrado "tty". Y no tengo nada mejor en este momento.

EDITAR 7

Después de pasar un tiempo de calidad con mi motor de búsqueda favorito, creo un poco más que la elección de ttyUSB es un problema raíz aquí. La regla de udev que señalé está bien, y deberías revertir esa edición.

Sin embargo, comencé a creer que las reglas de configuración hacia el final de ese archivo, para la identificación del producto "2003" son engañosas. Según los registros, me parece que la identificación del producto "2003" es en realidad el lado del dispositivo de memoria del dongle, mientras que el lado del módem tiene la identificación del producto "1232". Puede probar esto replicando las dos reglas "2003" para la identificación del producto "1232", en el archivo/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"

o mejor, agregue un nuevo archivo al lado, por ejemplo, llamado 78-ralph.rules, pero luego también necesita agregar la protección SUBSISTEMA y SUBSISTEMA a su alrededor.

Luego, extraiga la mochila, ejecute udevadm control --reload(o reinicie) e inserte la mochila. Y luego otra syslogcaptura, a menos que ahora funcione.

Sin embargo, el problema efectivo es que ModemManager descarta el complemento libmm-plugin-zte.soen la prueba previa y termina usando un controlador de módem genérico. Si tengo razón sobre la identificación del producto, entonces esta podría ser la razón; esa prueba previa busca una ID_MM_ZTE_PORT_TYPE_MODEMatribución, y esta falta para la identificación del producto "1232" (antes del parche), con el efecto de que el complemento zte se descarta.

EDITAR 8

El syslogregistro es un poco corto; falta el principio donde ModemManager no puede instalar el complemento zte. Sin embargo, está claro que el complemento de módem genérico se utiliza de todos modos. Ahora, puede ser que la usb_modeswitchregla que te di al principio también esté mal; decide cambiar a "2003" cuando pensé que cambió de "2003". Pero, man usb_modeswitch(lo que debería haber visto antes) sugiere que cambia a una identificación de producto en lugar de a partir de ella. En cualquier caso, el registro muestra que eso sucederá. Por lo tanto, cambie esa regla para usar "1232" en su lugar e intente nuevamente.

Por lo menos, al menos tengo que aprender un poco sobre udev.

EDITAR 9

Bueno. El problema sigue siendo (o también) que ModemManager deja caer el complemento ZTE en el sondeo previo. Los registros de depuración de ModemManager para 15.10 (conjuntos de registros "debuglogs *") cuentan la historia de que el complemento ZTE se descartó debido a la prueba de id de proveedor / id de producto.

¡Ve a la fuente, Luke! Aproveché esta oportunidad para ver brevemente el código fuente de ModemManager, e indica que el complemento como una tabla de vid / pid que no incluye 19d2 / 2003 ... sin embargo, no he encontrado esa fuente de tabla, por lo que no pude No verificar.

O tal vez hay un problema de tiempo aquí. Por ejemplo, que el ModemManager ejecuta una prueba previa mientras el dispositivo es 19d2 / 1232. Ese pensamiento está alineado con la observación de que tener las reglas udev de 78 mm-zte-port-types-RALPH.rules hace que ModemManager esté un poco más feliz con el dispositivo. Pero entonces, ¿por qué no se queda feliz y hace uso de ese complemento cuando el dispositivo se cambia a 19d2 / 2003?

Tal vez se necesitan más registros :-) Con ModemManager depurado, y también una captura del comando udevadm monitor --e |& tee udevadm.log(en otro terminal) cuando conecta el dispositivo. Obtuve ese comando de ( https://wiki.ubuntu.com/DebuggingUdev )

Haga esto dos veces: una vez sin 78-mm-zte-port-types-RALPH.rulesy una vez con las reglas ... ambas veces desde un nuevo reinicio. Es decir

1. configuración /lib/udev/rules.dcon o sin el *-RALPH.rulesarchivo
2. sacar el dispositivo
3. reiniciar
4. configurar ModemManager para depurar y configurar la captura de udevadm
5. conecta el dispositivo y espera un minuto
6. empacar archivos de registro
7. repita desde 1 con la siguiente prueba

Ese registro debería indicar dónde se ha caído el complemento ZTE y, según tengo entendido, también informará sobre el manejo de eventos udev.

EDITAR 10

(Estoy casi al final de mi cuerda aquí, pero me quedan una o dos respiraciones más :-)

En primer lugar, todas las udevdecoraciones parecen terminar como deberían, con solo un par de signos de interrogación en algunos de los atributos. En particular, 78-*-RALPH.rulesdebe desecharse; No es útil.

Creo que puedo leer algo de esto, pero no estoy exactamente seguro de cómo debería solucionarse. Básicamente, como lo veo, cuando el dongle está enchufado, hay una serie de eventos udev. Centrándose en los relacionados con ttyUSB1, hay un evento "temprano":

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

lo que hace que el usb_serialcontrolador se cargue y /dev/ttyUSB1aparezca. Eso en particular causa otro evento:

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

Creo que eso también desencadena ModemManager. Tienes que ir a syslogpara ver evidencia de esto, ya que no hay una correlación estricta entre los registros. El evento tiene una marca de tiempo 3867.435102y syslogpresenta su ModemManagerlínea de registro subsiguiente más cercana justo después de la línea de registro del kernel 3867.437412.

En mi línea de pensamiento, ModemManagerno debería activarse todavía, sino solo después del evento ttyUSB1 posterior:

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

que ha adjuntado los atributos ZTE.

En el registro MM, estaríamos en la línea estampada 1449934745.363291, que aparentemente es una marca de tiempo "en tiempo real" en lugar de una marca de "tiempo de núcleo".

ModemManagerluego se realiza con su sondeo previo 1449934745.450398, es decir, 87 ms después, que en términos de tiempo del núcleo estaría cerca 3867.524519y 55 ms antes de ese "buen" informe de evento UDEV anterior.

Tenga en cuenta que en syslog, ModemManagerpresenta quejas que ttyUSB1no tienen sus atributos establecidos, y tal vez esa queja está relacionada con el "marcado" que ocurre en 80-mm-candidate.rules. Según el comentario en ese archivo, esa marca parece ser un intento de lidiar exactamente con este problema, pero si es así, no parece funcionar en este caso.

Quizás una posibilidad para resolver esto sería cambiar la regla "tty" 80-mm-candidate.rulespara que sea:

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

En mi opinión, eso aseguraría que la ID_MM_CANDIDATEconfiguración se retrase hasta que se establezcan los atributos ZTE. La .ID_PORTconfiguración es un efecto de una 60-serial.rulesregla (llamada 60-persistent-serial.rulesantes), y la condición agregada a la regla de marcado es simplemente que tiene un valor.

La condición no es exactamente un atributo ZTE, solo para mantener la regla más genérica. Un paso más específico sería más bien exigir en su ENV{.MM_USBIFNUM}="?*"lugar, ya que esa asignación aquí sucede 77-mm-zte-port-types.rules.

En general, no estoy muy seguro sobre el udevorden de las reglas, y tampoco estoy seguro de que esto realmente deje ModemManagerde actuar demasiado rápido. Sin embargo, si no lo hace, entonces 80-mm-candidate.rulestendría poca o ninguna función, y tal vez todo se reduciría a las "mejoras" a ModemManagerpartir de 15.04.

EDITAR 21

suspiro. Probablemente irrelevante, pero es posible que desee verificar su 7-zte-mutil_port_device.rulesarchivo; ¿Es eso un remanente de otra experimentación? De todos modos, no es relevante aquí.

Todavía hay casi un segundo entre 515.558184y 516.381549donde ModemManagerse agarra ansiosa y erróneamente /dev/ttyUSB1, y aunque se queja de que no se está configurando, todavía pasa por un sondeo previo y descarta el complemento ZTE. En otras palabras, el parche de la regla no hace ModemManageresperar.

Supongo que también probaste usando en ENV{.MM_USBIFNUM}="?*"lugar de ENV{.ID_PORT}=="?*".

En realidad, para confirmar si la configuración ENV{ID_MM_CANDIDATE}=1es o no de importancia, debe alejarse temporalmente 80-mm-candidate.rules, luego ver (en syslog) si ModemManagerignora /dev/ttyUSB1o no. Sospecho que "no".

Y luego, bueno, tal vez pueda usar una versión funcional, como 14.04, y si lo necesita, tal vez ejecute 15.10 en una caja virtual, a menos que, por supuesto, ya esté todo en una caja virtual.

Creo que necesito reclamar la derrota en este punto.

El módem ha comenzado a funcionar en Ubuntu 16.04. Esta versión todavía está en fase de desarrollo, pero funciona bien en mi computadora portátil.

Desearía poder proporcionar más detalles técnicos sobre cómo comenzó a funcionar.

Después de echar un vistazo a esto, parece que esta no es la primera vez que este dragón ha sido tratado adecuadamente. Era un error antes en 12.10 y 13.04, tal vez el error nunca se solucionó o un parche nuevo rompió algo que funcionaba correctamente antes.

Con suerte, si estoy leyendo sus especificaciones técnicas correctamente, necesitaría señalarle en esta dirección (MF190J):

El módem 3G (ZTE MF190J) todavía requiere ajustes manuales.

¿Has probado esto?

 rfkill list up

y luego crea este script y ejecútalo:

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

y podría funcionar bien de esta manera.