Resumo executivo
Contexto
A expedição e o recebimento trabalham com coletores de dados Android, de mais de um modelo, ligados ao sistema de gestão de armazém (WMS) por sessões de terminal. Os coletores usam uma rede Wi-Fi própria, em uma VLAN dedicada, servida por dezenas de access points gerenciados por uma controladora central. Parte das antenas atende áreas abertas e galpões, onde o operador anda o tempo todo entre os pontos de coleta.
Problema
Os operadores relatavam que o coletor “caía” no meio da separação e era preciso logar de novo. O relatório que montei com os dados da controladora mostrou o tamanho do problema: milhares de quedas em 30 dias, concentradas em dezenas de coletores. Cada queda interrompe a operação e gera retrabalho.
Meu papel
- medir o problema antes de mexer em qualquer coisa, com um monitor automático de quedas;
- levantar e testar as hipóteses em cada camada (rádio, roaming, aparelho, sessão, cobertura);
- correlacionar controladora Wi-Fi, logs do servidor de sessões e capturas de pacotes;
- aplicar as correções em rodadas, com estado anterior e rollback registrados;
- separar o que era rede do que era aparelho e encaminhar cada causa para quem resolve.
Resultado
- As quedas diárias dos coletores foram reduzidas em 90% na medição de acompanhamento, o que encerrou o caso.
- Seis frentes de investigação registradas, com estados diferentes e evidências correspondentes.
- Na primeira janela de operação plena após as correções, as desconexões por hora caíram para cerca de metade (amostra curta; a medição de vários dias seguia em andamento).
- Nesse recorte, a mediana do sinal no momento da queda passou a ser de sinal bom, ou seja, as quedas restantes já não eram de sinal fraco.
- A captura de pacotes mostra um modelo de coletor abrindo nova conexão sem encerrar a anterior. A confirmação depende dos logs do aplicativo e do sistema do aparelho.
- Um defeito encontrado no próprio monitor (campo de sinal gravado como relação sinal-ruído, não dBm) foi corrigido antes de usar o dado.
Conclusão
As correções em rodadas, medidas pelo monitor de quedas ao longo dos dias seguintes, reduziram as quedas diárias dos coletores em 90% em relação à linha de base. Com a operação estável, o caso foi encerrado. A principal lição é que um sintoma com várias causas só se resolve medindo antes, mudando por etapas e medindo de novo.
O que este caso demonstra
- Troubleshooting orientado por hipóteses
- Wi-Fi corporativo: canais, potência, roaming
- Análise de pacotes TCP
- Correlação de várias fontes de log
- Mudança controlada com rollback
- Automação com Python
Detalhes técnicos
Roteiro da investigação
- Sintoma
- Linha de base
- Hipóteses
- Fontes de evidência
- Descarte
- Estado das frentes
- Correção em rodadas
- Medição
Sintoma
- Coletor perde a sessão com o WMS e o operador precisa logar de novo.
- Quedas espalhadas por várias áreas, com concentração na expedição (metade do total) e no recebimento.
- Uma única antena concentrava parcela desproporcional das quedas, mesmo com sinal bom.
Hipóteses levantadas e estado por frente
- Interferência e canais repetidos em 5 GHz.
- Roaming instável entre antenas vizinhas (potência desigual, 802.11r).
- Antena expulsando o coletor por RSSI mínimo.
- Coletor alternando entre 2,4 e 5 GHz.
- Renovação de chave (rekey) ou de endereço (DHCP) derrubando a sessão em intervalo fixo.
- Aplicativo ou Android do coletor reabrindo a sessão sozinho.
- Falta de cobertura em pontos de parada do recebimento.
- Servidor de sessões encerrando conexões ativas.
Fontes de evidência
- Controladora Wi-Fi: histórico de sessões de várias semanas, log de cada cliente (trocas de antena, sinal, banda) e leitura de rádio por antena (potência real, uso do canal, retransmissões).
- Monitor de quedas próprio: script Python que consulta a controladora a cada 60 s e grava queda, reconexão, antena e duração em CSV.
- Servidor de sessões (Linux): log de início e fim de cada sessão de terminal e contadores TCP do kernel.
- Captura de pacotes no servidor, filtrada pelos coletores de um dos modelos.
- Relato da operação por turno, para separar deslocamento normal de falha.
Hipóteses e estado da investigação
| Hipótese | Evidência consultada | Conclusão |
|---|---|---|
| Rekey derrubando a sessão a cada ~48 min | Renovação de chave de grupo desligada no SSID dos coletores. | Descartada |
| Servidor encerrando sessões ativas | Uma sessão por coletor, sem sessões fantasma; nas capturas, o servidor só fecha a sessão antiga depois que o coletor abre a nova. | Descartada |
| Quedas de ~48 min derrubando o terminal | Poucas sessões duraram 40–50 min, sem pico: o keepalive do servidor (tolerância de alguns minutos) segurava a sessão. | Descartada para o servidor; segue no Wi-Fi |
| Roaming instável entre duas antenas vizinhas | Centenas de trocas de ida e volta em menos de 2 min, em poucos dias, com sinal bom antes da troca; potência de uma antena no máximo ao lado de outra no mínimo; 802.11r ligado. | Confirmada |
| Alternância entre 2,4 e 5 GHz | Log do cliente: coletor saía de −42 dBm em 2,4 GHz para −67/−77 dBm em 5 GHz e voltava; uma antena externa em potência máxima atraía coletores da expedição. | Confirmada |
| RSSI mínimo expulsando o coletor | Limite acima do sinal de trabalho dos coletores. | Confirmada |
| Aplicativo do coletor iniciando nova conexão | Proporção bem maior de sessões curtas em um modelo do que no outro; captura mostra nova conexão após intervalo sem dados pendentes, sem retransmissões no intervalo observado. | Indício; logs do app/Android necessários |
| Temporizador de ~48–55 min em aparelhos específicos | Um subconjunto de aparelhos do mesmo lote concentra o padrão, inclusive em antenas com sinal ótimo; um deles caía a cada ~55 min “como um relógio”. | Provável (lease DHCP em verificação) |
| Falta de cobertura no recebimento | Em um corredor, quase todas as quedas com sinal fraco; antenas em potência alta ouvidas de longe pelo coletor, de potência menor, que não é ouvido de volta. | Evidência de cobertura insuficiente |
Achados e decisões técnicas
Potência assimétrica
Antena em potência máxima é ouvida pelo coletor de longe, mas não ouve o coletor de volta. O coletor se associa a ela, perde o enlace de subida e troca de novo. A regra adotada: potência da antena próxima à do cliente, e nunca máxima em ambiente interno.
802.11r desligado no SSID dos coletores
Fast roaming costuma falhar em Android antigo. Como a frota não tinha suporte confirmado, desliguei e deixei a religação condicionada ao levantamento de modelo e versão do Android de cada aparelho.
SSID dos coletores só em 2,4 GHz
Era a configuração anterior, até passar a usar as duas bandas sem registro de mudança. Voltar a uma banda acabou com o vai-e-volta; o custo é dividir o canal de 2,4 GHz com os outros SSIDs, o que passou a ser acompanhado por antena.
RSSI mínimo desligado, e não −80 dBm
Sem 5 GHz como alternativa, cada expulsão pode virar reassociação. A captura mostra nova conexão iniciada pelo coletor, mas os logs do app/Android são necessários para atribuir a decisão ao aplicativo. O plano original previa −80 dBm; decidi desligar até medir o efeito com a operação cheia.
Potência média, e não mínima, na antena mais carregada
Com uma única banda, potência mínima poderia abrir buraco de cobertura. A potência intermediária iguala a antena vizinha e fica próxima da potência do coletor.
Canais de 5 GHz a 20 MHz, fora do bloco congestionado
Várias antenas vizinhas estavam no mesmo canal de 40 MHz. Parte delas foi movida para canais distintos de 20 MHz.
Correções por fases
- Linha de baseRelatório de 30 dias da controladora e monitor de quedas rodando antes de qualquer alteração.
- Rodada 1: rádio da expedição802.11r desligado; potência equalizada nas antenas vizinhas; antenas retiradas do canal compartilhado; reinício de um equipamento com consumo de recursos elevado após longo período ligado.
- Rodada 2: banda únicaSSID dos coletores só em 2,4 GHz, 802.11v desligado e potência reduzida na antena externa que atraía coletores.
- Rodada 3: RSSI mínimoLimite retirado nas antenas afetadas, uma por vez, conferindo a tela antes de aplicar.
- Isolamento do aparelhoCaptura de pacotes dos coletores de um modelo para registrar que o coletor iniciou nova conexão; logs do app/Android ainda são necessários.
- CoberturaReforço de cobertura planejado nos pontos de parada.
- Medição contínuaMonitor de quedas, uso de canal e retransmissões por antena acompanhados ao longo dos dias seguintes.
Limitações
- As alterações de rádio da rodada 1 foram aplicadas juntas e com a operação rodando, por decisão do responsável; o efeito de cada uma não pode ser separado, só o do conjunto.
- As amostras logo após as correções eram curtas (troca de turno e uma hora de operação cheia); a medição de vários dias que veio depois confirmou a redução de 90% nas quedas diárias.
- A causa no aparelho (aplicativo de terminal ou Android) depende de teste de configuração com o fornecedor dos coletores.
- A hipótese de lease DHCP para o padrão de ~48 min ainda não foi confirmada.
- Nomes de antenas, endereços, VLANs reais, modelos de equipamento e identificadores dos coletores não são publicados.
Evidências
Nomes de antenas, endereços IP e MAC, VLANs, hostnames e modelos dos coletores foram substituídos por descrições genéricas ou marcadores (modelo A, modelo B, P1, P2). Contagens, datas e horários foram omitidos ou aproximados; o formato das linhas foi simplificado.
Código público e validação automatizada do monitor
O repositório do monitor ↗ (abre em nova aba) publica a implementação, a demonstração sem controladora e os testes. A suíte tem 177 testes, incluindo TLS seguro por padrão, e roda no GitHub Actions em Python 3.10, 3.11, 3.12 e 3.13 (versão de 23/10/2026, commit 963d838).
O resultado de cada execução está nas execuções do workflow ↗ (abre em nova aba). Os testes simulam a API da controladora; as métricas de produção são as desta página.
Matriz de achados
| Achado | Evidência | Prioridade | Ação | Status |
|---|---|---|---|---|
| Roaming de ida e volta entre duas antenas | Centenas de trocas de ida e volta em poucos dias, com sinal bom | Alta | Equalizar potência, desligar 802.11r, mudar canais | Corrigido |
| Coletor alternando entre bandas | Trocas de −42 dBm (2,4 GHz) para −77 dBm (5 GHz) | Alta | SSID dos coletores em banda única | Corrigido |
| RSSI mínimo acima do sinal de trabalho | Limite acima do sinal de trabalho dos coletores | Alta | Retirar o limite nas antenas afetadas, uma por vez | Corrigido |
| Equipamento com consumo de recursos elevado após longo período ligado | Desassociava clientes | Média | Reiniciado e acompanhado | Corrigido |
| Aplicativo do modelo A inicia nova conexão | Proporção maior de sessões curtas; captura mostra nova conexão sem retransmissões no intervalo observado | Alta | Comparar configuração do app e do Android com o modelo B | Indício; logs necessários |
| Ciclo de ~48–55 min em aparelhos do modelo B | Um subconjunto de aparelhos concentra o padrão, inclusive com sinal ótimo | Média | Conferir lease DHCP da rede dos coletores | Em verificação |
| Corredor do recebimento sem cobertura | Quase todas as quedas com sinal fraco | Alta | Reforço de cobertura planejado nos pontos de parada | Planejado |
| Divergência de horário entre as fontes de log | Distorcia a correlação com a controladora | Baixa | Alinhar os horários na análise | Corrigido na análise |
| Mudanças de rádio sem registro | Prints antigos divergiam da configuração encontrada | Média | Passou a ser registrada toda mudança de rádio | Adotado |
Captura do coletor modelo A (reconstrução sintética)
# hora origem → destino flags leitura 13:39:31.964 servidor → coletor:P1 [P.] tela entregue (370 bytes) 13:39:31.967 coletor → servidor [.] coletor confirma em 3 ms # 20,8 s de silêncio, nenhuma retransmissão, nenhum FIN ou RST 13:39:52.749 coletor:P2 → servidor:23 [S] coletor abre conexão NOVA 13:39:52.790 servidor → coletor:P1 [F.] servidor fecha a sessão órfã # timestamp TCP do coletor avançou 20.785 ms em 20,785 s # controladora sem evento de roaming desse cliente no intervalo
O que esta evidência sugere
O coletor abre uma nova conexão sem encerrar a anterior, sem retransmissões e sem evento de roaming no intervalo. A reconexão parte do próprio coletor; os logs do aplicativo e do Android vão mostrar se a decisão é do app ou do sistema.
Antes e depois (amostras)
| Métrica | Variação |
|---|---|
| Quedas diárias (acompanhamento final) | −90% |
| Desconexões por hora (primeira janela de operação plena) | Cerca de −48% |
| Trocas de antena em 5 GHz | Eliminadas |
| Mediana do sinal na queda | De sinal fraco/médio para sinal bom |
As trocas de ida e volta aumentaram depois da banda única, sem gerar queda: indicam células sobrepostas com força parecida, que entram na decisão de equalizar a potência do recebimento.
Versão didática
Como eu ensinaria este conceito
O caso mostra que um mesmo sintoma pode ter várias causas ao mesmo tempo, e que consertar a primeira não prova que o problema acabou. A turma aprende a medir antes, mudar uma coisa e medir de novo.
Público
Ensino Médio técnico, cursos de redes e suporte e formação de professores de Computação.
Pré-requisitos
Noção de Wi-Fi, antena e sinal; ler uma tabela simples.
Analogia
Uma conversa num pátio barulhento: se um fala gritando e o outro sussurra, só um lado entende. Antena com potência máxima é quem grita.
Experimento mínimo
Com o celular e um app de análise de Wi-Fi, a turma mede o sinal em pontos da escola, marca no mapa onde “cai” e propõe onde mudar a antena. Depois compara com uma segunda medição.
Erro comum
Achar que sinal forte no celular garante conexão estável, ou mudar várias configurações de uma vez e não saber qual resolveu.
Pergunta de reflexão
Se o problema some depois de uma mudança, como ter certeza de que foi ela? O que mais mudou no mesmo dia?
O laboratório A Rede Parou usa o mesmo método de investigação com registros fictícios de uma escola.