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.
Gostaria de poder fornecer mais detalhes técnicos sobre como começou a funcionar.
Eu tenho um modem ZTE MF-193E que funcionou bem antes. Quando comprei este modem há mais de um ano, ele funcionou prontamente fora da caixa. Agora, como o Ubuntu está progredindo na versão, as coisas estão se tornando cada vez mais difíceis para mim.
Este modem funcionou alguns meses atrás com o Ubuntu 15.04 (64 bits). Agora, no Ubuntu 15.10 (64 bits), ele não consegue se conectar.
Eu tenho configurar uma conexão de banda larga móvel . Eu tentei várias strings para 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, Modem Manager GUI detecta este dispositivo com facilidade. Os SMSs podem ser enviados e recebidos sem qualquer problema.)
Quando insiro o modem, ele é detectado bem, um ícone de CD é exibido no Unity com o nome do modem. Alguns segundos depois Eu recebo uma caixa de mensagem
Mobile Broadband Network: you are registered on the home network
perto do ícone da rede.
Quando tento conectar, o ícone sem fio no miniaplicativo do gerenciador de rede inicia esses movimentos centrífugos, mas eventualmente ele falha ao conectar e uma mensagem informa que estou off-line.
A linha que eu pude isolar de /var/log/syslog é isso,
NetworkManager[628]: <info> (ttyUSB1): device state change: ip-config
> -> failed (reason 'ip-config-unavailable') [70 120 5]
No entanto, não tenho certeza se este é o mais relevante.
Mais linhas de
/var/log/syslog pode ser encontrado aqui .
Atualização 1 - 06 de dezembro de 2015
Como apontado por um membro gentil, tentei a abordagem do módulo nf_conntrack_pptp .
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, o mesmo fracasso. Nenhuma mudança discernível no registro 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
Instalou ofono e, em seguida, tentou o modem novamente.
Consulte 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
Alterado tudo "negar" para "permitir" em /etc/dbus-1/system.d/nm-dispatcher.conf .
Tentei ligar. Sem sorte.
Algumas redes conectam e desconectam com a conexão Ethernet.
Seguido por sudo systemctl restart network-manager.service .
Conecte e conecte o modem.
Tentei ligar novamente. Não conecta.
O registro é 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.py devido a vários erros. Encontrou o arquivo no local indicado. Obtive isso de, link .
Os comandos acima são um pouco diferentes daqueles no Wiki.
Os arquivos de registro são aqui .
Atualização 7 - 07 de dezembro de 2015
Executado novamente (após a alteração sugerida em /lib/udev/rules.d/40-usb_modeswitch.rules e 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 /var/log/syslog também está incluído.
Os arquivos de registro são aqui .
Atualização 8 - 08 de dezembro de 2015
O conjunto de registros atualizado é aqui .
Atualização 9 - 08 de dezembro de 2015
Teste 1
Desta vez, inicializou o computador 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.
Inseriu o modem. lsusb mostrou que estava sendo reconhecido como um
19d2: 1232 dispositivo que precisa ser swithced para um 19d2: 2003
dispositivo. Desde a instalação do usb-modeswitch requer a reinicialização do
máquina (e, portanto, perder a instalação para execução de DVD), eu preparei um
arquivo de switch personalizado e alternou o modem da linha de comando ( sudo
usb_modeswitch -I -c 19d2:2003 ).
Assim que a troca foi realizada, fui informado de que estava
em Mobile Broadband Network e uma Nova Conexão de Banda Larga appreard
no menu do gerenciador de rede.
Configurei a conexão acima da maneira usual (o nome do APN não era questão), e a conexão foi estabelecida automaticamente.
Desconectei e ejetei o modem.
Parou de capturar o log do MM.
O log e o log completos do MM para o início da sessão para a ejeção do modem podem ser encontrados aqui .
Teste 2
O mesmo teste com um DVD de 64 bits do Ubuntu 14.04.
Os registros podem ser encontrados aqui .
Atualização 10 - 09 de dezembro de 2015
Desta vez testado com wvdial e descobriu que se wvdial for executado como raiz,
obtemos uma conexão bem-sucedida .
O wvdial conf e o log e o syslog correspondente são aqui
Conjectura principal: a situação pode ter algo a ver com o grupo de utilizadores do utilizador correspondente.
Mas, conforme indicado aqui ,
Com todas essas ferramentas, para estabelecer uma conexão discada, o usuário para ser membro dos grupos "dip" e "dialout", então coloque todos os usuários que devem se conectar via discada nesses grupos.
Mas como podemos encontrar,
$ groups masroor
masroor : masroor adm dialout cdrom sudo dip plugdev lpadmin sambashare family wireshark
Então, o usuário já é um membro dos grupos indicados.
Agora, talvez a questão se reduz a qualquer um desses pontos,
Atualização 11 - 09 de dezembro de 2015
wvdial funciona 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 veja essas quatro linhas perto do início do arquivo?
Atualização 12 - 10 de dezembro de 2015
Comentou a linha 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end" ) em /lib/udev/rules.d/77-mm-zte-port-types.rules .
Reinicie minha máquina. Soft desconectou o cabo e inseriu o modem.
Tentou se conectar. Sem sucesso.
O arquivo syslog é 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, testamos a máquina com os DVDs Ubuntu 15.04 e 15.10.
O que aconteceu entre 15.04 e 15.10?
É tão frustrante.
Atualização 14 - 10 de dezembro de 2015
Criamos um novo arquivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules conforme instruído na resposta.
Reiniciei minha máquina (ou executei sudo udevadm control --reload , na verdade tentei os dois). Inseriu o modem.
O modem foi reconhecido.
$ lsusb
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
O Soft desconectou o cabo e tentou se conectar usando o modem. Sem sucesso.
Ejetou o modem.
A máquina trava uma vez, isso é um evento aleatório? Minha máquina não costumamos pendurar uma vez por ano.
O arquivo syslog e os arquivos de regras criados são aqui .
Atualização 15 - 11 de dezembro de 2015
Adicionadas as linhas a seguir a /lib/udev/rules.d/40-usb_modeswitch.rules .
# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
Deixou o arquivo /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules intact.
Reinicie minha máquina. Inseriu o modem.
O modem foi reconhecido.
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
O Soft desconectou o cabo e tentou se conectar. Sem sucesso.
Ejetou o modem.
Removido /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules .
Reiniciei e tentei todo o processo novamente. Sem sucesso novamente.
O arquivo syslog (completo, não corri o risco de perder nenhum parte importante) e o arquivo de regra mencionado (40) são aqui .
Atualização de 16 a 11 de dezembro de 2015
Deixou apenas uma regra 1232 em
/lib/udev/rules.d/40-usb_modeswitch.rules , removeu o outro
um.
Executou sudo udevadm control --reload .
Inseriu o modem.
O modem foi reconhecido.
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
O Soft desconectou o cabo e tentou se conectar. Sem sucesso.
Ejetou o modem.
Mas não testamos o sistema padrão acima? Você queria deixar /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules em seu lugar?
O arquivo syslog (completo, não corri o risco de perder nenhum parte importante) e o arquivo de regra mencionado (40) são aqui
Atualização 17 - 11 de dezembro de 2015
Comentou a regra 1232 em
/lib/udev/rules.d/40-usb_modeswitch.rules , adicionado um para 2003.
# ZTE MFxxx
# Added on December 11 2015
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
Executou sudo udevadm control --reload .
Inseriu o modem.
O modem foi reconhecido como um dispositivo 1232 . Eu não estou disponível para tentar conectar (até onde eu saiba, 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
Ejetou o modem.
O arquivo syslog e o arquivo de regra mencionado (40) são aqui
Atualização 18 - 11 de dezembro de 2015
Coloque todos os arquivos de regras em sua forma original.
Assistiu a lsusb de saída a cada segundo usando um shell
roteiro. Saída capturada em arquivos com registro de hora.
Inseriu o modem. (O modem aparece pela primeira vez no arquivo %código%). Como podemos encontrar das capturas, é claro que ele muda de um dispositivo 1232 para um 2003.
Tentou se conectar. Sem sucesso.
Ejetou o modem.
O arquivo syslog, a hora carimbada em lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt outputs e os arquivos de regras mencionados são aqui .
Agora, você pode querer combinar as saídas do syslog com os timestamps.
Atualização de 19 a 11 de dezembro de 2015
Realizei este teste em uma nova direção com o desejo de que eu poderia isolar os problemas.
Salvo em uma mídia portátil lsusb e /lib/udev/rules.d/40-usb-media-players.rules (da máquina Ubuntu 15.10).
Inicializou a máquina usando o DVD de 64 bits do Xubuntu 15.04.
Executou /lib/udev/rules.d/77-mm-zte-port-types.rules . O primeiro arquivo é daquele que foi salvo
a partir de 15.10.
O exame do arquivo diff não 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 ou 2003.
Executou idProduct . Mais uma vez, o primeiro arquivo é daquele
salvo a partir de 15.10.
Novamente, o exame do arquivo diff não mostra diff 40-usb_modeswitch.rules
/lib/udev/rules.d/40-usb_modeswitch.rules >
diff15.10and15.04_40-usb.txt 1232 ou 2003.
Inseriu o modem. O modem foi reconhecido como um modem.
$ lsusb
Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
Poderia se conectar rapidamente após a configuração de uma conexão de banda larga móvel.
Ejetou o modem.
Instalou o USB_ModeSwitch mais recente.
diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
Agora retorna NULL, como esperado.
Executou idProduct .
Inseriu o modem. O modem foi reconhecido como um modem.
$ lsusb
Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
Pode se conectar facilmente.
Eu poderia ter tentado atualizar o MM e o NM para o Ubuntu 15.10, apenas para ver onde ele quebra. Eu realmente tentei, mas desisti devido a problemas de dependência sem fim.
Todos os arquivos diff mencionados acima são aqui .
Atualização de 20 a 12 de dezembro de 2015
Teste 1
O sudo udevadm control --reload-rules na condição original.
O dispositivo de modem ainda não foi inserido nesta sessão.
Configure o ModemManager para depurar e configurar a 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
Conectou o modem e esperou até que ele informasse que está registrado na rede de banda larga.
Tentou se conectar sem sucesso.
Ejetou o modem.
Pacotes de arquivos de log.
Teste 2
Repetiu o teste acima com
/lib/udev/rules no lugar.
Os nomes dos arquivos de log são autoexplicativos.
Todos os arquivos de log acima, além do syslog e dos 78 arquivos de regras, são aqui .
Eu gostaria que todos os arquivos de log viessem com carimbos de data / hora, facilitando a correspondência.
Atualização 21 - 15 de dezembro de 2015
O arquivo de regras e o /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules são aqui .
Atualização 22 - 16 de dezembro de 2015
Como recomendado em um comentário, instalei vários kernels de link e tentei conectar usando o modem depois de inicializar em cada.
4.2.8-040208-genérico, falha.
4.1.15-040115-genérico, falha.
4.0.9-040009-genérico, falha.
Então, talvez, possamos descartar o problema 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 modem começou a funcionar no Ubuntu 16.04. Esta versão ainda está em fase de desenvolvimento, mas funciona bem no meu laptop.
Gostaria de poder fornecer mais detalhes técnicos sobre como começou a funcionar.
Carregar o pacote ofono foi bom, provavelmente, mas aparentemente seu modelo de modem, ZTE MF193E, não está na lista da ZTE. Comparando com outros modems ZTE, por exemplo, MF190J, este modem provavelmente precisará da mesma regra especial udev , rodar usb_modeswitch quando o dongle for inserido, e para conseguir isso você pode, como root, adicionar um novo udev regra para o arquivo
/lib/udev/rules.d/40-usb_modeswitch.rules
com as duas linhas seguintes, por exemplo, em algum lugar perto do comentário # ZTE MF190J :
# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
mais uma linha em branco, para que pareça agradável aos olhos.
Provavelmente é melhor reiniciar depois disso, apenas para descobrir que tudo funciona como mágica: -)
Ou não. Como você sabe, isso é em águas profundas para mim, mas se ainda não funcionar, outro log de depuração do ModemManager seria necessário, para outro palpite.
EDITAR:
Agora estou olhando para 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'
apn='WAP' , mas o ModemManager estabelece uma correspondência insensível a maiúsculas e minúsculas.
A diferença entre maiúsculas e minúsculas pode ser a causa do problema subsequente: por exemplo, que o ppp queira uma configuração 'wap' (em vez de 'WAP' ) e não a encontre, ou que a extremidade remota espere apn='WAP' , mas fica 'wap' que 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 pacote ofono , então outro teste não vai doer, embora a segunda opção seja mais provável.
A segunda opção também é um problema maior, já que há uma correspondência de "contexto PDP" em maiúsculas disponível no modem. Ao pesquisar essa questão, parece que a correspondência insensível a maiúsculas e minúsculas está correta pela especificação (aparentemente relevante) "3GPP TS 23.003 capítulo 9.1", e um patch para isso foi adicionado a ModemManager em novembro do ano passado (em sua versão mm-1 -4, eu posso reunir). Portanto, nesse caso, seu modem não foi informado e espera correspondência com distinção entre maiúsculas e minúsculas, enquanto ModemManager infelizmente usa a correspondência sem distinção entre maiúsculas e minúsculas em vez de um fallback.
Uma solução para o segundo problema é usar um ModemManager diferente: localizando e instalando uma versão anterior a este patch, ou (com tempo livre suficiente), role seu próprio ModemManager . Mas também não é algo a se fazer por capricho, então talvez precisemos navegar um pouco para obter mais evidências de que esse é (agora) o problema e, se possível, encontrar outras maneiras de contornar isso. Ou com um pouco de sorte, alguém que sabe que algo passa ...
EDIT 2
Sim, a reversão de versão não é fácil devido a dependências. E rolar o seu próprio está longe de ser uma alegria também.
Duas possíveis ferramentas úteis: comando mmcli e
( link ).
O problema, eu acho, é que o ModemManager escolhe o contexto PDP 1 com apn = 'wap', onde deveria escolher o contexto PDP 9 com apn = 'WAP'. Talvez isso possa ser resolvido usando uma dessas ferramentas. Ou para forçar uma seleção de 9 durante a conexão ou excluindo os contextos 'wap' inválidos do modem, para os quais a ferramenta testador de módulos é anunciada para ser capaz.
A ferramenta modem-tester parece ser uma ferramenta java no navegador, então você precisa configurar o seu navegador para saber onde o seu java está, e você precisa que o java seja conhecido. Então, por favor, explore essa abordagem; Eu não usei isso sozinho, mas vendo as imagens, eu acho que ele irá apresentar os contextos de PDP como a guia 'Chamadas de dados', onde você primeiro tomar nota de tudo o que mostra e, em seguida, editar as entradas 'wap' para distorcer os rótulos apn 'wap' para serem, digamos, 'wap1' e 'wap2' (para "escondê-los" ao procurar por 'WAP'). Em seguida, salve e feche e manipule o dongle novamente. Pegue um log; parece que o syslog é suficiente agora, caso ele ainda se recuse a jogar.
O comando mmcli também parece útil nesta história; do man mmcli para ler sobre isso, mas não vi nada sobre os contextos do PDP lá.
EDIT 3
Boa ligação! para testar a partir do DVD. Isso nos disse que estou no caminho errado com a APN, e que tudo está em fazer o ppp aparecer. Pelo menos, essa seria minha nova árvore para latir.
Primeiramente, tomamos nota que há uma diferença de versão para o pppd (de 2.4.5 para 2.4.6), mas isso provavelmente não é um problema, já que todos em um dongle estariam nessa excursão.
Hmm, ppp; Eu preciso agitar minhas memórias do último milênio :-). Infelizmente estou ocupado hoje, mas vou tocar na base quando tiver tempo, para ver até onde você chegou. Meus primeiros becos a serem examinados 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 por alguns dias atrás), mas também deve haver uma maneira de pedir um registro mais detalhado.
EDIT 4
Garanta que /etc/ppp/pap-secrets e /etc/ppp/chap-secrets tenham o grupo dip (usando chgrp conforme necessário) e o modo 740 (ou -rw-r----- ) (usando chmod conforme necessário). O meu não fez.
EDIT 5
Como sobre essa árvore, em seguida: Comparando o trabalho wvdial syslog com o syslog que não funciona, parece que por algum motivo wvdial usou ttyUSB3 , enquanto a ModemManager que não trabalha continua usando ttyUSB1 . Não tenho certeza se é de todo significativo, mas aparentemente, mas ttyUSB1 e ttyUSB3 respondem como modems AT.
Então, como um teste, talvez você possa editar /etc/wvdial.conf , de forma que o [Dialer Defaults] inclua a linha:
Modem = /dev/ttyUSB1
para o teste one e ttyUSB3 para outro; ambos rodando como root; só para ver se há um comportamento diferente. Especialmente, se usar ttyUSB1 é um problema, enquanto usar ttyUSB3 não é, então seria bom verificar como fazer o ModemManager usar ttyUSB3 também. Para qualquer outro resultado do teste, eu diria que voltaremos a perseguir furões em ppp land.
EDIT 6
O log do dmesg pode ser ignorado, eu acho; Tem sido assim em todos os logs.
O novo syslog mostra apenas o teste ttyUSB3, mas talvez possamos supor que a vida fica melhor se NetworkManager puder ser usado para usar ttyUSB3 e ignorar ttyUSB1 (para este modem).
Eu também encontrei ( link ) especialmente com o pós # 10 desconcertante :-(
A regra udev aparentemente aplicável em /lib/udev/rules.d/77-mm-zte-port-types.rules não se aplica, mas seria supostamente para onde ir. E, com apenas um insight muito rudimentar sobre a udev magic, eu gostaria de questionar a quarta linha, que diz:
SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"
Acho que essa linha precisa de um # inicial para ser comentada. Em detalhes, minha leitura do arquivo é que ele requer um estado de chamada de SUBSYSTEM == "tty" e SUBSYSTEMS="usb" para usar os bits bons, incluindo as regras do produto "2003", e pelo menos para testes, Deve ser seguro pular a filtragem "tty". E eu não tenho nada melhor agora.
EDIT 7
Depois de ter passado algum tempo de qualidade com o meu mecanismo de busca favorito, acredito um pouco mais que a escolha do ttyUSB seja um problema de 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 para o final desse arquivo, para o ID do produto "2003", são enganosas. A partir dos logs, parece-me, que o ID do produto "2003" é, na verdade, o lado do dispositivo de memória do dongle, enquanto o lado do modem possui 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 dele, por exemplo chamado 78-ralph.rules , mas você também precisa adicionar a proteção SUBSYSTEM e SUBSYSTEMS ao redor dele.
Em seguida, puxe o dongle, execute udevadm control --reload (ou reinicialize) e insira o dongle. E depois ainda outro syslog captura, a menos que agora aconteça.
libmm-plugin-zte.so no pré-teste e acaba usando um manipulador genérico de modems. Se estou certo sobre o ID do produto, esse pode ser o motivo; esse pré-teste procura por uma atribuição ID_MM_ZTE_PORT_TYPE_MODEM , e isso está faltando para o ID do produto "1232" (antes do patch), com o efeito que o plugin zte é descartado.
EDIT 8
O syslog log é um pouco curto; faltando o início onde o ModemManager não consegue instalar o plugin zte. No entanto, é claro que o plugin do modem genérico é usado de qualquer maneira. Agora, pode ser que a regra usb_modeswitch que eu te dei no início esteja errada também; decide mudar para "2003" quando eu pensei que ele tinha comutado de "2003". Mas, man usb_modeswitch (que eu deveria ter olhado antes) sugere que ele muda para um id de produto em vez de de ele. Em qualquer caso, o log mostra que isso aconteça. 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
Bom. O problema ainda é (ou também) que o ModemManager elimina o plugin ZTE no momento da pesquisa. Os logs de depuração do ModemManager para o 15.10 (conjuntos de log "debuglogs *") contam a história de que o plugin ZTE é descartado devido ao teste id / product-id do fornecedor.
Vá para a fonte, Luke! Eu aproveitei esta oportunidade para avistar o código fonte do ModemManager brevemente, e ele indica que o plugin como uma tabela de vid / pid que não inclui 19d2 / 2003 ... no entanto, não encontrei a origem da tabela, por isso não pude verificar.
Ou talvez haja um problema de tempo aqui. Por exemplo, o ModemManager é executado enquanto o dispositivo é 19d2 / 1232. Esse pensamento está alinhado com a observação de que ter as regras do udev de 78 mm-zte-port-types-RALPH.rules torna o ModemManager um pouco mais feliz com o dispositivo. Mas então, por que ele não fica feliz e faz uso desse plugin quando o dispositivo é alterado para 19d2 / 2003?
Talvez sejam necessários mais registros :-) Com o ModemManager depurado, e também uma captura do comando udevadm monitor --e |& tee udevadm.log (em outro terminal) ao conectar o dispositivo. Eu recebi o comando de ( link )
Faça isso duas vezes: uma vez sem 78-mm-zte-port-types-RALPH.rules e uma vez com as regras ... ambas as vezes de uma nova reinicialização. Ou seja,
/lib/udev/rules.d com ou sem o arquivo *-RALPH.rules Esse registro deve dizer onde o plugin ZTE é removido, e como eu entendi, ele também irá informar sobre o tratamento do evento do udev.
EDIT 10
(Eu estou quase no final da minha corrente aqui, mas eu tenho mais uma ou duas respirações: -)
Em primeiro lugar, todas as decorações udev parecem acabar como deveriam, com apenas alguns pontos de interrogação em alguns dos atributos. Em particular, o 78-*-RALPH.rules deve ser descartado; não é útil.
Acho que posso ler algo a partir disso, mas não sei exatamente como isso deve ser corrigido. Basicamente, como eu vejo, quando o dongle está conectado, há uma enxurrada de eventos do udev. Concentrando-se naqueles que dizem respeito ao ttyUSB1, há um evento "inicial":
KERNEL[3867.310990] add /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1 (usb)
que faz com que o driver usb_serial seja carregado e /dev/ttyUSB1 seja exibido. 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)
Acho que isso também aciona ModemManager . Você precisa ir para syslog para ver evidências disso, já que não há correlação estrita entre os logs. O evento tem o carimbo de hora 3867.435102 e syslog apresenta a linha de log ModemManager subseqüente logo após uma linha de log do kernel carimbar 3867.437412 .
Na minha linha de pensamento, ModemManager nã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 da ZTE.
No log do MM, estaríamos na linha carimbada 1449934745.363291 , que aparentemente é um carimbo de hora "em tempo real" em vez de um carimbo "hora do kernel".
ModemManager é feito com sua pré-análise em 1449934745.450398 , ou seja, 87ms depois, que em termos de tempo do kernel estaria próximo de 3867.524519 e 55ms antes do relatório de evento UDEV "bom" acima.
Observe que em syslog , ModemManager apresenta reclamações de que ttyUSB1 não tem seus atributos definidos e talvez essa reclamação esteja relacionada à "marcação" em 80-mm-candidate.rules . Com o comentário nesse arquivo, essa marcação parece ser uma tentativa de lidar exatamente com esse problema, mas, se for o caso, parece não funcionar neste caso.
Talvez uma possibilidade para resolver isso seja alterar a regra "tty" em 80-mm-candidate.rules :
ENV{.ID_PORT}=="?*", SUBSYSTEM=="tty", ENV{ID_MM_CANDIDATE}="1"
Na minha opinião, isso garantirá que a configuração ID_MM_CANDIDATE seja atrasada até que os atributos ZTE sejam definidos. A configuração .ID_PORT é um efeito de uma regra 60-serial.rules (chamada 60-persistent-serial.rules before) 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, em vez disso, exigir ENV{.MM_USBIFNUM}="?*" , já que a atribuição aqui acontece por 77-mm-zte-port-types.rules .
Em geral, não tenho muita certeza sobre a udev de ordenação de regras, e também não tenho certeza de que isso realmente impede que ModemManager atue rápido demais. No entanto, se isso não acontecer, então 80-mm-candidate.rules teria pouca ou nenhuma função, e talvez então tudo se resumisse às "melhorias" para ModemManager de 15.04.
EDIT 21
suspiro. Provavelmente irrelevante, mas você pode querer verificar o seu arquivo 7-zte-mutil_port_device.rules ; isso é um remanescente de outra experimentação? De qualquer forma, não é relevante aqui.
Ainda há quase um segundo entre 515.558184 e 516.381549 onde ModemManager avidamente e erroneamente pega /dev/ttyUSB1 e, embora reclamando que não está sendo configurado, ainda passa pela pré-análise e descarta o plugin ZTE. Em outras palavras, o patch de regra não faz ModemManager wait.
Suponho que você também testou usando ENV{.MM_USBIFNUM}="?*" em vez de ENV{.ID_PORT}=="?*" .
Na verdade, para confirmar se a configuração ENV{ID_MM_CANDIDATE}=1 é de alguma importância, mova temporariamente 80-mm-candidate.rules e, em seguida, veja (em syslog ) se ModemManager ignora /dev/ttyUSB1 ou não. Eu suspeito "não".
E então, bem, talvez você possa usar uma versão de trabalho, como 14.04, e, se precisar, executar 15.10 em uma caixa virtual, a menos que já esteja tudo em uma caixa virtual.
Acho que preciso reivindicar a derrota neste momento.
Depois de dar uma olhada nisso, parece que esta não é a primeira vez que este dragão foi devidamente tratado. Foi um erro antes em 12.10 e 13.04, talvez o bug nunca tenha sido corrigido ou um novo patch tenha quebrado algo que estava funcionando corretamente antes.
Espero que, se eu estiver lendo suas especificações técnicas corretamente, eu precise apontá-lo nessa direção (MF190J):
Você já tentou isso:
rfkill list up
e, em seguida, 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 assim.