¶ INSTRUÇÃO DE TRABALHO
¶ Objetivo
Descrever os processos básicos de análise e troubleshooting dos principais casos que requeiram o acionamento do SN2 (Suporte Nível 2) pelo SN1 (Suporte Nível 1).
Observações.
O acionamento do SN2 pelo SN1 deverá ser regulamentado dentro do fluxograma de trabalho padrão da própria Faiston. Maiores detalhes poderão ser esclarecidos pela equipe de processos da Faiston.
¶ Arquitetura da Plataforma SDWAN Telcoweb
A arquitetura da plataforma de conectividade da Telcoweb pode ser dividida em duas camadas, de acordo com suas funções de gerenciamento e rede.
- Controle e Gerência
- CPE
¶ Camada 1 – Nuvem de Controle e Gerência
A camada de controle e gerência é hospedada no domínio da Telcoweb da nuvem (pode ser AWS, ou qualquer outro provedor). É composta basicamente por servidores virtuais que operam em regime de alta disponibilidade. Os servidores da camada de nuvem se comunicam entre si e com os CPEs para controlar as conexões entre e com os próprios CPEs, através de políticas de conectividade IP.
A camada de nuvem também é responsável pelo recebimento e armazenando das informações de estado e desempenho de todos os CPEs. A comunicação entre o CPE e a nuvem á feita usando protocolo IoT. Uma vez na nuvem, as informações são mostradas de forma estruturada e amigável no Portal Telcoweb (https://portal.telcoweb.co). O portal também interage com a plataforma Whatsapp para envio dos alarmes.
Na Figura 1 é possível observar que o ambiente da Telcoweb da camada 2 também acomoda os gateways (GWs) de conectividade de todos os clientes. Os GWs de conectividade são exclusivos para cada cliente, criando as redes privadas de cada cliente de forma exclusiva e totalmente independente. Ou seja, a partir da rede privada do cliente 1, é impossível acessar a rede privada do cliente 2.
Figura 1 - Arquitetura Telcoweb compreendendo a nuvem e o CPE
Entretanto, uma vez acessando o GW privado do cliente 1, o analista terá acesso a todos os CPEs que compõem a rede do cliente 1. Ou seja, além de fazer a tarefa de interconexão do tráfego privado entre os CPEs de um mesmo cliente, o GW permite o acesso do analista a cada um dos CPEs conectados para fins de gerenciamento e análise de falhas.
¶ Camada 2 – CPE (Customer Premises Equipment)
A camada 2 é o próprio CPE TW-EZ1. O TW-EZ1 é um appliance (hardware + software) que opera fisicamente dentro do ambiente do cliente.
O TW-EZ1 interconecta as duas LANs (LAN1 e LAN2), onde ficam os equipamentos internos do cliente: laptops, PCs, APs Wifi (access points) etc, com as WANs (WAN1, WAN2 e WANcell), que por sua vez se conectam aos provedores de acesso (ISPs).
A arquetura interna do TW-EZ1 compreende 3 “roteadores virtuais: NS1, NS2 e NS17 (containers virtuais) que são logicamente conectados às suas respectivas portas no hardware do CPE. Isto é:
- NS1 conectado à interface física enp1s0, compondo a WAN1,
- NS2 conectado à interface física enp1s0, compondo a WAN2 e
- NS17 conectado à interface lógica ppp ou wwan, compondo a WANcell.
Além dos roteadores virtuais NS1, NS2 e NS3, o appliance TW-EZ1 também abriga um switch (SW) virtual, responsável em oferecer os recursos de conectividade local LAN1 e LAN2.
O SW virtual se conecta logicamente e simultaneamente aos três “roteadores virtuais” NS1, NS2 e NS17 através de recursos de conexão de software que são controlados pelo protocolo (OpenFlow).
A Figura 2, logo a seguir mostra graficamente a arquitetura interna do CPE.
Figura 2 - Arquitetura interna do CPE TW-EZ1
Nesta arquitetura, é importante observar que o controle e a análise sobre as interfaces físicas que compõem as WAN1 1, 2 e 17 só podem ser executados a partir dos mesmos.
Ou seja, para analisar o estado da interface enp1s0 (WAN1) o analista deve acessar o NS1 e assim por diante. Maiores detalhes sobre este acesso serão dados nos procedimentos de acesso, logo a frente.
¶ Acesso via gateway Telcoweb
O acesso aos CPEs de todos os clientes SDWAN Telcoweb pode ser feito através do gateway de nuvem. Como mostrado na Figura 1, o gateway de nuvem faz parte da camada 2 da plataforma Telcoweb e está hospedado na nuvem, como a nuvem AWS de são Paulo.
O acesso ao Gateway é protegido por senha e por chave pública ssh. Isto significa que, mesmo que se saiba o login/senha do usuário de acesso, a chave pública ssh do PC, a partir do qual se tenta o acesso, também precisa estar cadastrada no servidor.
Uma vez cumpridas estas etapas de segurança, o acesso pode ser feito a partir da seguinte linha de comando.
ssh faiston@gateway2.telcoweb.com.br
Após entrar da VM que abriga todos os gateways dos clientes Telcoweb, o usuário poderá consultar qual o nome do Gateway que ele precisa acessar.
sudo docker ps
Este comando lista na tela todos os containers da VM gateway2.telcoweb.com.br.
A Figura 3 logo abaixo mostra um exemplo do resultado do comando anterior.
Figura 3 - Resultado do comando sudo docker ps, mostrando todos os gateways de clientes da VM gateway2.telcoweb.com.br.
Ao encontrar o nome do cliente, que geralmente coincide com o nome do gateway, o analista deve listar o endereço IP do CPE que ele precisa acessar para fazer a sua análise.
sh list-wg-peers.sh <cliente>
Figura 4 - Resultado do comandosh list-wg-peers.sh <cliente>.
O comando sh list-wg-peers.sh <cliente> retornará a lista de CPEs e seu respectivo IP de gerência (ex: 10.141.1.11) que deverá ser usado para o acesso ao mesmo.
A Figura 4 mostra o retorno do comando sh list-wg-peers.sh faiston. Assim, se o analista precisar acessar o CPE da logística, ele deverá anotar o endereço 10.141.1.11.
A única forma de acessar um CPE de determinado cliente para executar comandos pelo terminal é através do gateway deste cliente.
Por exemplo, se precisar fazer uma análise no CPE da Logística do cliente Faiston, basta primeiramente entrar no GW faiston através do seguinte comando:
docker exec –it faiston /bin/bash
A Figura 4 mostra graficamente o prompt de comando do gateway da Faiston.
Figura 4 – Prompt da linha de comando no gateway da Faiston
A partir do prompt do gateway da faiston (root@52f3cd99539d:/#) você poderá listar todos os CPEs conectados e o IP de gerência de cada um deles a partir do comando.
ssh sduser@10.141.1.11
¶ Cenários de acionamento do SN1 ao SN2
Esta seção descreve os principais cenários (mais comuns) de acionamento entre o SN1 Faiston e SN2 Faiston, bem como as informações necessárias para concretizar o acionamento.
Além de descrever os cenários de acionamento, a seção também oferece instruções de trabalho (manual), com o objetivo de orientar o analista do SN2 no trabalho de análise e troubleshooting de cada acionamento.
¶ Alarme de falha nas WANs 1 e 2 (WANs físicas)
As WANs 1 e 2 são diretamente conectadas via cabo de par trançado (Ethernet) ao modem/roteador do provedor.
¶ Modem DOWN – Status DOWN
Falha Física. Provávieis diagnósticos:
- Cabo de rede entre a interface WAN do CPE e o modem/roteador desligado
- Cabo de rede entre a interface WAN do CPE e o modem/roteador com defeito
- Modem/roteador desligado
- Modem/roteador com defeito
Figura 5 - Exemplo de página no portal Telcoweb, mostrando as
Na figura 5, ressaltada pelo círculo vermelho, é possível observar que tanto a conexão do CPE TW-EZ1 com o modem do provedor (físico), quanto a conexão fim-a-fim com a Internet (lógica) estão alarmadas a partir da WAN1.
Este alarme indica que não há conexão física entre a WAN do CPE e o modem/roteador do provedor está caída e portanto, nenhuma outra conexão estará funcionando. Assim, a informação do Status, que se refere à capacidade do CPE em se comunicar com a Internet, também cai consequentemente para DOWN, como pode ser observado na Figura 6 do Portal Telcoweb (https://portal.telcoweb.co).
Os prováveis diagnósticos para este cenário são:
- Cabo entre a WAN do CPE e o modem do provedor está desconectado e/ou com defeito.
- Modem do provedor está desligado ou com defeito.
A presença de uma pessoa no ambiente do cliente para fazer uma vistoria visual e eventualmente enviar fotos dos LEDs de conexão dos lados do CPE e do modem e eventualmente enviar fotos, pode facilitar muito no diagnóstico e nas ações de reparo.
O diagnóstico de Modem Down também pode ser acompanhado a partir do CPE, através do seguinte comando.
sudo ip netns exec ns-wan1 ip a
A Figura 6 mostra o resultado do comando sudo ip netns exec ns-wan1 ip a, ressaltando a linha que mostra o estado DOWN da interface enp1s0, o que indica falha física entre o CPE e o modem/roteador do provedor.
Figura 6 - Resumo dos estados das interfaces do CPE.
¶ Modem UP – Status DOWN
Figura 7 - Tela do portal Telcoweb, mostrando o estado Up/Down.
O estado Modem UP - Status Down é mais complexo e requer uma análise mais detalhada por parte do analista de rede. As possíveis causas deste tipo de problema são:
- Rompimento de Fibra ótica na rede de acesso do provedor.
Este é sem dúvida a causa mais comum de problemas, principalmente se a fibra chegar ao modem do provedor por via aérea (postes). A forma mais fácil de comprovar este diagnóstico é observar o alarme de LOS (Loss os Signal), como mostrado na Figura 8.
Figura 8 - Alarme de LOS no modem do provedor.
Se o LED de LOS estiver alarmado, significa que o modem do provedor perdeu comunicação ótica com a rede e portanto, não há conexão com a Internet. Havendo alguém no local do modem, vale a pena pedir para desligar e religar o modem do provedor após alguns segundos e observar posteriormente se o alarme desaparece. Não desaparecendo, a única opção que resta é realmente abrir um chamado de reparo com o provedor.
Do ponto de vista do CPE, uma falha da rede ótica pode ser rapidamente comprovado testando a conectividade com o próprio modem, usando o comando ping, como mostrado logo a seguir.
Por exemplo, se a interface sem conexão for a WAN2 do CPE.
sudo ip netns exec ns-wan2 ifconfig enp2s0
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.15.138 netmask 255.255.255.0 broadcast 192.168.15.255
inet6 fe80::2e0:1dff:fe03:f238 prefixlen 64 scopeid 0x20<link>
inet6 2804:7f0:bde1:1393:2e0:1dff:fe03:f238 prefixlen 64 scopeid 0x0<global>
ether 00:e0:1d:03:f2:38 txqueuelen 1000 (Ethernet)
RX packets 29238352 bytes 32585626572 (32.5 GB)
RX errors 0 dropped 1294 overruns 0 frame 0
TX packets 13895759 bytes 7359418696 (7.3 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xd0800000-d081ffff
sudo ip netns exec ns-wan2 ping 192.168.15.1
PING 192.168.15.1 (192.168.15.1) 56(84) bytes of data.
64 bytes from 192.168.15.1: icmp_seq=1 ttl=64 time=0.491 ms
64 bytes from 192.168.15.1: icmp_seq=2 ttl=64 time=0.333 ms
sudo ip netns exec ns-wan2 ping 8.8.8.8
PING 8.8.2.1 (8.8.2.1) 56(84) bytes of data.
--- 8.8.2.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6107ms
Observar que primeiramente o ping retornou OK quando direcionado para o IP da interface do modem diretamente conectada à WAN2 do CPE, o que indica que o modem está conectado fisicamente e está respondendo corretamente. Entretanto, o segundo comando de ping para a Internet (8.8.8.8), retornou perda de 100%,indicando que o modem não está conseguindo rotear pacotes para a Internet.
¶ Alarme de falha na WAN Cell
A interface WAN Cel, como o nome sugere, se forma logicamente a partir da interação do conjunto sim card + modem 4G do CPE com a rede da operadora celular.
Figura - Tela do portal mostrando falha na interface Wancell do CPE
O estabelecimento da conexão e o tráfego de dados pela WAN Cell depende:
- Sim card habilitado pela operadora (Vivo, Claro ou Tim).
- Configurações de APN, usuário e senha corretos, de acordo com a operadora do sim card.
- Antenas corretamente instalada nos conectores do CPE.
- Sinal celular da operadora com nível suficiente.
- Módulo sim card corretamente instalado, como mostra a Figura 10.
**Figura 10 - Foto do slot que fica debaixo da placa de modem dentro do CPE e que acomoda o SIM card da operadora celular.
Assim, dependendo de tantos fatores, inclusive de alguns que podem se alterar online, a WAN Cel tende a ser mais instável do que as WANs fixas (1 e 2).
Ao receber uma solicitação de suporte do N1, o analista N2 deve verificar primeiramente o estado físico do sim card no CPE. Esta verificação pode ser feita através de dois comandos.
mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [QUALCOMM INCORPORATED] QUECTEL Mobile Broadband Module
O comando mmcli -L mostra o ID obtido pelo modem do ponto de vista do sistema operacional do CPE. Neste caso o ID é 1. A partir dainformação doID do modem, pode-se consultar detalhes sobre o estado deste modem com o comando.
sudo mmcli -m 1
----------------------------------
General | path: /org/freedesktop/ModemManager1/Modem/1
| device id: 2190488a12cb644ba641fc3177145673985f2603
----------------------------------
Hardware | manufacturer: QUALCOMM INCORPORATED
| model: QUECTEL Mobile Broadband Module
| firmware revision: EC25AUFAR06A03M4G
| carrier config: default
| h/w revision: 10000
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: 866989050119798
----------------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4
| drivers: qmi_wwan, option
| plugin: quectel
| primary port: cdc-wdm0
| ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (gps),
| ttyUSB2 (at), ttyUSB3 (at), wwx26cf549d7236 (net)
----------------------------------
Status | lock: sim-pin2
| unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10)
| state: registered
| power state: on
| access tech: lte
| signal quality: 97% (cached)
----------------------------------
Modes | supported: allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 2g, 3g; preferred: 3g
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 4g; preferred: 4g
| allowed: 2g, 4g; preferred: 2g
| allowed: 3g, 4g; preferred: 4g
| allowed: 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 2g
| current: allowed: 4g; preferred: none
----------------------------------
Bands | supported: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
| current: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
----------------------------------
IP | supported: ipv4, ipv6, ipv4v6
----------------------------------
3GPP | imei: 866989050119798
| enabled locks: fixed-dialing
| operator id: 72410
| operator name: VIVO
| registration: home
----------------------------------
3GPP EPS | ue mode of operation: csps-2
| initial bearer path: /org/freedesktop/ModemManager1/Bearer/2
| initial bearer ip type: ipv4v6
----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/1
----------------------------------
Bearer | paths: /org/freedesktop/ModemManager1/Bearer/3
Observar que a qualidade do sinal (signal quality) está em 97% (> 80% é ótimo) e que o SIM card está corretamente registrado na Vivo (PLMN 7410).
O PLMN (Public Land Mobile Network) é a identificação da rede da operadora móvel celular.
Lista dos PLMNs das principais operadoras (Vivo, Claro e TIM) do Brasil.
72410, 72411 e 72406 - Vivo
72405, 72438 - Claro
72402, 72403 e 72404 - Tim
O estado (state) do SIM card mostrado acima é "registrado" (registered), o que significa que a rede da operadora Vivo "entende" o SIM card como parte normal da rede da mesma. Neste caso, o analista deve restartar o serviço wancell e observar a evolução do script de conexão do CPE.
sudo systemctl restart wancell_service.service
journalctl -f -u wancell_service.service
Feb 06 07:59:34 b-drops-1 pppd[3406749]: Connection terminated.
Feb 06 07:59:34 b-drops-1 pppd[3406749]: Exit.
Feb 06 07:59:34 b-drops-1 systemd[1]: wancell_service.service: Deactivated successfully.
Feb 06 07:59:34 b-drops-1 systemd[1]: Stopped Wancell service.
Feb 06 07:59:34 b-drops-1 systemd[1]: wancell_service.service: Consumed 39.026s CPU time.
Feb 06 07:59:34 b-drops-1 systemd[1]: Started Wancell service.
Feb 06 07:59:34 b-drops-1 wancell.sh[3878670]: # Building wvdial.conf
Feb 06 07:59:34 b-drops-1 wancell.sh[3878670]: Name space ns-wan17 already exists
Feb 06 07:59:34 b-drops-1 wancell.sh[3878670]: #### Flushing previous iptables entries
Feb 06 07:59:34 b-drops-1 wancell.sh[3878670]: ##### Getting CCID and CSQ
Feb 06 07:59:55 b-drops-1 wancell.sh[3878670]: ##### Starting the QMI connection by surveying the Modem's status
Feb 06 07:59:55 b-drops-1 wancell.sh[3878670]: Enabling modem 1
Feb 06 07:59:55 b-drops-1 wancell.sh[3879171]: successfully enabled the modem
Feb 06 08:00:05 b-drops-1 wancell.sh[3878670]: Modem 1 is registered
Feb 06 08:00:05 b-drops-1 wancell.sh[3878670]: The LTE modem is registered, so the script is proceeding to connect via qmi
Feb 06 08:00:06 b-drops-1 wancell.sh[3879405]: successfully connected the modem
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: State = registered
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: We have qmi connection by bearer 3
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: MTU 1500
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: WAN17_IFACE = wwan0
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: Address 10.115.5.109
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: Mask 30
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: ip link set wwan0 up
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip link set wwan0 up
Feb 06 08:00:06 b-drops-1 wancell.sh[3879436]: Cannot find device "wwx26cf549d7236"
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: ip link set wwan0 netns ns-wan17
Feb 06 08:00:06 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip link set wwan0 netns ns-wan17
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip addr add 10.115.5.109/30 dev wwx26cf549d7236
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip link set dev wwx26cf549d7236 mtu 1500
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip link set dev wwx26cf549d7236 arp off
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ifconfig wwan0 up
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: #### Flushing previous route entries
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 ip route add default dev wwx26cf549d7236
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ip netns exec ns-wan17 iptables -t nat -I POSTROUTING -o wwx26cf549d7236 -j MASQUERADE
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: ##### Checking wancell interface
Feb 06 08:00:07 b-drops-1 wancell.sh[3879455]: PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
Feb 06 08:00:07 b-drops-1 wancell.sh[3879455]: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=45.3 ms
Feb 06 08:00:07 b-drops-1 wancell.sh[3879455]: --- 8.8.8.8 ping statistics ---
Feb 06 08:00:07 b-drops-1 wancell.sh[3879455]: 1 packets transmitted, 1 received, 0% packet loss, time 0ms
Feb 06 08:00:07 b-drops-1 wancell.sh[3879455]: rtt min/avg/max/mdev = 45.333/45.333/45.333/0.000 ms
Feb 06 08:00:07 b-drops-1 wancell.sh[3878670]: Interface wwan0 is working well
Observar a última frase do comando Interface wwan0 is working well, que indica que a wancell (wwan0) voltou a se conectar normalmente com a rede da operadora e já disponibilizou acesso à Internet através da Wancell.
Em muitas situações de falha na Wancell, o SIM card aparece em falha (failed) por sim missing para o modem do CPE.
sudo mmcli -m 2
-----------------------------
General | path: /org/freedesktop/ModemManager1/Modem/2
| device id: 142a7d5ffcb734e94e3f0eb0839120ac3e6fd505
-----------------------------
Hardware | manufacturer: QUALCOMM INCORPORATED
| model: QUECTEL Mobile Broadband Module
| firmware revision: EC25AUFAR06A06M4G
| carrier config: default
| h/w revision: 10000
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: 866989051108154
-----------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4
| drivers: qmi_wwan, option
| plugin: quectel
| primary port: cdc-wdm0
| ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (gps),
| ttyUSB2 (at), ttyUSB3 (at), wwan0 (net)
-----------------------------
Status | state: failed
| failed reason: sim-missing
| power state: on
-----------------------------
Modes | supported: allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 2g, 3g; preferred: 3g
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 4g; preferred: 4g
| allowed: 2g, 4g; preferred: 2g
| allowed: 3g, 4g; preferred: 4g
| allowed: 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 2g
| current: allowed: 4g; preferred: none
-----------------------------
Bands | supported: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
| current: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
-----------------------------
IP | supported: ipv4, ipv6, ipv4v6
Nos casos de sim missing, o analista pode tentar resetar o SIM card através de comandos para tentar restabelecer o estado de "reconhecido" do SIM card pelo modem.
¶ Reset do SIM card
Há algumas formas de reset que podem ser aplicadas ao SIM card para tentar sair doestado de " sim missig":
- Reset por mmcli - atua somente no modem
sudo mmcli -m 0 -r
- Reset da da controladora USB - atual no sistema operacional
sudo usb_modeswitch -R -v 2c7c -p 0125
- Reset do SIM card - atua diretamente no SIM card
sudo minicom -D /dev/ttyUSB2
¶ Primeira tentativa - mmcli
Além de resetar o modem, o comando mmcli (modem manager command line interface) permite ainda listar (mmcli -L), desabilitar (mmcli -m 0 -d) e habilitar o modem (mmcli -m 0 -e). Entretanto, para evitar conflitos com o script do serviço wancell que ainda está rodando, vale a pena paralisar o mesmo através do comando
sudo systemctl stop wancell_service.service
Após o comando mmcli -m 0 -d ou mmcli -m 0 -d, o modem entra em estado desabilitado (disable), o que pode ser observado com o resultado do comando mmcli -m L:
mmcli -m 0
----------------------------------
General | path: /org/freedesktop/ModemManager1/Modem/1
| device id: 142a7d5ffcb734e94e3f0eb0839120ac3e6fd505
----------------------------------
Hardware | manufacturer: QUALCOMM INCORPORATED
| model: QUECTEL Mobile Broadband Module
| firmware revision: EC25AUFAR06A06M4G
| carrier config: default
| h/w revision: 10000
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: 866989051108154
----------------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4
| drivers: qmi_wwan, option
| plugin: quectel
| primary port: cdc-wdm0
| ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (gps),
| ttyUSB2 (at), ttyUSB3 (at), wwan0 (net)
----------------------------------
Status | lock: sim-pin2
| unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10)
| state: disabled
| power state: on
----------------------------------
Modes | supported: allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 2g, 3g; preferred: 3g
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 4g; preferred: 4g
| allowed: 2g, 4g; preferred: 2g
| allowed: 3g, 4g; preferred: 4g
| allowed: 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 2g
| current: allowed: 4g; preferred: none
----------------------------------
Bands | supported: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
| current: egsm, dcs, pcs, g850, utran-1, utran-5, utran-8, utran-2,
| eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8,
| eutran-28, eutran-40
----------------------------------
IP | supported: ipv4, ipv6, ipv4v6
----------------------------------
3GPP | imei: 866989051108154
| enabled locks: fixed-dialing
----------------------------------
3GPP EPS | ue mode of operation: csps-2
| initial bearer ip type: ipv4v6
----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0
É importante ressaltar neste ponto que só é possível verificar a qualidade do sinal da operadora móvel celular no modem após habilitar o modem através do comando mmcli -m 0 -e.
Após a execução do comando mmcli -m 0 -r, é conveniente restartar o serviço ModemManager para voltar o ID do modem para zero (0) e eliminar qualquer resíduo de estado no modem.
sudo systemctl restart ModemManager.service
Depois de restartar o serviço ModemMamager, o modem volta a ser reconhecido pelo sistema operacional com o ID zero (0) e assim, pode-se restartar o script da wancell através do comando
sudo systemctl restart wancell_service.service
e monitorar a evolução da conexão com o comando journalctl -f -u wancell_service.service, comop já mostrado anteriormente. Lembrando que o resultado esperado continua sendo Interface wwan0 is working well.
¶ Segunda tentativa - usb_modeswitch
Parar o script do serviço wancell_service.service com o comando.
sudo systemctl stop wancell_service.service
Às vezes o reset pelo comando mmcli é impossível por alguma inconsistência no carregamento do driver do modem no sistema operacional. Nesta condição, existe a possibilidade de reset direto na controladora USB do modem através do comando usb_modeswitch.
Para o modem EC25-AU da Quectel, que é o modelo mais utilizado dentro dos CPEs, o comando para reset é
sudo usb_modeswitch -R -v 2c7c -p 0125
As informações de fabricante 2c7c e modelo 0125 do modem podem ser obtidas através com comando
lsusb
Bus 001 Device 035: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
Da mesma forma que o comando mmcli, depois de aplicado o reset por usb_modeswitch, ainda convém resetar o serviço ModemManager para limpar resíduos e voltar o ID do modem para zero (0) no sistema operacional.
sudo systemctl restart ModemManager.service
O restabelecimento do modem após o reset por usb_modeswitch pode ser confirmado através do comando sudo mmcli -L e mmcli -m <ID>.
Finalmente com os resultados positivos nos passos acima, basta restartar o serviço wancell, atraés do comando
sudo systemctl restart wancell_service.service
¶ Terceira tentativa - minicom
O reset pelo minicom é mais difícil que os doois anteriores porque envolve um acesso via interface serial ao modem.
O acesso serial ao modem pode ser feito através do emulador de terminal minicom, que deve estar presente no CPE. O monicom pode ser instalado seguindo a seguinte sequência de comandos no prompt do CPE.
sudo apt update
sudo apt install minicom
Depois de instalar o terminal serial, caso necessário, o minicom deve ser chamado através do comando
sudo minicom -D /dev/ttyUSB2
Ao abir o aplicativo do minicom, o analista vai ter acesso ao terminal de comandos AT do modem, de acordo com a Figura 11 abaixo.
Figura 11 - Tela inicial do minicom.
A partir do terminal minicom, o analista pode executar os comandos AT para diagnóstico e reset.
Lista de comandos AT importantes:
- ATE - Para ecoar os comandos executados na tela.
É importante iniciar o scrip pelo ATE para poder ver na tela o que está sendo executado.
- AT+QPOWD - Para desligar a energia do SIM card e religar.
Este comando executa uma série de outros comandos AT internamente e é uma espécie de reset "duro" do SIM card.
- AT+CFUN=0 - Para desligar as funções de conexão.
Deve ser executado depois da execução automática de todos os comandos internos que fazem parte do AT+QPOWD.
- AT+CFUN=1 - Para ligar as funções de conexão do modem.
Deve ser executado logo depois do AT+CFUN=0.
O resultado esperado desta sequência é a confirmação de conexão do modem, ressaltado dentro do qudro vermelho da Figura 12.
Figura 12 - Resultado do script de reset do modem/SIM card através do minicom.
- Tecla crtl + A + X - Sair do minicom.
Pressionando a tecla ctrldo teclado + A + X, o analista irá sair do minicom de volta para o prompt do sistema operacional. A partir daí, voltar para a primeira tentativa de reset, via mmcli.