Erro 'ip-config -available' quando o modem USB tenta se conectar

Eu tenho um modem ZTE MF-193E que funcionava bem antes. Quando comprei este modem há mais de um ano, ele funcionou prontamente. Agora, à medida que o Ubuntu avança na versão, as coisas estão se tornando cada vez mais difíceis para mim.

Este modem até trabalhou alguns meses atrás com o Ubuntu 15.04 (64 bits). Agora, no Ubuntu 15.10 (64 bits), ele não pode se conectar.

Eu configurei uma conexão de banda larga móvel . Eu tentei várias strings para o APN, mas isso não foi um problema antes.

(O modem funciona bem no Windows 10, portanto, isso não é um problema de hardware. Além disso, a GUI do Modem Manager detecta muito bem esse dispositivo. Os SMSs podem ser enviados e recebidos sem nenhum problema.)

Quando insiro o modem, ele é detectado corretamente, um ícone de CD é exibido no Unity com o nome do modem. Alguns segundos depois, recebo uma caixa de mensagem

Mobile Broadband Network: you are registered on the home network

perto do ícone de rede.

Quando tento conectar, o ícone sem fio no miniaplicativo gerenciador de rede inicia esses movimentos centrífugos, mas eventualmente ele falha na conexão e uma mensagem informa que estou offline.

A linha da qual eu poderia me isolar /var/log/syslogé esta,

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

No entanto, não tenho certeza se esse é o relevante.

Mais linhas /var/log/syslogpodem ser encontradas aqui .

Atualização 1 - 06 de dezembro de 2015

Conforme indicado por um membro gentil, tentei a nf_conntrack_pptpabordagem do módulo.

Executou os seguintes comandos,

$ lsmod | grep nf_conntrack_pptp | wc -l
0

$ sudo modprobe nf_conntrack_pptp
lsmod | grep nf_conntrack_pptp
nf_conntrack_pptp      20480  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          106496  2 nf_conntrack_proto_gre,nf_conntrack_pptp

Então tentei meu modem, a mesma falha. Nenhuma alteração discernível no log também.

Atualização 2 - 06 de dezembro de 2015

Executado como root,

systemctl restart network-manager.service

Nenhuma saída na tela (terminal).

O registro correspondente do ponto acima para uma tentativa de conexão usando o modem pode ser encontrado aqui .

Atualização 3 - 06 de dezembro de 2015

Instalado ofonoe tentei o modem novamente.

Por favor, veja o log aqui .

Atualização 4 - 06 de dezembro de 2015

Novamente executado como root,

systemctl restart network-manager.service

O registro correspondente do ponto acima para uma tentativa de conexão usando o modem pode ser encontrado aqui .

Atualização 5 - 06 de dezembro de 2015

Todos "negado" foram alterados para "permitir" /etc/dbus-1/system.d/nm-dispatcher.conf.

Tentei conectar. Sem sorte

Algumas redes se conectam e desconectam com a conexão Ethernet.

Seguido por sudo systemctl restart network-manager.service.

O modem é conectado e conectado.

Tentei conectar novamente. Não se conecta.

O log está aqui .

Atualização 6 - 06 de dezembro de 2015

Executado

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

Não foi possível executar mm-test.pydevido a vários erros. Encontrou o arquivo no local indicado. Obtenha isso em https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

Os comandos acima são um pouco diferentes daqueles no Wiki.

Os arquivos de log estão aqui .

Atualização 7 - 07 de dezembro de 2015

Executado novamente (após a alteração sugerida /lib/udev/rules.d/40-usb_modeswitch.rulese a reinicialização)

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

O também /var/log/syslogestá incluído.

Os arquivos de log estão aqui .

Atualização 8 - 08 de dezembro de 2015

O conjunto atualizado de logs está aqui .

Atualização 9 - 08 de dezembro de 2015

Teste 1

1. Desta vez, o computador foi inicializado a partir de um DVD do Ubuntu 14.04 de 32 bits. Assim que o computador inicializou, começou a capturar o log do MM.

2. Inserido o modem. lsusbmostrou que estava sendo reconhecido como um dispositivo 19d2: 1232 que precisa ser alterado para um dispositivo 19d2: 2003. Como a instalação do usb-modeswitch requer reinicialização da máquina (e, portanto, perde a instalação para a execução do DVD), preparei um arquivo de opção personalizado e troquei o modem pela linha de comando ( sudo usb_modeswitch -I -c 19d2:2003).

3. Assim que a troca foi concluída, fui informado de que estava ligado Mobile Broadband Networke de uma nova conexão de banda larga no menu do gerenciador de rede.

4. Configurei a conexão acima da maneira usual (o nome do APN não foi um problema) e a conexão foi estabelecida automaticamente.

5. Desconectei e ejetei o modem.

6. Parou de capturar o log MM.

O log MM e o syslog completos da sessão inicial para a ejeção do modem podem ser encontrados aqui .

Teste 2

O mesmo teste com um DVD do Ubuntu 14.04 de 64 bits.

Os logs podem ser encontrados aqui .

Atualização 10 - 09 de dezembro de 2015

Desta vez, testamos wvdiale descobrimos que, se wvdialfor executado como root, obtemos uma conexão bem - sucedida .

O wvdialconf e log e o syslog correspondente estão aqui

Conjectura primária: a situação pode ter algo a ver com o grupo de usuários do usuário correspondente.

Mas como indicado aqui ,

Com todas essas ferramentas, para estabelecer uma conexão dial-up, o usuário deve ser membro dos grupos "dip" e "dialout"; portanto, coloque todos os usuários que deveriam se conectar via dial-up a esses grupos.

Mas como podemos encontrar,

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

Portanto, o usuário já é um membro dos grupos indicados.

Agora, talvez o problema se refira a um desses pontos,

1. Qual grupo adicional o usuário precisa ser?
2. Como executamos o processo de configuração da conexão de banda larga móvel como root? (problemas de segurança?)

Atualização 11 - 09 de dezembro de 2015

wvdialfunciona com USB3 e não funciona com USB1.

Por favor, encontre o syslog aqui .

Também está incluída a saída de dmesg | grep tty > /tmp/dmesg.tty.txt. Mas vê essas quatro linhas perto do início do arquivo?

Atualização 12 - 10 de dezembro de 2015

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

2. Reiniciei minha máquina. Soft desconectou o cabo e inseriu o modem.

3. Tentei conectar. Mal sucedido.

O arquivo syslog está aqui .

Atualização 13 - 10 de dezembro de 2015

Por puro desespero, para ver se algumas mudanças locais estão afetando a conexão, testou a máquina com os DVDs do Ubuntu 15.04 e 15.10.

1. Inicializou a máquina com o Xubuntu 15.04 de 64 bits. A conexão foi bem-sucedida como um encanto.
2. Inicializou a máquina com o Ubuntu 15.10 de 64 bits. A conexão falhou como antes.

O que aconteceu entre 15.04 e 15.10?

Tão frustrante.

Atualização 14 - 10 de dezembro de 2015

1. Criou um novo arquivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesconforme as instruções na resposta.

2. Reiniciei minha máquina (ou executada sudo udevadm control --reload, tentei as duas). Inserido o modem.

3. O modem foi reconhecido.

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

4. Soft desconectou o cabo e tentou se conectar usando o modem. Mal sucedido.

5. Ejetado o modem.

A máquina trava uma vez, isso é um evento aleatório? Minha máquina geralmente não trava uma vez no ano.

O arquivo syslog e os arquivos de regra criados estão aqui .

Atualização 15 - 11 de dezembro de 2015

1. Adicionadas as seguintes linhas em /lib/udev/rules.d/40-usb_modeswitch.rules.

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

2. Deixou o arquivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesintacto.

3. Reiniciei minha máquina. Inserido o modem.

4. O modem foi reconhecido.

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

5. Soft desconectou o cabo e tentou se conectar. Mal sucedido.

6. Ejetado o modem.

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

8. Reiniciei e tentei todo o processo novamente. Sem sucesso novamente.

O arquivo syslog (completo, não corri o risco de perder nenhuma parte importante) e o arquivo de regra mencionado (40) está aqui .

Atualização 16 - 11 de dezembro de 2015

1. Deixou apenas uma regra 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, removeu a outra.

2. Executado sudo udevadm control --reload.

3. Inserido o modem.

4. O modem foi reconhecido.

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

5. Soft desconectou o cabo e tentou se conectar. Mal sucedido.

6. Ejetado o modem.

Mas não testamos o sistema padrão acima? Você queria sair /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesem seu lugar?

O arquivo syslog (completo, não corri o risco de perder nenhuma parte importante) e o arquivo de regra mencionado (40) está aqui

Atualização 17 - 11 de dezembro de 2015

1. Comentou a regra 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, acrescentou uma para 2003.

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

2. Executado sudo udevadm control --reload.

3. Inserido o modem.

4. O modem foi reconhecido como um dispositivo 1232 . Não me ofereceram a tentativa de conexão (até onde sei, ele não será registrado na rede de banda larga, a menos que a troca tenha ocorrido em 2003)

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

5. Ejetado o modem.

O arquivo syslog e o arquivo de regra mencionado (40) são aqui

Atualização 18 - 11 de dezembro de 2015

1. Coloque todos os arquivos de regras em sua forma original.

2. Assistiu lsusbSaída a cada segundo usando um script de shell. Saída capturada em arquivos com registro de data e hora.

3. Inserido o modem. (O modem aparece pela primeira vez no arquivo lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Como podemos encontrar nas capturas, é claro que ele muda de um dispositivo 1232 para um de 2003.

4. Tentei conectar. Mal sucedido.

5. Ejetado o modem.

O arquivo syslog, as lsusbsaídas com registro de data e hora e os arquivos de regras mencionados estão aqui .

Agora, você pode querer combinar as saídas do syslog com os carimbos de hora.

Atualização 19 - 11 de dezembro de 2015

Realizei esse teste em uma direção totalmente nova, com o desejo de poder isolar os problemas.

1. Salvo em uma mídia portátil /lib/udev/rules.d/40-usb-media-players.rulese /lib/udev/rules.d/77-mm-zte-port-types.rules(da máquina Ubuntu 15.10).

2. Inicialize a máquina usando o DVD de 64 bits do Xubuntu 15.04.

3. Executado diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt . O primeiro arquivo é daquele salvo em 15.10.

   O exame do arquivo diff não mostra idProduct1232 ou 2003.

4. Executado diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Novamente, o primeiro arquivo é daquele salvo em 15.10.

   Novamente, o exame do arquivo diff não mostra idProduct1232 ou 2003.

5. Inserido o modem. O modem foi reconhecido como um modem.

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

6. Pode conectar-se rapidamente após configurar uma conexão de banda larga móvel

7. Ejetado o modem.

8. Instalou o USB_ModeSwitch mais recente.

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

   Agora retorna NULL, conforme o esperado.

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

10. Inserido o modem. O modem foi reconhecido como um modem.

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

11. Pode conectar-se facilmente.

Eu poderia ter tentado atualizar MM e NM para o Ubuntu 15.10, apenas para ver onde ele quebra. Na verdade, tentei, mas desisti devido a problemas de dependência sem fim.

Todos os arquivos diff mencionados acima estão aqui .

Atualização 20 - 12 de dezembro de 2015

Teste 1

1. O /lib/udev/rulesem condição original.

2. O dispositivo modem ainda não foi inserido nesta sessão.

3. Configure o ModemManager para depuração e instalação da captura do udevadm.

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

4. Conecte o modem e espere até que ele diga que está registrado na rede de banda larga.

5. Tentou se conectar sem sucesso.

6. Ejetado o modem.

7. Arquivos de log compactados.

Teste 2

Repita o teste acima com /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules no lugar.

Os nomes dos arquivos de log são auto-explicativos.

Todos os arquivos de log acima, mais o syslog e os 78 arquivos de regras estão aqui .

Desejo que todos os arquivos de log tenham registro de data e hora, facilitando a correspondência.

Atualização 21 - 15 de dezembro de 2015

1. O arquivo de regras foi alterado conforme sugerido.
2. Reiniciei minha máquina.
3. Inseriu o modem e tentou conectar-se. Não funcionou.

O arquivo de regras e o syslogestão aqui .

Atualização 22 - 16 de dezembro de 2015

Conforme recomendado em um comentário, instalei vários kernels em http://kernel.ubuntu.com/~kernel-ppa/mainline/ e tentei conectar-se usando o modem após a inicialização em cada um.

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

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

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

Então, talvez, possamos descartar a questão do kernel.

Atualização 23 - 16 de fevereiro de 2016

O modem começou a funcionar no Ubuntu 16.04. Esta versão ainda está no Alpha 1, mas funciona bem no meu laptop.

O carregamento do ofonopacote foi bom, provavelmente, mas aparentemente o modelo do seu modem, ZTE MF193E, não está na lista da ZTE. Comparando-o com outros modems ZTE, por exemplo, MF190J, é provável que este modem precise da mesma udevregra especial , para executar usb_modeswitchquando o dongle for inserido e para conseguir que você possa, como root, adicionar uma nova udevregra ao arquivo
/lib/udev/rules.d/40-usb_modeswitch.rules
com os dois seguintes linhas, por exemplo, em algum lugar perto do # ZTE MF190Jcomentário:

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

além de uma linha em branco, para que pareça agradável aos olhos.

Provavelmente é aconselhável reiniciar depois disso, apenas para descobrir que tudo funciona como mágica :-)

Ou não. Como você sabe, essa é uma água profunda para mim, mas se ainda não funcionar, será necessário outro log de depuração do ModemManager, para outro palpite.

EDITAR:

Agora estou olhando as duas linhas no 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'

Acho que o primeiro se refere à sua banda larga configurada, enquanto o último se refere à ligação interna a um "contexto PDP" (seja lá o que for). Pelo que parece, o modem oferece 9 contextos alternativos, incluindo um com apn='WAP', mas ModemManagerse conforma a uma correspondência que não diferencia maiúsculas de minúsculas.

A diferença entre maiúsculas e minúsculas pode ser a causa do problema subsequente: por exemplo, que o ppp deseja uma 'wap'configuração (e não 'WAP') e não a encontra, ou que a extremidade remota espera apn='WAP', mas recebe 'wap' com o qual se engasga.

A primeira opção pode ser facilmente testada (e descartada, provavelmente) alterando sua configuração para usar 'wap' em vez de 'WAP'. Você pode ter tentado isso antes, mas naquele momento sem o ofonopacote, então outro teste não será prejudicial, embora a segunda opção seja mais provável.

A segunda opção também é um problema, já que existe uma correspondência maiúscula de "contexto PDP" disponível no modem. Pesquisando esse problema no Google, parece que a correspondência sem distinção entre maiúsculas e minúsculas está correta pela especificação (aparentemente relevante) "3GPP TS 23.003 capítulo 9.1", e um patch para fazer isso foi adicionado ModemManagerem novembro do ano passado (em sua versão mm-1-4, Eu posso reunir). Portanto, neste caso, seu modem não foi informado e espera uma correspondência sensível a maiúsculas e minúsculas, enquanto, ModemManagerinfelizmente, usa a correspondência sem distinção entre maiúsculas e minúsculas, e não como um substituto.

Uma solução para o segundo problema é, obviamente, usar uma diferente ModemManager: localizando e instalando uma versão anterior a esse patch ou (com tempo livre suficiente), crie sua própria ModemManager. Mas também não há algo a fazer por capricho, portanto, talvez tenhamos que procurar um pouco mais para obter mais evidências de que esse é (agora) o problema e, se possível, encontrar outras maneiras de contorná-lo. Ou com um pouco de sorte, alguém que sabe alguma coisa aparece ...

EDIT 2

Sim, a reversão de versão não é fácil devido a dependências. E rolar a sua própria está longe de ser uma alegria também.

Duas ferramentas úteis possíveis: command mmclie ( http://m2msupport.net/m2msupport/module-tester/ ).

O problema, penso eu, é que o ModemManager escolhe o contexto 1 do PDP com apn = 'wap', onde deve escolher o contexto 9 do PDP com apn = 'WAP'. Talvez isso possa ser solucionado usando uma dessas ferramentas. Para poder forçar uma seleção de 9 durante a conexão ou excluir os contextos 'wap' ruins do modem, do qual a ferramenta testadora de módulo é anunciada como capaz.

A ferramenta modem-tester parece ser uma ferramenta java no navegador, portanto, você precisa que seu navegador esteja configurado para saber onde está o java, e que ele seja conhecido. Então, por favor, explore essa abordagem; Eu não o usei, mas vendo as capturas de tela, acho que ele apresentará os contextos do PDP como a guia 'Chamadas de dados', onde você primeiro toma nota de tudo o que mostra e depois edita as entradas 'wap' para distorça os rótulos apap 'wap' para que sejam, digamos, 'wap1' e 'wap2' (para "ocultá-los" ao procurar 'WAP'). Em seguida, salve e feche e faça malabarismos com o dongle novamente. Pegue um log; parece que o syslog é suficiente agora, caso ainda se recuse a jogar.

O mmclicomando também parece útil nesta história; fazer man mmclipara ler sobre isso, mas eu não vi nada sobre os contextos PDP lá.

EDIT 3

Boa decisão! para testar a partir do DVD. Isso nos disse que estou no caminho errado com o APN, e que tudo depende de fazer o ppp aparecer. Pelo menos, essa seria minha nova árvore para latir.

Primeiramente, observamos que há uma diferença de versão para o pppd (de 2.4.5 a 2.4.6), mas isso provavelmente não é um problema, já que todos em um dongle estariam nessa excursão.

Hum, ppp; Eu preciso despertar minhas memórias do último milênio :-). Infelizmente hoje estou ocupada, mas tocarei na base quando tiver tempo, para ver até onde você chegou. Meus primeiros becos a serem analisados ​​seriam: 1) o usuário está no grupo certo? 2) as credenciais estão corretas? 3) os mods do arquivo de configurações ppp / chat estão certos? O log de depuração do ppp sai em nm.txt (como há alguns dias atrás), mas também deve haver uma maneira de solicitar um log mais detalhado.

EDIT 4

Garanta /etc/ppp/pap-secretse /etc/ppp/chap-secretstenha grupo dip(usando chgrpconforme necessário) e modo 740(ou -rw-r-----) (usando chmodconforme necessário). O meu não.

EDIT 5

Que tal esta árvore: Comparando o wvdialsyslog ativo com o syslog não funcional, parece que, por algum motivo, é wvdialusado ttyUSB3enquanto o não ativo ModemManagercontinua usando ttyUSB1. Não tenho certeza se é significativo, mas aparentemente, masttyUSB1 e ttyUSB3ambos respondem como modems capazes AT.

Portanto, como teste, talvez você possa editar /etc/wvdial.confpara [Dialer Defaults]incluir abaixo a linha:

Modem = /dev/ttyUSB1

para um teste e ttyUSB3para outro; ambos rodando como root; apenas para ver se existe um comportamento diferente. Especialmente, se estiver usandottyUSB1 é um problema, enquanto o uso do ttyUSB3 não é, seria bom analisar como fazer o ModemManager usar o ttyUSB3 também. Para qualquer outro resultado de teste, eu diria que voltaremos a perseguir furões em terras ppp.

EDIT 6

O log dmesg pode ser ignorado, eu acho; tem sido assim em todos os logs. O novo syslog mostra apenas o teste ttyUSB3, mas talvez possamos assumir que a vida fica melhor seNetworkManager possível usar o ttyUSB3 e ignorar o ttyUSB1 (para este modem).

Eu também encontrei ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) com especialmente o post # 10 desconcertante :-(

A udevregra aparentemente aplicável /lib/udev/rules.d/77-mm-zte-port-types.rulesnão se aplica, mas supostamente seria para onde ir. E, com apenas uma percepção muito rudimentar, pré-101, sobre a udevmágica, eu consideraria questionar sua quarta linha, que diz:

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

Eu acho que essa linha precisa de uma inicial # para ser comentada. Em detalhes, minha leitura do arquivo é que ele requer um estado de chamada SUBSYSTEM == "tty" e SUBSYSTEMS = "usb" para usar os bits bons, incluindo as regras do produto "2003" e, pelo menos, para testar, deve ser seguro ignorar a filtragem "tty". E não tenho nada melhor agora.

EDIT 7

Depois de ter passado algum tempo de qualidade com meu mecanismo de pesquisa favorito, acredito um pouco mais que a opção ttyUSB é um problema raiz aqui. A regra do udev que eu apontei está ok, e você deve reverter essa edição.

No entanto, comecei a acreditar que as regras de configuração no final desse arquivo, para o ID do produto "2003", são enganosas. Pelos registros, parece-me que o ID do produto "2003" é realmente o lado do dispositivo de memória do dongle, enquanto o lado do modem tem o ID do produto "1232". Você pode testar isso replicando as duas regras "2003" para o ID do produto "1232", no arquivo/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"

ou melhor, adicione um novo arquivo ao lado, por exemplo, nomeado 78-ralph.rules, mas você também precisará adicionar a proteção SUBSYSTEM e SUBSYSTEMS ao seu redor.

Em seguida, retire o dongle, execute udevadm control --reload(ou reinicie) e insira o dongle. E mais uma syslogcaptura, a menos que agora funcione.

O problema efetivo, porém, é que o ModemManager descarta o plug libmm-plugin-zte.so- in na pré- análise e acaba usando um manipulador de modem genérico. Se eu estiver certo sobre o ID do produto, talvez este seja o motivo; essa pré-análise procura uma ID_MM_ZTE_PORT_TYPE_MODEMatribuição e falta o ID do produto "1232" (antes do patch), com o efeito de que o plugin zte é descartado.

EDIT 8

O sysloglog é um pouco curto; faltando o início em que o ModemManager falha ao instalar o plugin zte. No entanto, é claro que o plug-in de modem genérico é usado de qualquer maneira. Agora, pode ser que a usb_modeswitchregra que eu lhe dei desde o início também esteja errada; decide mudar para "2003" quando pensei que havia mudado de "2003". Mas, man usb_modeswitch(o que eu deveria ter examinado antes) meio que sugere que ele mude para um ID de produto e não para ele. De qualquer forma, o log mostra que isso acontece. Portanto, altere essa regra para usar "1232" e tente novamente.

Se nada mais, pelo menos eu tenho que aprender um pouco sobre o udev.

EDIT 9

Boa. O problema ainda é (ou também) que o ModemManager descarta o plug-in ZTE na pré-análise. Os logs de depuração do ModemManager para 15.10 (conjuntos de logs "debuglogs *") contam a história de que o plug-in ZTE foi descartado devido ao teste de identificação do fornecedor / identificação do produto.

Vá para a fonte, Luke! Aproveitei esta oportunidade para visualizar brevemente o código-fonte do ModemManager, e indica que o plug-in como uma tabela de vid / pid que não inclui 19d2 / 2003 ... porém, eu não encontrei a fonte da tabela, então não consegui verifique.

Ou talvez haja um problema de tempo aqui. Por exemplo, que o ModemManager execute a pré-análise enquanto o dispositivo estiver 19d2 / 1232. Esse pensamento está alinhado com a observação de que as regras do udev de 78 mm zte-port-types-RALPH.rules tornam o ModemManager um pouco mais feliz com o dispositivo. Mas então, por que ele não fica feliz e faz uso desse plug-in quando o dispositivo é alterado para 19d2 / 2003?

Talvez mais registros sejam necessários :-) Com o ModemManager depurado, e também uma captura do comando udevadm monitor --e |& tee udevadm.log(em outro terminal) quando você conecta o dispositivo. Eu recebi esse comando em ( https://wiki.ubuntu.com/DebuggingUdev )

Faça isso duas vezes: uma vez sem 78-mm-zte-port-types-RALPH.rulese uma vez com as regras ... ambas as vezes a partir de uma nova reinicialização. Ou seja,

1. configuração /lib/udev/rules.dcom ou sem o *-RALPH.rulesarquivo
2. retire o dispositivo
3. reiniciar
4. configure o ModemManager para depuração e configure a captura do udevadm
5. conecte o dispositivo e aguarde um minuto
6. empacotar arquivos de log
7. repita de 1 com o próximo teste

Esse registro deve informar onde o plug-in ZTE foi descartado e, pelo que entendi, também informará sobre o tratamento de eventos do udev.

EDIT 10

(Estou quase no fim da minha corda aqui, mas tenho mais uma ou duas respirações :-)

Primeiro, todas as udevdecorações parecem terminar como deveriam, com apenas alguns pontos de interrogação em alguns dos atributos. Em particular, o 78-*-RALPH.rulesdeve ser jogado fora; não é útil.

Acho que posso ler algo disso, mas não sei exatamente como deve ser corrigido. Basicamente, a meu ver, quando o dongle está conectado, há uma enxurrada de eventos do udev. Focando aqueles relacionados ao ttyUSB1, existe um evento "inicial":

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

o que faz com que o usb_serialdriver seja carregado e /dev/ttyUSB1apareça. Isso em particular causa outro evento:

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

Eu acho que isso também desencadeia ModemManager. Você precisa syslogver evidências disso, pois não há uma correlação estrita entre os logs. O evento é marcado com hora 3867.435102e syslogapresenta sua ModemManagerlinha de log subsequente mais próxima logo após uma linha de log do kernel carimbada 3867.437412.

Na minha linha de pensamento, ModemManagernão deve ser acionado ainda, mas somente após o evento ttyUSB1 subsequente:

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

que anexou os atributos ZTE.

No log do MM, estaríamos na linha carimbada 1449934745.363291 , o que aparentemente é um hora "em tempo real", em vez de um hora "do kernel".

ModemManagerentão é feito com a pré- 1449934745.450398análise em , ou seja, 87ms depois, o que em termos de tempo do kernel estaria próximo3867.524519 e 55ms antes do "bom" relatório de evento UDEV acima.

Observe que syslog, em , ModemManagerapresenta reclamações que ttyUSB1não têm seus atributos definidos e talvez essa reclamação esteja relacionada à "marcação" ocorrida em 80-mm-candidate.rules. Pelo comentário nesse arquivo, essa marcação parece ser uma tentativa de lidar exatamente com esse problema, mas, nesse caso, parece não funcionar nesse caso.

Talvez uma possibilidade para resolver isso seja alterar a regra "tty" 80-mm-candidate.rulespara:

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

Na minha opinião, isso garantiria que a ID_MM_CANDIDATEconfiguração seja adiada até que os atributos ZTE sejam definidos. A .ID_PORTconfiguração é um efeito de uma 60-serial.rulesregra (chamada 60-persistent-serial.rulesantes) e a condição adicionada à regra de marcação é simplesmente que ela possui um valor.

A condição não é exatamente um atributo ZTE, apenas para manter a regra mais genérica. Um passo mais específico seria exigir ENV{.MM_USBIFNUM}="?*", em vez disso, uma vez que essa atribuição acontece aqui 77-mm-zte-port-types.rules.

Em geral, não tenho muita certeza sobre a udevordenação de regras e também não tenho certeza de que isso realmente pare ModemManagerde agir rápido demais. No entanto, se isso não acontecer, 80-mm-candidate.rulesteria pouca ou nenhuma função e talvez tudo se resumisse às "melhorias" ModemManagerdo 15.04.

EDIT 21

suspiro. Provavelmente irrelevante, mas você pode querer verificar seu7-zte-mutil_port_device.rules arquivo; isso é um remanescente de outra experimentação? De qualquer forma, não é relevante aqui.

Ainda há quase um segundo entre 515.558184e 516.381549onde ModemManageravidamente e erroneamente o agarra /dev/ttyUSB1e, apesar de reclamar por não ter sido configurado, ainda passa por pré-sondagem e descarta o plug-in ZTE. Em outras palavras, o patch da regra não faz ModemManageresperar.

Suponho que você também testou usando em ENV{.MM_USBIFNUM}="?*"vez de ENV{.ID_PORT}=="?*".

Na verdade, para confirmar se a configuração ENV{ID_MM_CANDIDATE}=1é ou não importante, você deve se afastar temporariamente 80-mm-candidate.rulese ver (em syslog) se então ModemManagerignora /dev/ttyUSB1ou não. Eu suspeito que "não".

E então, bem, talvez você possa usar uma versão funcional, como a 14.04, e se precisar, talvez execute a 15.10 em uma caixa virtual, a menos que, é claro, tudo já esteja em uma caixa virtual.

Acho que preciso reivindicar a derrota neste momento.

O modem começou a funcionar no Ubuntu 16.04. Esta versão ainda está em fase de desenvolvimento, mas funciona bem no meu laptop.

Eu gostaria de poder fornecer mais detalhes técnicos sobre como ele começou a funcionar.

Depois de dar uma olhada nisso, parece que não é a primeira vez que esse dragão é tratado adequadamente. Era um bug anterior em 12.10 e 13.04, talvez o bug nunca fosse corrigido ou um novo patch quebrasse algo que estava funcionando corretamente antes.

Felizmente, se estou lendo suas especificações técnicas corretamente, preciso apontá-lo para essa direção (MF190J):

O modem 3G (ZTE MF190J) ainda requer ajustes manuais.

Você já tentou isso:

 rfkill list up

e então crie este script e execute-o:

 #/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 pode funcionar bem dessa maneira.