Errore "ip-config-unavailable" quando il modem USB tenta di connettersi?

Con tutti questi strumenti, per stabilire una connessione dialup, l'utente deve
essere membro dei gruppi "dip" e "dialout", quindi inserisci tutti gli utenti che
dovrebbero connettersi tramite dialup in questi gruppi .

Ma come possiamo scoprire,

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

Quindi, l'utente è già un
membro dei gruppi indicati.

Ora, forse il problema si riduce a uno di questi punti,

1. Quale gruppo aggiuntivo deve appartenere all'utente?
2. Come eseguiamo il processo di configurazione della connessione a banda larga mobile come root? (problemi di sicurezza?)

Aggiornamento 11 – 09 dicembre 2015

wvdial funziona con USB3 e non funziona con USB1.

Si prega di trovare il syslog qui.

È incluso anche l'output di dmesg | grep tty > /tmp/dmesg.tty.txt . Ma vedi quelle quattro righe vicino all'inizio del file?

Aggiornamento dal 12 al 10 dicembre 2015

1. Riga 4 commentata (SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end" ) in /lib/udev/rules.d/77-mm-zte-port-types.rules .

2. Riavviato la mia macchina. Soft ha scollegato il cavo e inserito il modem.

3. Ho provato a connetterti. Non riuscito.

Il file syslog è qui.

Aggiornamento dal 13 al 10 dicembre 2015

Per pura disperazione, per vedere se alcune modifiche locali stanno influenzando la connessione, ho testato la macchina con i DVD di Ubuntu 15.04 e 15.10.

1. Avviato la macchina con Xubuntu 15.04 64 bit DVD. La connessione è riuscita come un incantesimo.
2. Avviato la macchina con Ubuntu 15.10 64 bit DVD. La connessione non è riuscita proprio come prima.

Cosa è successo tra le 15:04 e le 15:10?

Così frustrante.

Aggiornamento dal 14 al 10 dicembre 2015

1. Creato un nuovo file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules come indicato nella risposta.

2. Riavviato la mia macchina (o eseguito sudo udevadm control --reload , in realtà li ho provati entrambi). Inserito il modem.

3. Il modem è stato riconosciuto.

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

4. Soft ha scollegato il cavo e ha provato a connettersi utilizzando il modem. Non riuscito.

5. Modem espulso.

La macchina si blocca una volta, è un evento casuale? La mia macchina non
di solito si blocca una volta all'anno.

Il file syslog e i file delle regole creati sono qui.

Aggiornamento dal 15 all'11 dicembre 2015

1. Aggiunte le seguenti righe a /lib/udev/rules.d/40-usb_modeswitch.rules .

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

2. Ha lasciato il file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intatto.

3. Riavviato la mia macchina. Inserito il modem.

4. Il modem è stato riconosciuto.

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

5. Soft ha scollegato il cavo e ha provato a connettersi. Non riuscito.

6. Modem espulso.

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

8. Riavviato e riprovato l'intero processo. Di nuovo fallito.

Il file syslog (completo, non ho corso il rischio di perdere nessuna
parte importante) e il file delle regole menzionato (40) sono qui.

Aggiornamento dal 16 all'11 dicembre 2015

1. Ha lasciato solo una regola 1232 in
   /lib/udev/rules.d/40-usb_modeswitch.rules , rimosso l'altro
   .

2. Eseguito sudo udevadm control --reload .

3. Inserito il modem.

4. Il modem è stato riconosciuto.

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

5. Soft ha scollegato il cavo e ha provato a connettersi. Non riuscito.

6. Modem espulso.

Ma non abbiamo testato il sistema predefinito sopra? Volevi lasciare /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules al suo posto?

Il file syslog (completo, non ho corso il rischio di perdere nessuna
parte importante) e il file delle regole menzionato (40) sono qui

Aggiornamento dal 17 all'11 dicembre 2015

1. Commentato la regola 1232 in
   /lib/udev/rules.d/40-usb_modeswitch.rules , ne ha aggiunto uno per il 2003.

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

2. Eseguito sudo udevadm control --reload .

3. Inserito il modem.

4. Il modem è stato riconosciuto come 1232 dispositivo. Non mi viene offerto di provare a connettermi (per quanto ne so, non verrà registrato su una rete a banda larga a meno che il passaggio non sia avvenuto nel 2003)

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

5. Modem espulso.

Il file syslog e il file di regole menzionato (40) sono qui

Aggiornamento dal 18 all'11 dicembre 2015

1. Metti tutti i file delle regole nella loro forma originale.

2. Ho guardato lsusb output ogni secondo usando uno script di shell
   . Output acquisito in file con data e ora.

3. Inserito il modem. (Il modem appare per la prima volta nel file
   lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt ). Come possiamo scoprire
   dalle acquisizioni, è chiaro che passa da un dispositivo 1232 a
   a uno 2003.

4. Ho provato a connetterti. Non riuscito.

5. Modem espulso.

Il file syslog, con data e ora lsusb gli output e i file delle regole menzionati sono qui.

Ora, potresti voler abbinare gli output di syslog con i timestamp.

Aggiornamento dal 19 all'11 dicembre 2015

Ho eseguito questo test in una direzione completamente nuova con il desiderio di
poter isolare i problemi.

1. Salvato in un supporto portatile /lib/udev/rules.d/40-usb-media-players.rules e /lib/udev/rules.d/77-mm-zte-port-types.rules (dalla macchina Ubuntu 15.10).

2. Avviato la macchina utilizzando il DVD Xubuntu 15.04 a 64 bit.

3. Eseguito diff 77-mm-zte-port-types.rules
/lib/udev/rules.d/77-mm-zte-port-types.rules >
diff15.10and15.04_77-mm.txt . Il primo file è quello salvato
   del 15.10.

   L'esame del file diff non mostra idProduct 1232 o 2003.

4. Eseguito diff 40-usb_modeswitch.rules
/lib/udev/rules.d/40-usb_modeswitch.rules >
diff15.10and15.04_40-usb.txt . Anche in questo caso, il primo file è da quello
   salvato dal 15.10.

   Anche in questo caso, l'esame del file diff non mostra idProduct 1232 o 2003.

5. Inserito il modem. Il modem è stato riconosciuto come modem.

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

6. Potrebbe connettersi prontamente dopo aver impostato una connessione a banda larga mobile.

7. Modem espulso.

8. Installato l'ultimo USB_ModeSwitch.

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

   Ora restituisce NULL, come previsto.

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

10. Inserito il modem. Il modem è stato riconosciuto come modem.

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

11. Potrebbe connettersi facilmente.

Avrei potuto provare ad aggiornare MM e NM a quello di Ubuntu 15.10, solo per vedere dove si interrompe. In realtà ho provato ma ho rinunciato a causa di infiniti problemi di dipendenza.

Tutti i file diff sopra menzionati sono qui.

Aggiornamento dal 20 al 12 dicembre 2015

Test 1

1. Il /lib/udev/rules in condizioni originali.

2. Il dispositivo modem non è stato ancora inserito in questa sessione.

3. Configura ModemManager per il debug e la configurazione di 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. Collegato il modem e aspettato finché non dice che è registrato nella rete a banda larga.

5. Tentativo di connessione senza successo.

6. Modem espulso.

7. File di registro compressi.

Test 2

Ripetuto il test precedente con
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules a posto.

I nomi dei file di registro sono autoesplicativi.

Tutti i file di registro di cui sopra più syslog e i 78 file di regole sono
qui.

Vorrei che tutti i file di registro fossero dotati di timestamp, semplificando la corrispondenza.

Aggiornamento dal 21 al 15 dicembre 2015

1. Modificato il file delle regole come suggerito.
2. Riavviato la mia macchina.
3. Ho inserito il modem e ho provato a connetterti. Non ha funzionato.

Il file delle regole e il syslog sono qui.

Aggiornamento dal 22 al 16 dicembre 2015

Come consigliato in un commento, ho installato vari kernel da
http://kernel.ubuntu.com/~kernel-ppa/mainline/ e ho provato a connetterti
usando il modem dopo l'avvio in ciascuno.

1. 4.2.8-040208-generico, errore.

2. 4.1.15-040115-generico, guasto.

3. 4.0.9-040009-generico, errore.

Quindi, forse, possiamo escludere il problema del kernel.

Aggiornamento dal 23 al 16 febbraio 2016

Il modem ha iniziato a funzionare in Ubuntu 16.04. Questa versione è ancora in Alpha 1, ma funziona bene sul mio laptop.

Risposta accettata:

Caricamento del ofono il pacchetto ha funzionato bene, probabilmente, ma a quanto pare il tuo modello di modem, ZTE MF193E, non è nell'elenco ZTE. Confrontandolo con altri modem ZTE, ad esempio MF190J, è probabile che questo modem necessiti dello stesso speciale udev regola, per eseguire usb_modeswitch quando il dongle è inserito, e per farlo puoi, come root, aggiungere un nuovo udev regola nel file
/lib/udev/rules.d/40-usb_modeswitch.rules
con le seguenti due righe, ad esempio, vicino a # ZTE MF190J commento:

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

più una riga vuota, in modo che sia piacevole alla vista.

Probabilmente è saggio riavviare dopo, solo per scoprire che tutto funziona come per magia 🙂

O no. Come sai, per me è un'acqua profonda, ma se ancora non funziona, sarebbe necessario un altro registro di debug di ModemManager, per un'altra ipotesi folle.

MODIFICA:

Ora sto guardando le due righe in modemmanager.txt:

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

e

[mm-broadband-bearer.c:994] parse_pdp_list(): Found PDP context with CID 1 and PDP type ipv4 for APN 'wap'

Immagino che il primo si riferisca alla configurazione della tua banda larga, mentre il secondo si riferisca all'associazione interna a un "contesto PDP" (qualunque esso sia). A quanto pare, il modem offre 9 contesti alternativi, incluso uno con apn='WAP' , ma il ModemManager si accontenta di una corrispondenza senza distinzione tra maiuscole e minuscole.

La differenza tra maiuscole e minuscole potrebbe essere la causa del problema successivo:ad esempio, quel ppp vuole un 'wap' configurazione (anziché 'WAP' ) e non lo trova, o che il terminale remoto si aspetta apn='WAP' , ma ottiene "wap" su cui si soffoca.

La prima opzione potrebbe essere facilmente testata (ed esclusa, probabilmente) modificando la configurazione per utilizzare "wap" anziché "WAP". Potresti averlo già provato, ma in quel momento senza il ofono pacchetto, quindi un altro test non farà male, anche se la seconda opzione è più probabile.

Anche la seconda opzione è più problematica, dato che è disponibile una corrispondenza maiuscola del "contesto PDP" dal modem. Cercando su Google questo problema, sembra che la corrispondenza senza distinzione tra maiuscole e minuscole sia corretta dalla specifica (apparentemente rilevante) "3GPP TS 23.003 capitolo 9.1" e una patch per farlo è stata aggiunta a ModemManager nel novembre dello scorso anno (nella sua versione mm-1-4, posso raccogliere). Quindi, in questo caso, il tuo modem non è stato informato e si aspetta una corrispondenza con distinzione tra maiuscole e minuscole, mentre ModemManager sfortunatamente utilizza la corrispondenza senza distinzione tra maiuscole e minuscole piuttosto che come ripiego.

Una soluzione per il secondo problema è ovviamente usare un diverso ModemManager :trovando e installando una versione precedente a questa patch, oppure (con abbastanza tempo libero), lancia il tuo ModemManager . Ma nessuno dei due è qualcosa da fare per capriccio, quindi forse abbiamo bisogno di dare un'occhiata un po' per ottenere più prove che questo è (ora) il problema e, se possibile, trovare altri modi per aggirarlo. Oppure, con un po' di fortuna, passa qualcuno che sa qualcosa...

MODIFICA 2

Sì, il rollback della versione non è facile a causa delle dipendenze. E anche rotolare il tuo è tutt'altro che una gioia.

Due possibili strumenti utili:comando mmcli e
(http://m2msupport.net/m2msupport/module-tester/).

Il problema, penso, è che ModemManager seleziona il contesto PDP 1 con apn='wap' dove dovrebbe selezionare il contesto PDP 9 con apn='WAP'. Forse questo può essere risolto utilizzando uno di quegli strumenti. O per essere in grado di forzare una selezione di 9 durante la connessione, o eliminando i contesti "wap" non validi dal modem, di cui è pubblicizzato lo strumento di test dei moduli.

Lo strumento modem-tester sembra essere uno strumento java nel browser, quindi è necessario che il browser sia configurato per sapere dove si trova il tuo java e hai bisogno che java sia noto. Quindi per favore esplora questo approccio; Non l'ho usato da solo, ma vedendo gli screenshot, suppongo che presenterà i contesti PDP come la scheda "Chiamate dati", dove prima prendi nota di tutto ciò che mostra, quindi modifichi le voci "wap" in distorcere le etichette apn "wap" in modo che siano, ad esempio, "wap1" e "wap2" (in modo da "nasconderle" quando si cerca "WAP"). Quindi salva e chiudi, quindi destreggia di nuovo il dongle. Prendi un registro; sembra che syslog sia sufficiente ora, nel caso si rifiuti ancora di giocare.

Il mmcli il comando sembra utile anche in questa storia; fare man mmcli per leggerlo, ma non ho visto nulla sui contesti PDP lì.

MODIFICA 3

Ottima scelta! per testare dal DVD. Questo ci ha detto che sono sulla strada sbagliata con l'APN e che tutto sta nel far apparire ppp. Almeno, quello sarebbe il mio nuovo albero a cui abbaiare.

Innanzitutto prendiamo atto che c'è una differenza di versione per pppd (da 2.4.5 a 2.4.6), ma probabilmente non è un problema, poiché tutti su un dongle sarebbero stati in questa escursione.

Hmm, ppp; Ho bisogno di risvegliare i miei ricordi dell'ultimo millennio :-). Sfortunatamente sono impegnato oggi, ma toccherò la base quando avrò tempo, per vedere fino a che punto sei arrivato. I miei primi vicoli da esaminare sarebbero:1) l'utente è nel gruppo giusto? 2) le credenziali sono corrette? 3) le mod del file di configurazione ppp/chat sono corrette? Il log di debug di ppp esce in nm.txt (come qualche giorno fa), ma dovrebbe esserci anche un modo per chiedergli una registrazione più dettagliata.

MODIFICA 4

Assicurati /etc/ppp/pap-secrets e /etc/ppp/chap-secrets avere il gruppo dip (usando chgrp secondo necessità) e modalità 740 (o -rw-r----- ) (usando chmod come necessario). Il mio no.

MODIFICA 5

Che ne dici di questo albero, quindi:Confrontando il wvdial funzionante syslog con syslog non funzionante, sembra che per qualche motivo wvdial usato ttyUSB3 mentre il ModemManager non funzionante continua a usare ttyUSB1 . Non sono sicuro che sia significativo, ma a quanto pare ma ttyUSB1 e ttyUSB3 entrambi rispondono come modem con capacità AT.

Quindi, come prova, forse puoi modificare /etc/wvdial.conf quindi sotto [Dialer Defaults] include la riga:

Modem = /dev/ttyUSB1

per un test e ttyUSB3 per un altro; entrambi in esecuzione come root; giusto per vedere se c'è un comportamento diverso. Soprattutto se si utilizza ttyUSB1 è un problema mentre l'utilizzo di ttyUSB3 non lo è, quindi sarebbe bene esaminare come fare in modo che ModemManager utilizzi anche ttyUSB3. Per qualsiasi altro risultato del test, direi che torneremo a inseguire furetti nella terra di ppp.

MODIFICA 6

Il registro dmesg può essere ignorato, credo; è stato così in tutti i log.
Il nuovo syslog mostra solo il test ttyUSB3, ma forse possiamo presumere che la vita migliorerà se NetworkManager si può pensare di usare ttyUSB3 e ignorare ttyUSB1 (per questo modem).

Ho anche trovato (https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784) soprattutto con il post n. 10 sconcertante 🙁

L'apparentemente applicabile udev regola in /lib/udev/rules.d/77-mm-zte-port-types.rules non si applica, ma dovrebbe essere dove andare. E, con solo una visione molto rudimentale, pre-101, del udev magic, prenderei comunque in considerazione di mettere in discussione la sua 4a riga, che dice:

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

Penso che quella riga abbia bisogno di un # iniziale per essere commentato. In dettaglio, la mia lettura del file è che richiede uno stato di chiamata di SUBSYSTEM==”tty” e SUBSYSTEMS=”usb” per utilizzare i bit buoni, comprese le regole del prodotto “2003”, e almeno per il test, dovrebbe essere sicuro saltare il filtro "tty". E non ho niente di meglio in questo momento.

EDIT 7

Dopo aver trascorso del tempo di qualità con il mio motore di ricerca preferito, credo un po' di più che la scelta di ttyUSB sia un problema alla radice qui. La regola udev che ho indicato è ok e dovresti ripristinare quella modifica.

Tuttavia, ho iniziato a credere che le regole di configurazione verso la fine di quel file, per l'ID prodotto "2003" siano fuorvianti. Dai registri, mi sembra che l'ID prodotto "2003" sia in realtà il lato del dispositivo di memoria del dongle, mentre il lato modem ha l'ID prodotto "1232". Puoi verificarlo replicando le due regole "2003" per l'ID prodotto "1232", nel file /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 meglio, aggiungi un nuovo file accanto ad esso, ad es. denominato 78-ralph.rules , ma devi anche aggiungere la protezione SUBSYSTEM e SUBSYSTEMS attorno ad esso.

Quindi, estrai il dongle, esegui udevadm control --reload (o riavviare) e inserire il dongle. E poi ancora un altro syslog cattura, a meno che non funzioni ora.

Il problema effettivo, tuttavia, è che ModemManager scarta il plugin libmm-plugin-zte.so al pre-probing e finisce per utilizzare un gestore modem generico. Se ho ragione sull'ID prodotto, questo potrebbe essere il motivo; quel pre-sondaggio cerca un ID_MM_ZTE_PORT_TYPE_MODEM attribuzione, e questo è assente per l'ID prodotto "1232" (prima della patch), con l'effetto che il plug-in zte viene scartato.

MODIFICA 8

Il syslog log è un po' corto; manca l'inizio in cui ModemManager non riesce a installare il plugin zte. Tuttavia, è chiaro che il plug-in modem generico viene comunque utilizzato. Ora, potrebbe essere che il usb_modeswitch anche la regola che ti ho dato all'inizio è sbagliata; decide di passare da a "2003" quando pensavo fosse passato da “2003”. Ma, man usb_modeswitch (che avrei dovuto guardare prima) in qualche modo suggeriscono che si sposta da a un ID prodotto anziché da esso. In ogni caso, il registro mostra che ciò accada. Pertanto, modifica la regola per utilizzare invece "1232" e riprova.

Se non altro, almeno devo imparare un po' di udev.

MODIFICA 9

Bene. Il problema è ancora (o anche) che ModemManager rilascia il plug-in ZTE al pre-probing. I registri di debug di ModemManager per 15.10 (set di registri "debuglog*") raccontano tutti la storia che il plug-in ZTE è stato scartato a causa del test vendor-id/product-id.

Vai alla fonte, Luke! Ho colto l'occasione per vedere brevemente il codice sorgente di ModemManager, e indica che il plugin è una tabella di vid/pid che non include 19d2/2003 … però, non ho trovato quella sorgente della tabella, quindi non ho potuto verifica.

O forse c'è un problema di tempismo qui. Ad esempio, che ModemManager esegua il pre-probing mentre il dispositivo è 19d2/1232. Questo pensiero è in linea con l'osservazione che avere le regole udev 78-mm-zte-port-types-RALPH.rules rende ModemManager un po' più felice con il dispositivo. Ma allora, perché non rimane felice e non utilizza quel plug-in quando il dispositivo passa a 19d2/2003?

Forse sono necessari più log 🙂 Con ModemManager eseguito il debug e anche un'acquisizione del comando udevadm monitor --e |& tee udevadm.log (in un altro terminale) quando si collega il dispositivo. Ho ricevuto quel comando da (https://wiki.ubuntu.com/DebuggingUdev)

Fallo due volte:una volta senza 78-mm-zte-port-types-RALPH.rules e una volta con le regole... entrambe le volte da un nuovo riavvio. Cioè

1. imposta /lib/udev/rules.d con o senza il *-RALPH.rules file
2. estrai il dispositivo
3. riavvia
4. imposta ModemManager per il debug e imposta udevadm capture
5. collega il dispositivo e attendi un minuto
6. comprimere i file di registro
7. Ripetere da 1 con il prossimo test

Quella registrazione dovrebbe dire dove è stato rilasciato il plug-in ZTE e, da quanto ho capito, parlerà anche della gestione degli eventi udev.

MODIFICA 10

(Sono quasi alla fine del mio legame qui, ma ho ancora uno o due respiri rimasti :-)

Innanzitutto, tutti gli udev le decorazioni sembrano finire come dovrebbero, con solo un paio di punti interrogativi in ​​un paio di attributi. In particolare, le 78-*-RALPH.rules dovrebbe essere buttato via; non è utile.

Penso di poter leggere qualcosa da questo, ma non sono esattamente sicuro di come dovrebbe essere risolto. Fondamentalmente, per come la vedo io, quando il dongle è collegato c'è una raffica di eventi udev. Focalizzandoci su quelli che riguardano ttyUSB1, c'è un evento “in anticipo”:

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

che causa il usb_serial driver da caricare e /dev/ttyUSB1 apparire. Ciò in particolare provoca un altro evento:

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

Penso che attivi anche ModemManager . Devi andare su syslog per vedere le prove di ciò, poiché non esiste una stretta correlazione tra i registri. L'evento è contrassegnato dall'ora 3867.435102 e syslog presenta il suo ModemManager successivo più vicino log line subito dopo una linea di log del kernel contrassegnata da 3867.437412 .

Nella mia linea di pensiero, ModemManager non dovrebbe essere ancora attivato, ma solo dopo il successivo evento ttyUSB1:

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

che ha allegato gli attributi ZTE.

Nel registro MM, saremmo alla riga con il timbro 1449934745.363291 , che a quanto pare è un timestamp "in tempo reale" piuttosto che un timestamp del kernel.

ModemManager quindi viene eseguito il pre-probing in1449934745.450398 , ovvero 87 ms dopo, che in termini di tempo del kernel sarebbe vicino a 3867.524519 e 55 ms prima di quel rapporto sull'evento UDEV "buono" sopra.

Nota che in syslog , ModemManager presenta reclami che ttyUSB1 non ha i suoi attributi impostati e forse quel reclamo è correlato al "contrassegno" che si verifica in 80-mm-candidate.rules . Dal commento in quel file, quel contrassegno sembra essere un tentativo di affrontare esattamente questo problema, ma in tal caso non sembra funzionare in questo caso.

Forse una possibilità per risolvere questo problema sarebbe cambiare la regola "tty" in 80-mm-candidate.rules essere:

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

Nella mia mente, ciò assicurerebbe che il ID_MM_CANDIDATE l'impostazione viene ritardata fino a quando non vengono impostati gli attributi ZTE. Il .ID_PORT l'impostazione è un effetto di un 60-serial.rules regola (chiamata 60-persistent-serial.rules prima), e la condizione aggiunta alla regola di marcatura è semplicemente che abbia un valore.

La condizione non è esattamente un attributo ZTE, solo per mantenere la regola più generica. Un passaggio più specifico sarebbe invece richiedere ENV{.MM_USBIFNUM}="?*" invece, poiché l'assegnazione qui avviene tramite 77-mm-zte-port-types.rules .

In generale non sono molto sicuro di udev ordinamento delle regole, e non sono nemmeno del tutto sicuro che questo fermi davvero ModemManager dall'agire troppo in fretta. Tuttavia, in caso contrario, 80-mm-candidate.rules avrebbe poca o nessuna funzione, e forse tutto sarebbe dovuto ai "miglioramenti" di ModemManager dal 15.04.

MODIFICA 21

sospiro. Probabilmente irrilevante, ma potresti voler controllare il tuo 7-zte-mutil_port_device.rules file; è un residuo di altre sperimentazioni? Comunque, non pertinente qui.

Manca ancora quasi un secondo tra 515.558184 e 516.381549 dove ModemManager eagerly and erroneously grabs /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.