Guia de sobrevivência wi-fi no Linux Mint: do power save ao loop de eventos de driver

Guia de Sobrevivência Wi-Fi no Linux Mint: Do Power Save ao Loop de Eventos de Driver#

Fala, pessoal. Hoje vou compartilhar um guia definitivo sobre como lidar com instabilidades de Wi-Fi no Linux Mint, baseado em perrengues reais que passei na minha própria estação de trabalho. Quando a gente trabalha há anos resolvendo problemas de infraestrutura e suporte N2, entende que rede não é apenas "conectar ou cair" - é uma dança complexa entre hardware, driver, kernel e orquestradores de sistema.

Recentemente, enfrentei dois cenários distintos que quase derrubaram minha produtividade. O primeiro era o clássico desaparecimento da rede, e o segundo era algo muito mais sinistro: uma degradação de performance sistêmica causada por um driver em conflito.

Abaixo, desconstruo as camadas de falha e apresento as soluções forenses necessárias para manter seu sistema estável.

1. O cenário clássico: o desaparecimento da rede#

O problema era direto e irritante: do nada, a rede caía. Não era apenas Wi-Fi; a rede cabeada também ficava "indisponível", e o sistema não listava absolutamente nada até que um reboot fosse realizado.

Onde a rede morria#

Quando a rede some e um restart simples não resolve, eu desconfio da camada mais baixa. Iniciei verificando o estado físico e lógico do rádio via rfkill:

rfkill list

Se o rádio estivesse em Soft block, a solução seria imediata:

sudo rfkill unblock all

No entanto, em muitos chipsets Realtek ou Intel, o culpado é o Wi-Fi Power Save. O NetworkManager coloca a placa em economia de energia e ela falha ao tentar "acordar".

A Solução Definitiva para Power Save: Editei o arquivo /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf e mudei o valor de 3 para 2:

[connection]
wifi.powersave = 2

2. Protocolos de backup e pré-requisitos de sistema#

Antes de fazer alterações em arquivos de configuração de módulos do Kernel ou de orquestradores de rede, é de suma importância realizar backups preventivos dos arquivos envolvidos. Isso garante o restabelecimento imediato das operações no caso de erros sintáticos ou comportamentos indesejados do hardware.

Criando backups de configuração de módulos#

Execute os seguintes comandos no terminal para garantir a segurança dos arquivos antes de realizar qualquer alteração no diretório de modprobe:

# Criar backup individual do arquivo de configuração do driver Realtek
if [ -f /etc/modprobe.d/rtw88.conf ]; then
  sudo cp /etc/modprobe.d/rtw88.conf /root/rtw88.conf.bak.$(date +%Y%m%d)
  echo "Backup de rtw88.conf criado em /root/"
else
  echo "Arquivo /etc/modprobe.d/rtw88.conf não existia previamente."
fi

# Backup preventivo completo de todo o diretório /etc/modprobe.d/
sudo cp -r /etc/modprobe.d/ /root/modprobe-backup-$(date +%Y%m%d)/

# Verificar o estado atual e existência do arquivo
ls -la /etc/modprobe.d/rtw88.conf

Esses backups permitem reverter rapidamente as opções de carregamento de driver caso ocorra alguma incompatibilidade inesperada.

3. Validação detalhada do hardware e do kernel#

Antes de diagnosticar se um driver está defeituoso, é essencial realizar um levantamento de compatibilidade física, lógico-operacional do barramento, estado de firmware e versão do kernel utilizada.

A. Validação do kernel#

As otimizações de drivers Realtek são fortemente atreladas à versão do kernel ativa. O suporte ao rtw88_8822ce foi severamente modificado nas ramificações mais recentes do kernel LTS.

# Verificar a versão ativa do Kernel do Linux
uname -r

# Testar em modo simulação se o módulo está compilado e disponível para o kernel atual
modprobe -n -v rtw88_8822ce 2>&1

# Verificar se há atualizações de pacotes do kernel pendentes no repositório
apt list --upgradable | grep linux-image

# Listar arquivos físicos do driver rtw88 para o kernel atual
ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/rtw88/

B. Validação do hardware#

Tudo começa na comunicação física com o barramento PCI Express. Se a placa Wi-Fi sumir eletricamente do barramento, nenhuma alteração de driver resolverá.

# Localizar adaptador Wi-Fi no barramento PCI
lspci | grep -i -E "network|wireless"

# Consultar status físico e lógico do rádio (rfkill)
rfkill list all

# Verificar se a interface wlp3s0 está configurada no sistema (UP ou DOWN)
ip link show wlp3s0

# Auditar mensagens de erro de hardware ou falha de inicialização no dmesg
dmesg | grep -i "error\|fail" | grep -i "wifi\|wireless\|wlp3s0"

C. Validação de firmware#

Mesmo com o driver carregado, a placa requer blobs de firmware proprietários fornecidos pelo pacote firmware-realtek. Se o firmware falhar ao carregar, a interface de rede falhará ao subir.

# Verificar o carregamento do firmware da placa Wi-Fi no dmesg
dmesg | grep -i firmware | grep -i rtw88

# Validar o pacote de firmware Realtek instalado no Linux Mint
dpkg -l | grep firmware | grep -i realtek

# Verificar se há novas versões de firmware disponíveis para atualização
apt list --upgradable | grep firmware

4. Diagnóstico de driver e pilha de rede#

Quando o hardware está visível e o kernel é compatível, o problema reside na comunicação entre as camadas lógicas: Driver ➔ NetworkManager ➔ wpa_supplicant ➔ D-Bus.

A. Status de carregamento do driver#

Verifique se os módulos do Kernel estão ativos e respondendo na memória volátil:

# Verificar se o módulo rtw88 está ativo e carregado na memória do kernel
lsmod | grep rtw88

# Validar módulos de suporte e sub-sistemas de rede wireless ativos
lsmod | grep -E "rtw88|wlan|cfg80211|mac80211"

# Inspecionar parâmetros disponíveis expostos pelo driver rtw88_8822ce
modinfo rtw88_8822ce | grep -i "parm"

# Auditar dmesg em tempo real buscando por falhas ou timeouts do driver
dmesg | grep -i "rtw88\|wlp3s0" | tail -20

B. Saúde e configuração do networkmanager#

O NetworkManager orquestra os dispositivos de rede baseando-se em arquivos de regras declarativas. Um bug ou loop no NetworkManager pode desconectar a placa repetidamente.

# Verificar o status ativo do serviço orquestrador de rede
systemctl status NetworkManager

# Checar status geral do NetworkManager (conectividade, estado)
nmcli general status

# Verificar o status das interfaces de rede conhecidas
nmcli device status

# Listar conexões ativas registradas
nmcli connection show

# Confirmar se a interface wlp3s0 está de fato no modo "managed" pelo NM
nmcli device status | grep wlp3s0

C. Validação do wpa_supplicant#

O wpa_supplicant é responsável pela criptografia e handshakes Wi-Fi (WPA/WPA2/WPA3). Travamentos nesse daemon causam quedas constantes e loops de autenticação.

# Verificar o status de execução do daemon de autenticação WPA/WPA2
systemctl status wpa_supplicant

# Inspecionar as definições padrão de conexões wpa_supplicant
cat /etc/wpa_supplicant/wpa_supplicant.conf

# Auditar logs recentes do serviço para identificar problemas de autenticação
journalctl -u wpa_supplicant --since "10 minutes ago"

# Buscar padrões de erro específicos nos logs históricos
journalctl -u wpa_supplicant | grep -i -E "fail|error|reject"

D. Saúde do subsistema de comunicação d-bus#

Os daemons NetworkManager e wpa_supplicant utilizam mensagens IPC através do D-Bus. Se o D-Bus for saturado, a interface gráfica inteira começará a responder com lag e quedas de chamadas API.

# Confirmar status operacional do dbus
systemctl status dbus

# Ler logs recentes de comunicação do subsistema D-Bus
journalctl -u dbus --since "10 minutes ago"

# Listar processos com consumo excessivo de conexões ou CPU no D-Bus
ps aux | grep dbus | sort -k3 -rn | head -5

# Verificar se o wpa_supplicant está operando normalmente com o barramento do NetworkManager
busctl tree org.freedesktop.NetworkManager 2>/dev/null | head -10

5. O cenário forense: o loop de eventos e a tempestade de interrupções#

Recentemente, o nível de dificuldade subiu. O sistema (Linux Mint, Kernel 6.8.0-106-generic) apresentava um lag de interface insuportável. O uso de CPU escalava para 95% e o Load Average batia 7.55. O mouse "pulava", e a renderização sofria atrasos visíveis.

O comportamento do kernel#

Ao rodar journalctl -f, identifiquei um flood originado no wpa_supplicant. A interface wlp3s0 (Realtek RTL8822CE) estava gerando eventos de mudança de sinal a cada 100ms.

O log era persistente: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=9999 txrate=58500

O valor de noise=9999 indicava que o driver rtw_8822ce estava enviando informações inconsistentes. Isso gerava um Interrupt Storm (tempestade de interrupções). Através do watch -n1 "cat /proc/interrupts", vi o contador de IRQs da placa subindo freneticamente, resultando em alto I/O Wait e o systemd-journald saturando o disco.

Rastreabilidade de driver#

A falha reside no driver rtw88 (especificamente no módulo rtw88_8822ce), na lógica de LPS (Leisure Power Save) e no Antenna Diversity. O driver tentava alternar entre as antenas físicas para compensar o ruído falso, disparando um callback no wpa_supplicant via nl80211. Esse loop saturava o dbus-daemon, quebrando outros serviços de interface.

Silenciando o overhead#

1. Parâmetros de Módulo (Persistence): Forcei a desativação do gerenciamento de energia profundo e travei a seleção de antena no arquivo /etc/modprobe.d/rtw88.conf:

   options rtw88_core disable_lps_deep=y
   options rtw88_8822ce disable_lps_deep=y ant_sel=1

1. Redução de Verbosidade: Alterei o ExecStart do serviço do wpa_supplicant para redirecionar o log para um arquivo isolado (como /var/log/wpa_supplicant.log) e ativei a flag -q (quiet):

   ExecStart=/usr/sbin/wpa_supplicant -u -s -O "DIR=/run/wpa_supplicant GROUP=netdev" -f /var/log/wpa_supplicant.log -t -q

1. Limpeza de Race Condition: Matei o processo crashpad_handler (PID 8100) que havia entrado em condição de corrida devido aos micro-travamentos, liberando 23% de CPU instantaneamente.

Resultado final: O Load Average caiu de 7.55 para 0.58. Sistema fluido e estável.

6. Auditoria forense de interrupções e validação pós-fix#

Após a aplicação dos fixes descritos nas seções anteriores, é obrigatório auditar se a tempestade de interrupções (Interrupt Storm) cessou e se os novos parâmetros foram aplicados de forma persistente no Kernel.

A. Monitoramento das interrupções de hardware (irqs)#

Para verificar se as interrupções de hardware estabilizaram e se a placa parou de floodar o kernel, execute as auditorias abaixo:

# Verificar as interrupções de hardware registradas para a interface
cat /proc/interrupts | grep -i wlp3s0

# Monitorar variações de interrupções em tempo real (observe se o valor aumenta bruscamente)
watch -n1 "cat /proc/interrupts | grep -i wlp3s0"

# Executar loop de teste rápido para registrar taxa de subida de IRQs por segundo
for i in 1 2 3; do
    cat /proc/interrupts | grep wlp3s0 | awk '{print $2}'
    sleep 1
done

# Verificar se há gargalos no uso do CPU devido a I/O (I/O wait)
iostat -x 1 5

B. Validação da persistência dos parâmetros pós-recarregamento#

Não basta reiniciar o computador. Devemos auditar se os parâmetros de módulo customizados foram interpretados corretamente pelo kernel em runtime.

# Confirmar que o driver foi recarregado corretamente na memória
lsmod | grep rtw88

# Validar se os parâmetros passados em /etc/modprobe.d foram lidos com sucesso
cat /sys/module/rtw88_core/parameters/disable_lps_deep
cat /sys/module/rtw88_8822ce/parameters/ant_sel

# Testar conectividade de rede básica
ping -c 5 8.8.8.8

# Validar se a carga média do sistema (Load Average) normalizou
uptime

Se disable_lps_deep retornar Y (ou 1) e ant_sel retornar 1 (ou o valor travado), e as interrupções pararem de subir bruscamente durante o tráfego, o bug de loop de eventos foi corrigido com sucesso.

7. Tabela operacional de recuperação (no-reboot protocol)#

Se o Wi-Fi cair ou o sistema começar a travar, siga este fluxo antes de pensar em reiniciar:

8. Checklist de troubleshooting wi-fi (Linux Mint)#

Utilize o checklist operacional abaixo para triagem e correção de anomalias de conexões sem fio:

1. Diagnóstico inicial#

• [ ] Executar rfkill list para auditar possíveis bloqueios de hardware/software no rádio.
• [ ] Verificar se a interface física está presente e ativa através do comando ip link show.
• [ ] Confirmar integridade do serviço orquestrador: systemctl status NetworkManager.
• [ ] Iniciar escuta dos logs do sistema em background com journalctl -f ou tail -f /var/log/syslog.

2. Tratamento de power save (economia de energia)#

• [ ] Verificar arquivo /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf.
• [ ] Mudar valor configurado de 3 (habilitado) para 2 (desabilitado).
• [ ] Reiniciar o NetworkManager com sudo systemctl restart NetworkManager.

3. Ajuste de parâmetros do driver#

• [ ] Confirmar o módulo carregado usando o comando lsmod | grep rtw88.
• [ ] Mapear as opções do driver executando modinfo rtw88_8822ce.
• [ ] Criar o arquivo de configurações /etc/modprobe.d/rtw88.conf com as flags de desativação do LPS e seleção de antena.
• [ ] Descarregar e carregar o módulo do kernel de forma limpa:

  sudo modprobe -r rtw88_8822ce && sudo modprobe rtw88_8822ce

4. Resolução de tempestade de interrupções (interrupt storm)#

• [ ] Monitorar a taxa de escalada de interrupções por segundo: watch -n1 "cat /proc/interrupts | grep wlp3s0".
• [ ] Verificar overhead no processamento e estado de I/O Wait utilizando o comando iostat -x 1 5.
• [ ] Matar processos zumbis ou com condição de corrida que saturam a CPU (ex: crashpad_handler).

5. Validação pós-procedimento#

• [ ] Realizar teste de conectividade externo: ping -c 5 8.8.8.8.
• [ ] Auditar load average geral da máquina: uptime.
• [ ] Monitorar a estabilidade da taxa de transferência de dados e oscilações do sinal por um período de 24 horas.

9. Matriz de relação de problemas identificados#

A matriz a seguir consolida os riscos, severidades e as mitigações diretas documentadas neste guia:

Considerações práticas#

No Linux, problemas de rede raramente são binários. Eles exigem uma análise por camadas - do rfkill ao barramento PCI, passando pelo gerenciamento de energia. Hardware e driver às vezes brigam, mas com as ferramentas de infraestrutura corretas, dá para colocar os dois para conversar sem precisar de um reboot.

Veja também

Infraestrutura Anatomia de um deadlock silencioso no CloudLinux e cPanel: processos fantasmas, travas de sessão e filas TCP

Infraestrutura Anatomia do crontab, comportamento do kernel e manutenção do spool de e-mails no Exim

Infraestrutura Do LSM ao netfilter na OCI: desmistificando selinux e liberando portas no Ubuntu minimal 24.04

Este post está licenciado sob CC BY-NC.