¶ INSTRUÇÃO DE TRABALHO 1
¶ 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 dos gateways de nuvem. Como mostrado na Figura 1, os gateways de nuvem fazem parte da camada 2 da plataforma Telcoweb e estão hospedados na nuvem, como a nuvem AWS de são Paulo.
O acesso a cada 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 dos seguintes comandos.
Para o cliente Loungerie
ssh faiston@gateway3.telcoweb.co
Para os demais clientes
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 5 mostra graficamente o prompt de comando do gateway da Faiston.
Figura 5 – 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.
- WAN1 → interface física
enp1s0, associada ao namespacens-wan1 - WAN2 → interface física
enp2s0, associada ao namespacens-wan2
¶ Cenário 1 — Modem DOWN / Status DOWN
Indica falha física. Prováveis 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 a WAN1 com falha física e falha fim-a-fim de Internet.
Na figura 5 é possível observar que tanto a conexão do CPE TW-EZ1 com o modem do provedor (física), quanto a conexão fim-a-fim com a Internet (lógica), estão alarmadas a partir da WAN1. Isso indica que a 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. Como consequência, a informação de Status — que se refere à capacidade do CPE de se comunicar com a Internet — também cai para DOWN.
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 enviar fotos dos LEDs de conexão do CPE e do modem pode facilitar muito o diagnóstico e as ações de reparo.
¶ Passo 1 — Verificar o estado da interface
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 acima, destacando 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.
¶ Passo 2 — Reiniciar a interface física (down/up)
Antes de acionar o provedor, vale tentar reiniciar a interface física do CPE — em alguns casos isso é suficiente para renegociar o link com o modem:
Para a WAN1:
sudo ip netns exec ns-wan1 ifconfig enp1s0 down
sudo ip netns exec ns-wan1 ifconfig enp1s0 up
Para a WAN2, o procedimento é o mesmo, substituindo o namespace e a interface:
sudo ip netns exec ns-wan2 ifconfig enp2s0 down
sudo ip netns exec ns-wan2 ifconfig enp2s0 up
Após subir a interface novamente, confirme o estado com o comando do Passo 1. Se a interface continuar em DOWN, o problema é físico (cabo ou modem) e deve seguir para vistoria local ou chamado ao provedor.
¶ Passo 3 — Requisitar endereçamento IP via DHCP
Se a interface subir (UP) mas ainda não tiver endereço IP, tente requisitar a configuração via DHCP:
Para a WAN1:
sudo ip netns exec ns-wan1 udhcpc -i enp1s0 -b
Para a WAN2:
sudo ip netns exec ns-wan2 udhcpc -i enp2s0 -b
¶ Passo 4 — Verificar o serviço SDWAN
Acompanhe o log do serviço para confirmar se a WAN foi reconhecida e reestabelecida corretamente:
journalctl -f -u sdwan_service.service
¶ Passo 5 — Verificar o IP recebido e testar o gateway
Confira qual endereço IP a interface recebeu do DHCP:
sudo ip netns exec ns-wan1 ip a
Com o IP recebido, teste a conectividade com o gateway do provedor (o primeiro endereço da faixa, geralmente .1, mas confirme pela máscara/rede recebida). Exemplo:
sudo ip netns exec ns-wan1 ping 192.168.x.x
Substitua
192.168.x.xpelo IP real do gateway, com base na faixa de rede que a interface recebeu no Passo 3.
Se o ping para o gateway falhar, o problema é físico ou está na primeira milha (cabo/modem). Se o ping para o gateway funcionar mas o CPE não navegar na Internet, avance para o Cenário 2 abaixo.
¶ Cenário 2 — Modem UP / Status DOWN
Figura 7 - Tela do portal Telcoweb, mostrando o estado Up/Down.
Este cenário é mais complexo e requer uma análise mais detalhada por parte do analista. A causa mais comum é:
- Rompimento de fibra óptica na rede de acesso do provedor — principalmente quando a fibra chega ao modem do provedor por via aérea (postes).
A forma mais fácil de confirmar esse diagnóstico é observar o alarme de LOS (Loss of Signal) no modem, 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 óptica com a rede e, portanto, não há conexão com a Internet. Havendo alguém no local, vale pedir para desligar e religar o modem do provedor após alguns segundos e observar se o alarme desaparece. Se não desaparecer, a única opção é abrir um chamado de reparo com o provedor.
¶ Confirmando a falha pelo CPE
Do ponto de vista do CPE, uma falha na rede óptica pode ser rapidamente comprovada testando a conectividade com o próprio modem via ping. Exemplo com a WAN2:
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.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6107ms
Observe que o primeiro ping, direcionado ao IP da interface do modem diretamente conectada à WAN2 do CPE, retornou OK — o que indica que o modem está conectado fisicamente e respondendo corretamente. Já o segundo ping, para a Internet (8.8.8.8), retornou 100% de perda — 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).
¶ Diagnóstico inicial
Ao receber uma solicitação de suporte do N1, o analista N2 deve verificar primeiro o estado físico do SIM card no CPE. Essa verificação pode ser feita com dois comandos.
¶ 1. Identificar o modem
mmcli -L
Exemplo de retorno:
mmcli -L
/org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] QUECTEL Mobile Broadband Module
O comando mmcli -L mostra o ID atribuído ao modem pelo sistema operacional do CPE. Neste exemplo, o ID é 0.
¶ 2. Consultar o estado do modem
mmcli -m 0
Exemplo de retorno (modem operando normalmente):
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)
----------------------------------
3GPP | imei: 866989050119798
| enabled locks: fixed-dialing
| operator id: 72410
| operator name: VIVO
| registration: home
----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/1
----------------------------------
Bearer | paths: /org/freedesktop/ModemManager1/Bearer/3
Pontos a observar no retorno:
- signal quality: acima de 80% é considerado ótimo. No exemplo, 97%.
- state: deve estar como
registered— significa que a rede da operadora reconhece o SIM card como parte normal da rede. - operator name / operator id: confirma em qual operadora o chip está registrado, via código PLMN.
¶ Tabela de PLMN (Public Land Mobile Network) — operadoras do Brasil
O PLMN identifica a rede da operadora móvel celular.
| Operadora | Códigos PLMN |
|---|---|
| Vivo | 72410, 72411, 72406 |
| Claro | 72405, 72438 |
| TIM | 72402, 72403, 72404 |
¶ Se o SIM está registered: reiniciar o serviço WAN Cell
Se o estado do SIM card estiver registered, o analista deve reiniciar o serviço WAN Cell e acompanhar o script de conexão.
Reiniciar o serviço:
sudo systemctl restart wancell_service.service
Acompanhar o script de conexão em tempo real:
journalctl -f -u wancell_service.service
Exemplo de saída esperada (conexão bem-sucedida):
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
A linha final Interface wwan0 is working well confirma que a WAN Cell (wwan0) voltou a se conectar normalmente com a rede da operadora e já disponibiliza acesso à Internet.
¶ Se o SIM aparece como failed (sim-missing)
Em muitas situações de falha na WAN Cell, o SIM card aparece em falha (failed) por sim-missing no 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
-----------------------------
Nesses casos, o analista pode tentar resetar o SIM card através de três métodos, em ordem crescente de complexidade, para tentar restabelecer o estado de "reconhecido" pelo modem:
| Nível | Método | Atua em |
|---|---|---|
| 1 | mmcli |
Somente no modem (software) |
| 2 | usb_modeswitch |
Controladora USB (sistema operacional) |
| 3 | minicom |
Diretamente no SIM card (via porta serial) |
A recomendação é seguir essa ordem: só avançar para o método seguinte se o anterior não resolver.
¶ Verificação preliminar: atualização do sistema
Antes de iniciar os resets, vale verificar se o sistema operacional do CPE está com os pacotes atualizados. Tecnologia desatualizada (drivers, firmware do ModemManager, pacotes do sistema) pode ser a causa raiz de falhas de reconhecimento do SIM card ou instabilidade da WAN Cell.
sudo apt-get update
sudo apt-get upgrade
Atenção: o
apt-get upgradepode reiniciar serviços do sistema. Se possível, execute essa verificação em horário de menor impacto e, após concluir, confirme se o serviço WAN Cell voltou a subir normalmente antes de prosseguir com os métodos de reset abaixo.
¶ Reset do SIM card
Há algumas formas de reset que podem ser aplicadas ao SIM card para tentar sair do estado 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 dois 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 minicom 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.
¶ Reinicialização do CPE (em caso de travamento do minicom)
Se o minicom travar e nenhum dos três métodos de reset acima restabelecer o modem, é necessário reiniciar o CPE.
Antes de reiniciar, verifique se a data e a hora do sistema estão sincronizadas:
date
sudo hwclock
Compare os dois resultados. Se as datas e horários estiverem sincronizados, prossiga com a reinicialização.
Desabilite temporariamente o serviço WAN Cell (evita tentativas de conexão durante o boot):
sudo systemctl disable wancell_service.service
Reinicie o equipamento:
sudo reboot
Após o CPE concluir a inicialização, habilite novamente o serviço WAN Cell:
sudo systemctl enable wancell_service.service
Confirme que a WAN Cell voltou a conectar acompanhando o log:
journalctl -f -u wancell_service.service