Errore "ip-config-non disponibile" quando il modem USB tenta di connettersi

Ho un modem ZTE MF-193E che ha funzionato bene prima. Quando ho acquistato questo modem più di un anno fa, ha funzionato immediatamente. Ora, mentre Ubuntu sta procedendo nella versione, le cose stanno diventando sempre più difficili per me.

Questo modem ha funzionato anche un paio di mesi fa con Ubuntu 15.04 (64 bit). Ora, in Ubuntu 15.10 (64 bit), non è possibile connettersi.

Ho impostato una connessione a banda larga mobile . Ho provato varie stringhe per APN, ma questo non è stato un problema prima.

(Il modem funziona bene in Windows 10, quindi questo non è affatto un problema hardware. Inoltre, la GUI di Modem Manager rileva bene questo dispositivo. Gli SMS possono essere inviati e ricevuti senza alcun problema.)

Quando inserisco il modem, viene rilevato correttamente, un'icona CD viene visualizzata in Unity con il nome del modem. Pochi secondi dopo, ricevo una finestra di messaggio

Mobile Broadband Network: you are registered on the home network

vicino all'icona della rete.

Quando provo a connettermi, l'icona wireless nell'applet del gestore di rete avvia quei movimenti centrifughi, ma alla fine non riesce a connettersi e un messaggio mi dice che sono offline.

La linea da cui ho potuto isolare /var/log/syslogè questa,

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

Tuttavia, non sono sicuro che questo sia quello rilevante.

Altre linee da /var/log/syslogpossono essere trovate qui .

Aggiornamento 1 - 06 dicembre 2015

Come sottolineato da un membro gentile, ha provato l' nf_conntrack_pptpapproccio del modulo.

Eseguiti i seguenti comandi,

$ 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

Quindi ho provato il mio modem, lo stesso errore. Nessuna modifica riconoscibile nel registro.

Aggiornamento 2 - 06 dicembre 2015

Eseguito come root,

systemctl restart network-manager.service

Nessuna uscita sullo schermo (terminale).

Il registro corrispondente dal punto precedente a un tentativo di connessione tramite modem è disponibile qui .

Aggiornamento 3 - 06 dicembre 2015

Installato ofonoe quindi riprovato il modem.

Si prega di consultare il registro qui .

Aggiornamento 4 - 06 dicembre 2015

Ancora una volta eseguito come root,

systemctl restart network-manager.service

Il registro corrispondente dal punto precedente a un tentativo di connessione tramite modem è disponibile qui .

Aggiornamento 5 - 06 dicembre 2015

Modificato tutto "nega" per "consentire" in /etc/dbus-1/system.d/nm-dispatcher.conf.

Ho provato a connettermi. Senza fortuna.

Alcune reti si collegano e si disconnettono con una connessione Ethernet.

Seguito da sudo systemctl restart network-manager.service.

Modem plug out e plug in.

Ho provato di nuovo a connettermi. Non si connette.

Il registro è qui .

Aggiornamento 6 - 06 dicembre 2015

eseguito

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

e

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

Impossibile eseguire a mm-test.pycausa di più errori. Ho trovato il file nella posizione indicata. Ottenuto da questo, https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

I comandi sopra sono in qualche modo diversi da quelli nel Wiki.

I file di registro sono qui .

Aggiornamento 7 - 07 dicembre 2015

Eseguito di nuovo (dopo la modifica suggerita /lib/udev/rules.d/40-usb_modeswitch.rulese il riavvio)

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

e

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

Il /var/log/syslogè incluso pure.

I file di registro sono qui .

Aggiornamento 8 - 8 dicembre 2015

Il set di registri aggiornato è qui .

Aggiornamento 9 - 8 dicembre 2015

Test 1

1. Questa volta ha avviato il computer da un DVD di Ubuntu 14.04 a 32 bit. Non appena il computer si è avviato, ha iniziato a catturare il registro MM.

2. Inserito il modem. lsusbha mostrato che veniva riconosciuto come un dispositivo 19d2: 1232 che doveva essere spostato su un dispositivo 19d2: 2003. Dal momento che l'installazione di usb-switchwitch richiede il riavvio della macchina (e quindi di perdere l'installazione per l'esecuzione del DVD), ho preparato un file switch personalizzato e ho cambiato il modem dalla riga di comando ( sudo usb_modeswitch -I -c 19d2:2003).

3. Non appena la commutazione è stata effettuata, sono stato informato che ero Mobile Broadband Networkattivo e un appreard Nuova connessione a banda larga nel menu del gestore di rete.

4. Ho impostato la connessione sopra nel solito modo (il nome APN non era un problema) e la connessione è stata stabilita automaticamente.

5. Ho disconnesso ed espulso il modem.

6. Interrotto l'acquisizione del registro MM.

Il registro MM completo e il syslog per l'avvio della sessione per l'espulsione del modem sono disponibili qui .

Test 2

Lo stesso test con un DVD di Ubuntu 14.04 a 64 bit.

I registri sono disponibili qui .

Aggiornamento 10 - 09 dicembre 2015

Questa volta testato wvdiale trovato che se wvdialviene eseguito come root, otteniamo una connessione corretta .

La wvdialconf e log e syslog corrispondenti sono qui

Congettura primaria: la situazione potrebbe avere qualcosa a che fare con il gruppo di utenti dell'utente corrispondente.

Ma come indicato qui ,

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

Ma come possiamo trovare,

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

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

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

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

Aggiornamento 11 - 09 dicembre 2015

wvdialfunziona con USB3 e non funziona con USB1.

Si prega di trovare il syslog qui .

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

Aggiornamento 12 - 10 dicembre 2015

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

2. Ho riavviato la mia macchina. Soft disconnesso il cavo e inserito il modem.

3. Ho provato a connettermi. Senza esito.

Il file syslog è qui .

Aggiornamento 13-10 dicembre 2015

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

1. Avviato la macchina con Xubuntu 15.04 a 64 bit DVD. La connessione ha avuto successo come un fascino.
2. Avviato la macchina con Ubuntu 15.10 a 64 bit DVD. La connessione non è riuscita proprio come prima.

Che cosa è successo tra il 15.04 e il 15.10?

Così frustrante.

Aggiornamento 14 - 10 dicembre 2015

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

2. Riavviato il mio computer (o eseguito sudo udevadm control --reload, effettivamente provato entrambi). Inserito il modem.

3. Il modem è stato riconosciuto.

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

4. Soft ha staccato il cavo e ha provato a connettersi utilizzando il modem. Senza esito.

5. Espulso il modem.

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

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

Aggiornamento 15-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. Lascia il file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesintatto.

3. Ho 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 staccato il cavo e ha provato a connettersi. Senza esito.

6. Espulso il modem.

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

8. Riavviato e riprovato l'intero processo. Di nuovo senza successo.

Il file syslog (completo, non ho rischiato di perdere nessuna parte importante) e il file della regola menzionato (40) sono qui .

Aggiornamento 16-11 dicembre 2015

1. Lasciata solo una regola 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, rimossa l'altra.

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 staccato il cavo e ha provato a connettersi. Senza esito.

6. Espulso il modem.

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

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

Aggiornamento 17-11 dicembre 2015

1. Commentato la regola 1232 in /lib/udev/rules.d/40-usb_modeswitch.rules, aggiunta una 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 un dispositivo 1232 . Non mi viene offerto di provare a collegarmi (per quanto ne so, non sarà registrato sulla rete a banda larga a meno che non sia avvenuta la commutazione al 2003)

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

5. Espulso il modem.

Il file syslog e il file della regola menzionato (40) sono qui

Aggiornamento 18-11 dicembre 2015

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

2. Ho guardato l' lsusboutput ogni secondo usando uno script di shell. Output acquisito in file con data e ora.

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

4. Ho provato a connettermi. Senza esito.

5. Espulso il modem.

Il file syslog, gli lsusboutput timestamp e i file delle regole menzionati sono qui .

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

Aggiornamento 19-11 dicembre 2015

Ho eseguito questo test in una direzione completamente nuova con l'augurio di poter isolare i problemi.

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

2. Avviato il computer usando Xubuntu 15.04 a 64 bit DVD.

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 proviene da quello salvato dal 15.10.

   L'esame del file diff non mostra idProduct1232 o 2003.

4. Eseguito diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Ancora una volta, il primo file proviene da quello salvato dal 15.10.

   Ancora una volta, l'esame del file diff non mostra idProduct1232 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 facilmente dopo aver impostato una connessione a banda larga mobile.

7. Espulso il modem.

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 rompe. In realtà ci ho provato ma ho rinunciato a causa di infiniti problemi di dipendenza.

Tutti i file diff sopra menzionati sono qui .

Aggiornamento 20-12 dicembre 2015

Test 1

1. In /lib/udev/rulescondizioni originali.

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

3. Setup ModemManager per il debug e l'installazione dell'acquisizione udevadm.

   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 atteso che dicesse che è registrato nella rete a banda larga.

5. Ho provato a connettermi senza successo.

6. Espulso il modem.

7. File di registro compressi.

Test 2

Ripetuto il test sopra riportato con /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesin posizione.

I nomi dei file di registro sono autoesplicativi.

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

Vorrei che tutti i file di registro fossero corredati di timestamp, facilitando la corrispondenza.

Aggiornamento 21-15 dicembre 2015

1. Modificato il file della regola come suggerito.
2. Ho riavviato la mia macchina.
3. Inserito il modem e provato a connettersi. Non ha funzionato.

Il file delle regole e il syslogsono qui .

Aggiornamento 22-16 dicembre 2015

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

1. 4.2.8-040208-generico, guasto.

2. 4.1.15-040115-generico, errore.

3. 4.0.9-040009-generico, errore.

Quindi, forse, possiamo escludere il problema del kernel.

Aggiornamento 23-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.

Il caricamento del ofonopacchetto 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 della stessa udevregola speciale , da eseguire usb_modeswitchquando viene inserita la chiave hardware e per ottenere che, come root, è possibile aggiungere una nuova udevregola al file
/lib/udev/rules.d/40-usb_modeswitch.rules
con le seguenti due righe ad esempio, da qualche parte vicino al # ZTE MF190Jcommento:

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

più una linea vuota, quindi sembra piacevole alla vista.

È probabilmente saggio riavviare dopo quello, solo per scoprire che tutto funziona come per magia :-)

O no. Come sapete, per me si tratta di acque profonde, ma se ancora non funziona, sarebbe necessario un altro registro di debug di ModemManager, per un'altra ipotesi selvaggia.

MODIFICARE:

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 tua configurazione a banda larga, mentre il secondo si riferisce al legame interno a un "contesto PDP" (qualunque cosa sia). A quanto pare, il modem offre 9 contesti alternativi, incluso uno con apn='WAP', ma ModemManagersi 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, che ppp vuole una 'wap'configurazione (piuttosto che 'WAP') e non la trova, o che il terminale remoto si aspetta apn='WAP', ma ottiene "wap" su cui soffoca.

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

La seconda opzione è anche più un problema, dato che esiste una corrispondenza "Contesto PDP" maiuscola disponibile 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 ModemManagernovembre dello scorso anno (nella sua versione mm-1-4, Posso riunirmi). Quindi, in questo caso, il tuo modem non è stato detto e si aspetta una corrispondenza con distinzione tra maiuscole e minuscole, mentre ModemManagersfortunatamente usa una corrispondenza senza distinzione tra maiuscole e minuscole anziché come fallback.

Una soluzione per il secondo problema è ovviamente quella di usarne una diversa ModemManager: trovando e installando una versione precedente a questa patch oppure (con abbastanza tempo libero), esegui il roll-off ModemManager. Ma nessuno dei due è qualcosa da fare per capriccio, quindi forse dovremmo cercare un po 'in giro per ottenere più prove che questo è (ora) il problema e, se possibile, trovare altri modi per aggirarlo. O con un po 'di fortuna, qualcuno che sa qualcosa passa ...

MODIFICA 2

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

Due possibili strumenti utili: command mmclie ( http://m2msupport.net/m2msupport/module-tester/ ).

Il problema, penso, è che ModemManager sceglie il contesto 1 del PDP con apn = 'wap' dove dovrebbe scegliere il contesto 9 del PDP con apn = 'WAP'. Forse questo può essere risolto usando uno di quegli strumenti. O essere in grado di forzare una selezione di 9 durante la connessione o eliminando dal modem i contesti di "wap" errati, di cui è pubblicizzato lo strumento modulo tester.

Lo strumento modem tester sembra essere uno strumento java nel browser, quindi è necessario che il browser sia configurato per sapere dove si trova java e che è necessario conoscere java. 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 modifica 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 e destreggia di nuovo il dongle. Prendi un registro; sembra che il syslog sia sufficiente ora, nel caso in cui si rifiuti ancora di giocare.

Anche il mmclicomando sembra utile in questa storia; faccio man mmclia leggere su di esso, ma non ho visto nulla di 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 sì che ppp emerga. Almeno, sarebbe il mio nuovo albero a cui abbaiare.

Innanzitutto prendiamo nota che esiste una differenza di versione per pppd (dalla 2.4.5 alla 2.4.6), ma probabilmente non è un problema, dato che tutti quelli su un dongle sarebbero stati in questa escursione.

Hmm, ppp; Devo suscitare i miei ricordi dell'ultimo millennio :-). Purtroppo oggi sono occupato, 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 giuste? 3) la mod del file di configurazione ppp / chat è corretta? Il registro di debug ppp esce in nm.txt (come pochi giorni fa), ma dovrebbe esserci anche un modo per richiederlo per una registrazione più dettagliata.

MODIFICA 4

Accertarsi /etc/ppp/pap-secretse /etc/ppp/chap-secretsdisporre del gruppo dip(usando chgrpsecondo necessità) e della modalità 740(o -rw-r-----) (usando chmodsecondo necessità). Il mio no.

MODIFICA 5

Che ne dici di questo albero, quindi: confrontando il wvdialsyslog funzionante con il syslog non funzionante, sembra che per qualche ragione venga wvdialusato ttyUSB3mentre il non funzionante ModemManagercontinua a usarlo ttyUSB1. Non sono sicuro che sia significativo, ma a quanto pare ma ttyUSB1ed ttyUSB3entrambi rispondono come modem AT.

Quindi, come test, forse puoi modificarlo in /etc/wvdial.confmodo che [Dialer Defaults]includa la riga:

Modem = /dev/ttyUSB1

per un test e ttyUSB3per un altro; entrambi in esecuzione come root; solo per vedere se c'è un comportamento diverso. Soprattutto, se l'utilizzo ttyUSB1è un problema, mentre l'uso di ttyUSB3 non lo è, sarebbe bene esaminare come far sì che ModemManager usi anche ttyUSB3. Per qualsiasi altro risultato del test, direi che torneremo a inseguire i furetti in terra ppp.

MODIFICA 6

Penso che il registro dmesg possa essere ignorato; è stato così in tutti i registri. Il nuovo syslog mostra solo il test ttyUSB3, ma forse possiamo supporre che la vita migliora se si NetworkManagerpuò usare ttyUSB3 e ignorare ttyUSB1 (per questo modem).

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

La udevregola apparentemente applicabile /lib/udev/rules.d/77-mm-zte-port-types.rulesnon si applica, ma presumibilmente sarebbe dove andare. E, con solo un'intuizione molto rudimentale e pre-101 sulla udevmagia, prenderei comunque in considerazione la possibilità di mettere in discussione la sua quarta riga, che dice:

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

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

MODIFICA 7

Dopo aver trascorso un po 'di tempo con il mio motore di ricerca preferito, credo che la scelta di ttyUSB sia un problema alla radice. 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 dispositivo di memoria della chiave hardware, mentre il lato modem ha l'ID prodotto "1232". È possibile 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, aggiungere un nuovo file accanto ad esso, ad esempio denominato 78-ralph.rules, ma è necessario aggiungere anche la protezione SUBSYSTEM e SUBSYSTEMS al suo interno.

Quindi, estrarre il dongle, eseguire udevadm control --reload(o riavviare) e inserire il dongle. E poi ancora un'altra syslogcattura, a meno che ora non funzioni.

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

MODIFICA 8

Il syslogregistro è 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, può darsi che anche la usb_modeswitchregola che ti ho dato all'inizio sia sbagliata; decide di passare a "2003" quando pensavo che fosse passato a "2003". Ma, man usb_modeswitch(che avrei dovuto guardare prima) in qualche modo suggeriscono che si sposta su un ID di prodotto piuttosto che da esso. In ogni caso, il registro mostra che ciò accade. Pertanto, modifica questa regola per utilizzare invece "1232" e riprova.

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

MODIFICA 9

Buona. Il problema è ancora (o anche) che ModemManager rilascia il plug-in ZTE durante il pre-sondaggio. I registri di debug di ModemManager per il 15.10 (set di registri "debuglogs *") raccontano tutti che il plug-in ZTE è stato scartato a causa del test ID fornitore / ID prodotto.

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 ... tuttavia, non ho trovato quella fonte di tabella, quindi non ho potuto verificare.

O forse c'è un problema di temporizzazione qui. Ad esempio, che ModemManager esegue il pre-sondaggio mentre il dispositivo è 19d2 / 1232. Questo pensiero è allineato 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 rimanere felici e utilizzare quel plugin quando il dispositivo è passato al 19d2 / 2003?

Forse sono necessari più registri :-) 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.rulese una volta con le regole ... entrambe le volte da un nuovo riavvio. ie

1. installazione /lib/udev/rules.dcon o senza il *-RALPH.rulesfile
2. estrarre il dispositivo
3. riavvio
4. imposta ModemManager per il debug e imposta l'acquisizione di udevadm
5. collegare il dispositivo e attendere un minuto
6. impacchettare i file di registro
7. ripetere da 1 con il prossimo test

Quella registrazione dovrebbe dire dove viene rilasciato il plugin ZTE e, a quanto ho capito, parlerà anche della gestione degli eventi udev.

MODIFICA 10

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

In primo luogo, tutte le udevdecorazioni sembrano finire come dovrebbero, con solo un paio di punti interrogativi in ​​un paio di attributi. In particolare, 78-*-RALPH.rulesdovrebbe essere gettato via; non è utile.

Penso di poter leggere qualcosa da questo, ma non sono esattamente sicuro di come debba essere risolto. Fondamentalmente, come la vedo io, quando il dongle è collegato c'è una raffica di eventi udev. Concentrandosi su quelli riguardanti ttyUSB1, c'è un evento "precoce":

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

che provoca il usb_serialcaricamento e la /dev/ttyUSB1visualizzazione del driver . 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 si inneschi anche questo ModemManager. Devi andare a syslogvedere prove di ciò, dal momento che non esiste una stretta correlazione tra i registri. L'evento è timestamp 3867.435102e syslogpresenta la ModemManagerriga di log successiva più vicina subito dopo la timbratura di una riga di log del kernel 3867.437412.

Secondo il mio modo di pensare, ModemManagernon 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 sulla linea stampata 1449934745.363291, che apparentemente è un timestamp "in tempo reale" piuttosto che un "timestamp del kernel".

ModemManagerpoi viene fatto con il suo pre-sondaggio a 1449934745.450398, cioè, 87 ms più tardi, che in termini di tempo del kernel sarebbe vicino 3867.524519e 55 ms prima di quel "buon" rapporto sugli eventi UDEV sopra.

Si noti che in syslog , ModemManagerpresenta reclami che ttyUSB1non hanno i suoi attributi impostati, e forse quel reclamo è correlato al "contrassegno" che sta accadendo 80-mm-candidate.rules. Con il commento in quel file, quella marcatura 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 sarebbe quella di cambiare la regola "tty" in 80-mm-candidate.rules :

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

Nella mia mente, ciò garantirebbe che ID_MM_CANDIDATE impostazione venga ritardata fino a quando non vengono impostati gli attributi ZTE. L' .ID_PORTimpostazione è un effetto di una 60-serial.rulesregola (chiamata 60-persistent-serial.rulesprima) e la condizione aggiunta alla regola di marcatura è semplicemente che ha un valore.

La condizione non è esattamente un attributo ZTE, solo per mantenere la regola più generica. Un passo più specifico sarebbe piuttosto richiedereENV{.MM_USBIFNUM}="?*" invece, dal momento che quel compito accade qui 77-mm-zte-port-types.rules.

In generale non sono molto sicuro udevdell'ordinamento delle regole e non sono nemmeno sicuro che questo si fermi davveroModemManager di agire troppo rapidamente. Tuttavia, in caso contrario, 80-mm-candidate.rulesavrebbe poca o nessuna funzione, e forse allora tutto si ridurrebbe ai "miglioramenti" a ModemManagerpartire dal 15.04.

MODIFICA 21

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

C'è ancora quasi un secondo tra 515.558184e 516.381549dove ModemManagerafferra avidamente ed erroneamente /dev/ttyUSB1, e mentre si lamenta del fatto che non sia stato impostato, passa comunque al pre-sondaggio e scarta il plugin ZTE. In altre parole, la patch della regola non creaModemManager aspettare.

Suppongo che tu abbia anche provato usando ENV{.MM_USBIFNUM}="?*"invece diENV{.ID_PORT}=="?*" .

In realtà, per confermare se l'impostazione ENV{ID_MM_CANDIDATE}=1è o meno importante, è necessario allontanarsi temporaneamente 80-mm-candidate.rules, quindi vedere (in syslog) se poi ModemManagerignora /dev/ttyUSB1o meno. Sospetto "non".

E poi, beh, forse puoi usare una versione funzionante, come 14.04, e, se necessario, magari eseguire 15.10 in una virtualbox, a meno che ovviamente non sia già tutto in una virtualbox.

Penso di aver bisogno di chiedere la sconfitta a questo punto.

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

Vorrei poter fornire ulteriori dettagli tecnici su come ha iniziato a funzionare.

Dopo averne dato un'occhiata sembra che questa non sia la prima volta che questo drago viene trattato correttamente. Era un bug prima in 12.10 e 13.04 forse il bug non era mai stato corretto o una nuova patch aveva rotto qualcosa che funzionava correttamente prima.

Spero che, se sto leggendo correttamente le vostre specifiche tecniche, dovrei indicarvi questa direzione (MF190J):

Il modem 3G (ZTE MF190J) richiede ancora una modifica manuale.

Hai provato questo:

 rfkill list up

e quindi crea questo script ed eseguilo:

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

e potrebbe funzionare bene in questo modo.