errore 'ip-config-unavailable' quando il modem USB tenta di connettersi

12

Ho un modem ZTE MF-193E che ha funzionato bene prima. Quando ho comprato questo modem più di un anno fa, ha funzionato facilmente fuori dalla scatola. Ora, mentre Ubuntu progredisce 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 può connettersi.

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

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

Quando inserisco il modem, viene rilevato tutto, un'icona del CD viene visualizzata in Unity con il nome del modem. Qualche secondo dopo, Ottengo una finestra di messaggio

Mobile Broadband Network: you are registered on the home network

vicino all'icona di rete.

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

La linea che potrei isolare da /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 sia pertinente.

Altre linee da /var/log/syslog può essere trovato qui .

Aggiornamento 1 - 6 dicembre 2015

Come sottolineato da un membro gentile, ho provato l'approccio del modulo nf_conntrack_pptp .

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. Neanche una modifica visibile nel registro.

Aggiornamento 2 - 6 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 può essere trovato qui .

Aggiornamento 3 - 6 dicembre 2015

Installato ofono e poi provato di nuovo il modem.

Vedi il log qui .

Aggiornamento 4 - 6 dicembre 2015

Di nuovo eseguito come root,

systemctl restart network-manager.service

Il registro corrispondente dal punto precedente a un tentativo di connessione tramite il modem può essere trovato qui .

Aggiornamento 5 - 6 dicembre 2015

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

Ho provato la connessione. Senza fortuna.

Alcuni network si connettono e si disconnettono con una connessione Ethernet.

Seguito da sudo systemctl restart network-manager.service .

Modem plug-in e plug-in.

Ho provato di nuovo a connetterti. Non si connette.

Il registro è qui .

Aggiornamento 6 - 6 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 mm-test.py a causa di più errori. Trovi il file nella posizione indicata. Ottenuto da questo, link .

I comandi precedenti sono leggermente diversi da quelli del Wiki.

I file di registro sono qui .

Aggiornamento 7 - 07 dicembre 2015

Eseguito di nuovo (dopo la modifica suggerita in /lib/udev/rules.d/40-usb_modeswitch.rules e riavvia)

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

Anche /var/log/syslog è incluso.

I file di registro sono qui .

Aggiornamento 8 - 8 dicembre 2015

Il set aggiornato di log è qui .

Aggiornamento 9 - 8 dicembre 2015

Test 1

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

  2. Inserito il modem. lsusb ha mostrato che veniva riconosciuto come a 19d2: dispositivo 1232 che deve essere convertito in un 19d2: 2003 dispositivo. Poiché l'installazione di usb-modeswitch richiede il riavvio di macchina (e quindi perdere l'installazione per l'esecuzione di DVD), ho preparato un file switch personalizzato e ha commutato il modem dalla riga di comando ( sudo usb_modeswitch -I -c 19d2:2003 ).

  3. Non appena il passaggio è stato completato, mi è stato comunicato che lo ero su Mobile Broadband Network e una nuova connessione a banda larga appreard nel menu del gestore di rete.

  4. Ho configurato 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. Interruzione dell'acquisizione del registro MM.

Il registro MM completo e il syslog per l'avvio della sessione all'espulsione del modem possono essere trovati qui .

Test 2

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

I log possono essere trovati qui .

Aggiornamento 10 - Dicembre 09 2015

Questa volta testato con wvdial e trovato che se wvdial viene eseguito come root, otteniamo una connessione di successo .

Il wvdial conf e log e il syslog corrispondente 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 ha   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

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 essere l'utente?
  2. Come eseguiamo il processo di configurazione della connessione a banda larga mobile come root? (problemi di sicurezza?)

Aggiornamento 11 - Dicembre 09 2015

wvdial funziona con USB3 e non funziona con USB1.

Trova il syslog qui .

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

Aggiornamento 12 - 10 dicembre 2015

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

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

  3. Ho provato a connetterti. Senza successo.

Il file syslog è qui .

Aggiornamento 13 - 10 dicembre 2015

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

  1. Avviato il computer con Xubuntu 15.04 64 bit DVD. La connessione ha avuto successo come un incantesimo.
  2. Avviato il computer con Ubuntu 15.10 64 bit DVD. La connessione è fallita 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.rules come indicato nella risposta.

  2. Ha riavviato la mia macchina (o eseguito sudo udevadm control --reload , in realtà ha 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 disconnesso il cavo e ha provato a connettersi tramite il modem. Senza successo.

  5. Espulso il modem.

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

Il file syslog e i file di 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. Lasciato il file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intatto.

  3. Riavviata 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 disconnesso il cavo e ha provato a connettersi. Senza successo.

  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 non riuscito.

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

Aggiornamento 16 - 11 dicembre 2015

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

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

  6. Espulso il modem.

Ma non abbiamo testato il sistema predefinito sopra? Intendevi 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 mancarne uno parte importante) e il file delle regole menzionato (40) sono qui

Aggiornamento 17 - 11 dicembre 2015

  1. Ha commentato la regola 1232 in /lib/udev/rules.d/40-usb_modeswitch.rules , 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 dispositivo 1232 . Non mi viene offerto di provare a connetterti (per quanto ne so, non sarà registrato alla rete a banda larga a meno che non si sia passati al 2003)

    Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
    
  5. Espulso il modem.

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

Aggiornamento 18 - 11 dicembre 2015

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

  2. Guarda lsusb output ogni secondo usando una shell script. Output acquisito nei file con data e ora.

  3. Inserito il modem. (Il modem appare per la prima volta nel file %codice%). Come possiamo trovare dalle acquisizioni, è chiaro che passa da un dispositivo 1232 a uno del 2003.

  4. Ho provato a connetterti. Senza successo.

  5. Espulso il modem.

Il file syslog, gli output con timestamp lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt ei file delle regole menzionati sono qui .

Ora, potresti voler abbinare le uscite syslog con i timestamp.

Aggiornamento 19 - 11 dicembre 2015

Ha eseguito questo test in una direzione completamente nuova con il desiderio che io potrebbe isolare i problemi.

  1. salvato in un media portatile lsusb e /lib/udev/rules.d/40-usb-media-players.rules (dalla macchina Ubuntu 15.10).

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

  3. Eseguito /lib/udev/rules.d/77-mm-zte-port-types.rules . Il primo file è quello salvato dal 15.10.

    L'esame del file diff non mostra diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt 1232 o 2003.

  4. Eseguito idProduct . Di nuovo, il primo file è da uno salvato dal 15.10.

    Ancora una volta, l'esame del file diff non mostra diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt 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. È possibile connettersi facilmente dopo aver configurato 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 idProduct .

  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à 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. sudo udevadm control --reload-rules nella condizione originale.

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

  3. Imposta ModemManager per il debug e imposta l'acquisizione di 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 al modem e atteso finché non dice che è registrato nella rete a banda larga.

  5. Ho provato a connetterti senza successo.

  6. Espulso il modem.

  7. File di registro compressi.

Test 2

Ripetuto il test precedente con /lib/udev/rules al posto.

I nomi dei file di registro sono autoesplicativi.

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

Desidero che tutti i file di registro siano dotati di timestamp, semplificando la corrispondenza.

Aggiornamento 21 - 15 dicembre 2015

  1. Modificato il file di regole come suggerito.
  2. Riavvia la mia macchina.
  3. Inserito il modem e provato a connetterti. Non ha funzionato.

Il file di regole e /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules sono qui .

Aggiornamento 22 - 16 dicembre 2015

Come consigliato in un commento, ho installato vari kernel da link e ho provato a connetterti utilizzando il modem dopo l'avvio in ciascuno.

  1. 4.2.8-040208-generico, errore.

  2. 4.1.15-040115-generic, failure.

  3. 4.0.9-040009-generic, failure.

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.

    
posta Masroor 29.11.2015 - 02:32
fonte

4 risposte

1

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.

    
risposta data Masroor 24.02.2016 - 16:38
fonte
4

Il caricamento del pacchetto ofono ha funzionato, probabilmente, ma a quanto pare il tuo modello di modem, ZTE MF193E, non si trova nell'elenco ZTE. Confrontandolo con altri modem ZTE, ad esempio MF190J, è probabile che questo modem abbia bisogno della stessa speciale regola udev , per eseguire usb_modeswitch quando viene inserito il dongle e per ottenere ciò è possibile, come root, aggiungere un nuovo udev regola al file
/lib/udev/rules.d/40-usb_modeswitch.rules
con le due righe seguenti, ad esempio, vicino al commento # ZTE MF190J :

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

più una riga vuota, quindi è piacevole da guardare.

Probabilmente è saggio riavviare dopo, solo per scoprire che tutto funziona come per magia: -)

Oppure no. Come sapete, questo è per me un deep water, ma se ancora non funziona, sarebbe necessario un altro log di debug di ModemManager, per un'altra ipotesi selvaggia.

EDIT:

Ora guardo le due linee 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 banda larga, mentre il secondo si riferisce al collegamento interno a un "contesto PDP" (qualunque esso sia). A quanto sembra, il modem offre 9 contesti alternativi, tra cui uno con apn='WAP' , ma ModemManager si assesta per 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 configurazione 'wap' (anziché 'WAP' ) e non la trova, o che la fine remota si aspetta apn='WAP' , ma ottiene 'wap' che soffoca.

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

La seconda opzione è anche più di un problema, dato che esiste una corrispondenza "contesto PDP" maiuscola disponibile dal modem. Cercando di risolvere questo problema, sembra che la corrispondenza insensibile alle maiuscole e minuscole sia corretta con la specifica (apparentemente rilevante) "3GPP TS 23.003 capitolo 9.1" e una patch per farlo è stata aggiunta a ModemManager a novembre dell'anno scorso (nella sua versione mm-1 -4, posso raccogliere). Quindi, in questo caso, il tuo modem non è stato informato, e si aspetta una corrispondenza sensibile al maiuscolo / minuscolo, mentre ModemManager sfortunatamente utilizza la distinzione maiuscole / minuscole che corrisponde direttamente anziché come una riserva.

Una soluzione per il secondo problema è ovviamente utilizzare un diverso ModemManager : trovando e installando una versione precedente a questa patch, o (con sufficiente tempo di ricambio), tira il tuo ModemManager . Ma nessuno dei due è qualcosa da fare per un capriccio, quindi forse dovremmo sfogliare un po 'per avere più prove che questo è (ora) il problema, e se possibile trovare altri modi per aggirare il problema. O con un po 'di fortuna, qualcuno che sa qualcosa cade da ...

EDIT 2

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

Due possibili strumenti utili: comando mmcli e ( link ).

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

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

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

EDIT 3

Buona chiamata! 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 venga fuori. Almeno, sarebbe il mio nuovo albero ad abbaiare.

Innanzitutto prendiamo nota del fatto che esiste una differenza di versione per pppd (da 2.4.5 a 2.4.6), ma probabilmente non è un problema, poiché tutti quelli su una chiave sarebbero stati in questa escursione.

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

EDIT 4

Assicurati che /etc/ppp/pap-secrets e /etc/ppp/chap-secrets abbiano gruppo dip (usando chgrp come necessario) e modo 740 (o -rw-r----- ) (usando chmod come necessario). Il mio no.

EDIT 5

Come su questo albero, quindi: confrontando il% s_s_log% syslog funzionante con syslog non funzionante, sembra che per qualche motivo wvdial usato wvdial mentre% non funzionante co_de% continua a usare ttyUSB3 . Non sono sicuro che sia del tutto significativo, ma a quanto pare, ma ModemManager e ttyUSB1 rispondono entrambi come modem con funzionalità AT.

Quindi, come test, forse puoi modificare ttyUSB1 in modo che in ttyUSB3 includa la riga:

Modem = /dev/ttyUSB1

per l'un test e /etc/wvdial.conf per un altro; entrambi in esecuzione come root; solo per vedere se c'è un comportamento diverso. Soprattutto, se si usa [Dialer Defaults] è un problema considerando che l'uso di ttyUSB3 non lo è, allora sarebbe bene cercare in che modo ModemManager usi anche ttyUSB3. Per qualsiasi altro risultato del test, direi che torneremo a inseguire i furetti in ppp land.

EDIT 6

Il log di 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 ttyUSB3 può essere usato per usare ttyUSB3 e ignorare ttyUSB1 (per questo modem).

Ho anche trovato ( link ) con in particolare il post 10 sconcertante :-(

La regola ttyUSB1 apparentemente applicabile in NetworkManager non si applica, ma presumibilmente è dove andare. E, con solo una conoscenza rudimentale, pre-101 della magia udev , vorrei comunque prendere in considerazione la sua quarta linea, che dice:

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

Penso che quella linea abbia bisogno di un /lib/udev/rules.d/77-mm-zte-port-types.rules iniziale, in modo da essere commentata. In dettaglio, la mia lettura del file è che richiede uno stato di chiamata di SUBSYSTEM == "tty" e SUBSYSTEMS="usb" per utilizzare i bit validi, incluse le regole del prodotto "2003" e almeno per i test, dovrebbe essere sicuro saltare il filtro "tty". E non ho niente di meglio adesso.

EDIT 7

Dopo aver trascorso un po 'di tempo con il mio motore di ricerca preferito, credo che un po' di più che la scelta del ttyUSB sia un problema di root qui. La regola di 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 log, 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 testare questo replicando le due regole "2003" per l'ID prodotto "1232", nel file udev

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 es. chiamato # , ma devi anche aggiungere la protezione SUBSYSTEM e SUBSYSTEMS attorno ad esso.

Quindi, estrai il dongle, esegui /lib/udev/rules.d/77-mm-zte-port-types.rules (o riavvia) e inserisci il dongle. E poi un'altra cattura 78-ralph.rules , a meno che ora non funzioni.

Il problema effettivo, tuttavia, è che ModemManager scarta il plug-in udevadm control --reload al pre-probing e finisce usando un gestore di modem generico. Se ho ragione riguardo l'id prodotto, questa potrebbe essere la ragione; che il pre-rilevamento cerca un'attribuzione di syslog , e questo manca per l'ID prodotto "1232" (prima della patch), con l'effetto che il plug-in di zte viene scartato.

EDIT 8

Il libmm-plugin-zte.so log è un po 'breve; manca l'inizio in cui ModemManager non riesce a installare il plugin zte. Tuttavia, è chiaro che il plugin del modem generico viene comunque utilizzato. Ora, potrebbe essere che anche la regola ID_MM_ZTE_PORT_TYPE_MODEM che ti ho dato all'inizio sia sbagliata; decide di passare da a "2003" quando pensavo che fosse cambiato da "2003". Ma, syslog (che avrei dovuto guardare prima) suggerisce di spostare a un id prodotto anziché da esso. In ogni caso, il registro mostra che deve accadere. Pertanto, per favore cambia quella regola per usare "1232", e riprova ancora.

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 in fase di pre-analisi. I log di debug di ModemManager per 15.10 (log set "debuglogs *") dicono tutti che il plug-in ZTE è scartato a causa del test id produttore / id prodotto.

Vai alla fonte, Luke! Ho colto l'occasione per avvistare 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-rilevamento mentre il dispositivo è 19d2 / 1232. Questo pensiero è allineato all'osservazione che avere le regole udev di 78-mm-zte-port-types-RALPH.rules rende ModemManager un po 'più felice con il dispositivo. Ma allora, perché non rimane felice e fa uso di quel plugin quando il dispositivo passa a 19d2 / 2003?

Forse sono necessari più registri :-) Con ModemManager debug, e anche una cattura del comando usb_modeswitch (in un altro terminale) quando si collega il dispositivo. Ho ricevuto questo comando da ( link )

Fai questo due volte: una volta senza man usb_modeswitch e una volta con le regole ... entrambe le volte da un nuovo riavvio. Cioè.

  1. imposta udevadm monitor --e |& tee udevadm.log con o senza il file 78-mm-zte-port-types-RALPH.rules
  2. estrai il dispositivo
  3. riavvio
  4. imposta ModemManager per il debug e imposta udevadm capture
  5. collega il dispositivo e attendi un minuto
  6. impacchetta i file di registro
  7. ripeti da 1 con il prossimo test

Quella registrazione dovrebbe indicare dove il plugin ZTE è stato eliminato e, a quanto ho capito, parlerà anche della gestione degli eventi di udev.

EDIT 10

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

In primo luogo, tutte le decorazioni /lib/udev/rules.d sembrano finire come dovrebbero, con solo un paio di punti interrogativi in ​​un paio di attributi. In particolare, il *-RALPH.rules dovrebbe essere gettato via; non è utile.

Penso di poter leggere qualcosa da questo, ma non sono esattamente sicuro di come dovrebbe essere risolto. Fondamentalmente, a quanto vedo, 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 determina il caricamento del driver udev e la visualizzazione di 78-*-RALPH.rules . Ciò in particolare causa 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 usb_serial . Devi andare a /dev/ttyUSB1 per vedere la prova di questo, poiché non esiste una stretta correlazione tra i registri. L'evento è con indicazione dell'ora ModemManager e syslog presenta la successiva riga di conteggio 3867.435102 immediatamente successiva alla riga di log del kernel stampata su syslog .

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 log MM ci troveremmo alla riga stampata 3867.437412 , che apparentemente è un timestamp "in tempo reale" piuttosto che un "timbro del tempo del kernel".

ModemManager quindi viene eseguito con il suo pre-rilevamento a 1449934745.363291 , cioè 87 ms dopo, che nei termini del kernel del kernel sarebbe vicino a ModemManager e 55ms prima di quel "buon" rapporto sugli eventi UDEV sopra.

Da notare che in 1449934745.450398 , 3867.524519 si lamentano che syslog non ha i suoi attributi impostati e forse quel reclamo è correlato al "marchio" che si verifica in ModemManager . Con il commento in quel file, quella marcatura sembra essere un tentativo di risolvere esattamente questo problema, ma se così fosse, non sembra funzionare in questo caso.

Forse una possibilità per risolvere questo sarebbe cambiare la regola "tty" in ttyUSB1 per essere:

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

Nella mia mente, ciò assicurerebbe che l'impostazione 80-mm-candidate.rules venga ritardata fino a quando non vengono impostati gli attributi ZTE. L'impostazione 80-mm-candidate.rules è un effetto di una regola ID_MM_CANDIDATE (chiamata prima .ID_PORT ) e la condizione aggiunta alla regola di contrassegno è 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 richiedere 60-serial.rules , poiché quell'assegnazione qui avviene per 60-persistent-serial.rules .

In generale non sono molto sicuro dell'ordinamento della regola ENV{.MM_USBIFNUM}="?*" , e non sono affatto sicuro che ciò impedisca veramente a 77-mm-zte-port-types.rules di agire troppo rapidamente. Tuttavia, se non lo fa, udev avrebbe poca o nessuna funzione, e forse poi tutto si ridurrebbe ai "miglioramenti" a ModemManager dal 15.04.

EDIT 21

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

C'è ancora quasi un secondo tra ModemManager e 7-zte-mutil_port_device.rules dove 515.558184 afferra con impazienza e erroneamente 516.381549 , e mentre si lamenta che non è stato impostato, continua comunque il pre-test e scarta il plugin ZTE. In altre parole, la patch della regola non rende ModemManager wait.

Suppongo che tu abbia provato anche con /dev/ttyUSB1 invece di ModemManager .

In realtà, per confermare se l'impostazione di ENV{.MM_USBIFNUM}="?*" è di importanza, devi spostare temporaneamente ENV{.ID_PORT}=="?*" , quindi vedere (in ENV{ID_MM_CANDIDATE}=1 ) se poi 80-mm-candidate.rules ignora syslog o no. Sospetto "non".

E poi, beh, forse puoi usare una versione funzionante, come 14.04, e se hai bisogno, forse esegui 15.10 in una virtualbox, a meno che, naturalmente, non sia già tutto in una virtualbox.

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

    
risposta data Ralph Rönnquist 07.12.2015 - 11:27
fonte
0

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

Se tutto va bene, se sto leggendo le tue specifiche tecniche dovrei indirizzarti verso questa direzione (MF190J):

Il modem 3G (ZTE MF190J) richiede ancora un ritocco manuale.

    
risposta data John75077 12.12.2015 - 03:39
fonte
-2

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 in questo modo.

    
risposta data Michael 15.12.2015 - 17:12
fonte