¿Error 'ip-config-undisponible' cuando el módem USB intenta conectarse?

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 a través del 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, quizás el problema se reduzca a cualquiera de estos puntos,

1. ¿A qué grupo adicional debe pertenecer el usuario?
2. ¿Cómo ejecutamos el proceso de configuración de la conexión de banda ancha móvil como raíz? (¿problemas de seguridad?)

Actualización 11:9 de diciembre de 2015

wvdial funciona con USB3 y no trabajar con USB1.

Encuentre 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. Sin éxito.

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 de Ubuntu 15.04 y 15.10.

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

¿Qué pasó entre el 15.04 y el 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.rules como se indica en la respuesta.

2. Reinicié mi máquina (o ejecuté sudo udevadm control --reload , en realidad probé ambos). 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. Sin éxito.

5. Expulsó el módem.

La máquina se cuelga una vez, ¿es un evento aleatorio? Mi máquina no
normalmente se bloquea 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.rules intacto.

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. Sin éxito.

6. Expulsó el módem.

7. Se eliminó /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 me arriesgué a 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 en
   /lib/udev/rules.d/40-usb_modeswitch.rules , quitó el otro
   uno.

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. Sin éxito.

6. Expulsó el módem.

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

El archivo syslog (completo, no me arriesgué a 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 en
   /lib/udev/rules.d/40-usb_modeswitch.rules , agregó uno 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 1232 dispositivo. No me ofrecen intentar conectarme (según mi conocimiento, no se registrará en la red de banda ancha a menos que el cambio haya ocurrido en 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. Visto lsusb salida cada segundo usando un shell
   script. Salida capturada en archivos con marca 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
   de las capturas, está claro que cambia de un dispositivo 1232 a
   uno de 2003.

4. Intenté conectarme. Sin éxito.

5. Expulsó el módem.

El archivo syslog, con marca de tiempo lsusb las salidas 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 que
pudiera aislar los problemas.

1. Guardado en un medio portátil /lib/udev/rules.d/40-usb-media-players.rules y /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 DVD de 64 bits.

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 guardado
   del 15.10.

   El examen del archivo diff no muestra idProduct 1232 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
   guardado desde el 15.10.

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

5. Insertó el módem. El módem fue reconocido como 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. Instalado 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 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 falla. De hecho, lo intenté, pero me di por vencido debido a un sinfín de problemas de dependencia.

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

Actualización 20:12 de diciembre de 2015

Prueba 1

1. El /lib/udev/rules en 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 udevadm capture.

   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 dice que está registrado en la red de banda ancha.

5. Intenté conectarme 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.rules en 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í.

Ojalá todos los archivos de registro vinieran con marcas de tiempo, lo que facilita la coincidencia.

Actualización 21:15 de diciembre de 2015

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

El archivo de reglas y el syslog están aquí.

Actualización 22:16 de diciembre de 2015

Como se indica en un comentario, instalé varios núcleos desde
http://kernel.ubuntu.com/~kernel-ppa/mainline/ e intenté conectarme
usando el módem después de iniciar 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, tal vez, podamos descartar el problema del kernel.

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.

Respuesta aceptada:

Cargando el ofono El paquete funcionó bien, 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 el mismo udev especial regla, para ejecutar usb_modeswitch cuando se inserta el dongle, y para lograrlo, puede, como root, agregar un nuevo udev regla al archivo
/lib/udev/rules.d/40-usb_modeswitch.rules
con las siguientes dos líneas, por ejemplo, en algún lugar cerca del # ZTE MF190J comentario:

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

más una línea en blanco, para que se vea agradable a la vista.

Probablemente sea prudente reiniciar después de eso, solo para descubrir que todo funciona como magia 🙂

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

EDITAR:

Ahora estoy viendo 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 último se refiere al enlace interno a un "contexto PDP" (sea lo que sea). Aparentemente, el módem ofrece 9 contextos alternativos, incluido uno con apn='WAP' , pero el ModemManager se conforma con una coincidencia que no distingue entre mayúsculas y minúsculas.

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

La primera opción podría probarse fácilmente (y probablemente descartarse) cambiando su configuración para usar 'wap' en lugar de 'WAP'. Puede que hayas probado esto antes, pero en ese momento sin el ofono paquete, por lo que otra prueba no 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. Al buscar en Google este problema, parece que la coincidencia que no distingue 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 hacer esto a ModemManager en noviembre del año pasado (en su versión mm-1-4, puedo deducir). Entonces, en este caso, no se le ha dicho a su módem y espera una coincidencia entre mayúsculas y minúsculas, mientras que ModemManager lamentablemente utiliza la coincidencia sin distinción entre mayúsculas y minúsculas directamente en lugar de como alternativa.

Una solución para el segundo problema es, por supuesto, usar un ModemManager diferente :ya sea buscando e instalando una versión anterior a este parche, o (con suficiente tiempo libre), implemente su propio ModemManager . Pero tampoco es algo que se haga por capricho, por lo que tal vez necesitemos explorar 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 aquí...

EDITAR 2

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

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

Creo que el problema 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 se pueda solucionar usando una de esas herramientas. Ya sea para poder forzar una selección de 9 durante la conexión, o eliminando los contextos 'wap' incorrectos del módem, de lo que se anuncia que es capaz la herramienta de prueba de módulos.

La herramienta modem-tester parece ser una herramienta 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 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' para distorsione las etiquetas apn 'wap' para que sean, por ejemplo, 'wap1' y 'wap2' (para "ocultarlas" al buscar 'WAP'). Luego guarde y cierre, y vuelva a hacer malabarismos con el dongle. Coge un tronco; parece que syslog es suficiente ahora, en caso de que aún se niegue a jugar.

El mmcli comando también parece útil en esta historia; hacer man mmcli para leer al respecto, pero no vi nada sobre contextos PDP allí.

EDITAR 3

¡Buena llamada! para probar desde el DVD. Eso nos dijo que estoy en el camino equivocado con el APN, y que todo radica en hacer que aparezca ppp. Al menos, ese sería mi nuevo árbol al que 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 entonces todos los usuarios de un dongle habrían estado en esta excursión.

Hmm, ppp; Necesito remover mis recuerdos del último milenio :-). Desafortunadamente, estoy ocupado hoy, pero me pondré en contacto la próxima vez que tenga tiempo para ver qué tan lejos has llegado. Mis primeros callejones para investigar serían:1) ¿Está el usuario en el grupo correcto? 2) ¿las credenciales son correctas? 3) ¿Son correctos los mods del archivo de configuración de ppp/chat? El registro de depuración de ppp aparece en nm.txt (como hace unos días), pero también debería haber una forma de solicitar un registro más detallado.

EDITAR 4

Asegúrese de /etc/ppp/pap-secrets y /etc/ppp/chap-secrets tener grupo dip (usando chgrp según sea necesario) y modo 740 (o -rw-r----- ) (usando chmod según sea necesario). El mío no.

EDITAR 5

Entonces, ¿qué tal este árbol? Comparando el wvdial de trabajo syslog con syslog que no funciona, parece que por alguna razón wvdial usado ttyUSB3 mientras que el ModemManager que no funciona sigue usando ttyUSB1 . No estoy seguro de si es significativo, pero aparentemente pero ttyUSB1 y ttyUSB3 ambos responden como módems con capacidad AT.

Entonces, como prueba, tal vez pueda editar /etc/wvdial.conf por lo que está en [Dialer Defaults] incluye la línea:

Modem = /dev/ttyUSB1

para la prueba, y ttyUSB3 Por otro; ambos ejecutándose como root; solo para ver si hay un comportamiento diferente. Especialmente, si usa ttyUSB1 es un problema mientras que el uso de ttyUSB3 no lo es, entonces sería bueno investigar cómo hacer que ModemManager también use ttyUSB3. Para cualquier otro resultado de la prueba, diría que volveremos a perseguir hurones en ppp land.

EDITAR 6

El registro de dmesg se puede ignorar, 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 NetworkManager se puede pensar en usar ttyUSB3 e ignorar ttyUSB1 (para este módem).

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

El aparentemente aplicable udev regla en /lib/udev/rules.d/77-mm-zte-port-types.rules no se aplica, pero supuestamente sería a dónde ir. Y, con solo una visión muy rudimentaria, anterior a 101, del udev magia, de todos modos consideraría cuestionar su cuarta línea, que dice:

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

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

EDITAR 7

Después de haber pasado un buen rato con mi motor de búsqueda favorito, creo un poco más que la elección de ttyUSB es un problema de raíz aquí. La regla de udev que señalé está bien, y debería 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, p. llamado 78-ralph.rules , pero luego también debe agregar la protección SUBSYSTEM y SUBSYSTEMS a su alrededor.

Luego, saca el dongle, ejecuta udevadm control --reload (o reinicie) e inserte el dongle. Y luego otro syslog captura, a menos que ahora funcione.

Sin embargo, el problema efectivo es que ModemManager descarta el complemento libmm-plugin-zte.so en el sondeo previo, 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; que el sondeo previo busca un ID_MM_ZTE_PORT_TYPE_MODEM atribución, y esto falta para la identificación del producto "1232" (antes del parche), con el efecto de que el complemento zte se descarta.

EDITAR 8

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

Si nada más, al menos tengo que aprender un poco sobre udev.

EDITAR 9

Bien. El problema sigue siendo (o también) que ModemManager suelta 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 es una tabla de vid/pid que no incluye 19d2/2003... aunque no he encontrado la fuente de esa tabla, así que no pude verificar.

O tal vez hay un problema de tiempo aquí. Por ejemplo, que ModemManager ejecute 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 contento con el dispositivo. Pero entonces, ¿por qué no permanece contento y utiliza ese complemento cuando el dispositivo se cambia a 19d2/2003?

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

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

1. configurar /lib/udev/rules.d con o sin las *-RALPH.rules archivo
2. sacar el dispositivo
3. reiniciar
4. configure ModemManager para la depuración y configure la captura de udevadm
5. conecta el dispositivo y espera un minuto
6. empaquetar archivos de registro
7. repetir desde 1 con la siguiente prueba

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

EDITAR 10

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

En primer lugar, todos los udev las decoraciones parecen terminar como deberían, con solo un par de signos de interrogación en un par de atributos. En particular, las 78-*-RALPH.rules debe ser desechado; no es útil.

Creo que puedo leer algo de esto, pero no estoy exactamente seguro de cómo debería arreglarse. Básicamente, como yo lo veo, cuando el dongle está enchufado, hay una ráfaga de eventos udev. Centrándonos 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 provoca el usb_serial controlador a cargar, y /dev/ttyUSB1 a aparecer. Eso en particular provoca 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 syslog para ver evidencia de esto, ya que no hay una correlación estricta entre los registros. El evento tiene una marca de tiempo 3867.435102 y syslog presenta su subsiguiente ModemManager más cercano línea de registro justo después de una línea de registro del kernel estampada 3867.437412 .

En mi línea de pensamiento, ModemManager no debe 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 tiene adjuntos los atributos de ZTE.

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

ModemManager luego se realiza con su sondeo previo en 1449934745.450398 , es decir, 87 ms más tarde, lo que en términos de tiempo de kernel estaría cerca de 3867.524519 y 55 ms antes de ese "buen" informe de eventos UDEV anterior.

Tenga en cuenta que en syslog , ModemManager presenta quejas de que ttyUSB1 no tiene 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 solucionar exactamente 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" en 80-mm-candidate.rules ser:

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

En mi opinión, eso garantizaría que el ID_MM_CANDIDATE la configuración se retrasa hasta que se configuran los atributos de ZTE. El .ID_PORT la configuración es un efecto de un 60-serial.rules regla (llamada 60-persistent-serial.rules antes), y la condición añadida a la regla de marcado es simplemente que tiene un valor.

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

En general, no estoy muy seguro acerca de udev ordenamiento de reglas, y tampoco estoy del todo seguro de que esto realmente detenga ModemManager de actuar demasiado rápido. Sin embargo, si no es así, entonces 80-mm-candidate.rules tendría poca o ninguna función, y tal vez todo se reduciría a las "mejoras" de ModemManager del 15.04.

EDITAR 21

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

Aún queda casi un segundo entre 515.558184 y 516.381549 donde ModemManager ansiosamente y erróneamente toma /dev/ttyUSB1 , and whilst complaining about it not being set up, still goes through pre-probing and discards the ZTE plugin. In other words, the rule patch doesn’t make ModemManager wait.

I suppose you also tested using ENV{.MM_USBIFNUM}="?*" instead of ENV{.ID_PORT}=="?*" .

Actually, to confirm whether or not setting ENV{ID_MM_CANDIDATE}=1 is of any importance, you should temporarily move away 80-mm-candidate.rules , then see (in syslog ) if then ModemManager ignores /dev/ttyUSB1 o no. I suspect “not”.

And then, well, maybe you can use a working version, such as 14.04, and if you need, perhaps run 15.10 in a virtualbox, unless of course it’s already all is in a virtualbox.

I think I need to claim defeat at this point.