☰

WPA_CLI mostrando o ponto de acesso como conectado quando não deveria

tag-icon • tag-icon networking wifi wpa-supplicant 802.1x wpa-cli
WPA_CLI mostrando o ponto de acesso como conectado quando não deveria

Estou usando o kernel Linux 3.3 e estou tentando usar o wpa_cliutilitário para monitorar o status da minha conexão WiFi. Estou usando um dongle WiFi da Edimax para conectar-me a um ponto de acesso sem fio.

Normalmente vejo algo assim:

# wpa_cli status
Selected interface 'wlan0'
wpa_state=SCANNING
ip_address=XXX.XXX.XXX.XXX
address=XX:XX:XX:XX:XX:XX

Ou a mesma coisa, mas com wpa_state=COMPLETED.

A análise desta saída de texto me permite ver se minha conexão sem fio está ativa ou escaneando. No entanto, notei que depois de desligar meu ponto de acesso wpa_state=COMPLETEDainda está sendo retornado. Usando o comando:

# iwlist wlan0 scanning

Força uma varredura e wpa_stateestará correto.

Força uma varredura e wpa_stateocasionalmente estará correto, mas geralmente não.

Estou me perguntando se tenho uma configuração incorreta em algum lugar ou se existe uma maneira mais eficiente de fazer isso (essencialmente, só quero ver se minha interface tem uma conexão ativa ou não). Aqui está /etc/wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
country=US


network={
    ssid="myssid"
    psk="mypsk"
    key_mgmt=WPA-PSK
    eap=
}

Eu preferiria não forçar uma varredura todas as vezes, mas deixar os módulos do driver/kernel cuidarem disso. Esta é a primeira vez que trabalho com WiFi no Linux, então acho que provavelmente configurei algo incorretamente. Alguém pode me apontar na direção certa?

Atualizar:

Após alguma investigação mais aprofundada, acredito que algo estranho está acontecendo, fazendo com que o kernel retorne uma versão em cache da lista de APs. Estou usando o RTL8192cudriver, então comecei a depurar isso. Acho que meu problema pode estar relacionado aesse, mas não é exatamente o mesmo bug que tenho um kernel mais recente que o kernel 2.6 usado lá.

Atualização 2:

Minha crença é que o problema pode estar em algum lugar do kernel. No arquivo net/mac80211/scan.c, na linha 214 da função ieee80211_scan_rx, vejo um bssiddo BSSmeu AP aparecer (quando o AP está ligado) e ser colocado via ieee80211_rx_bss_put(aqui). Neste ponto, ele é retornado nos resultados da verificação e wpa_supplicantfaz com que a MLMEcamada no kernel se autentique e se conecte a esse AP. No entanto, depois de desconectar a alimentação do AP, nunca vejo a MLMEcamada desistir atomic_tde mantê-la BSS. Isso faz com BSSque nunca seja desvinculado da função cfg80211_bss_expireao final de uma varredura ( cfg80211_wext_giwscan), no arquivo net/wireless/scan.c, linha 205 (aqui).

Há alguma configuração com wpa_supplicant que preciso adicionar para que a MLMEcamada diminua BSS, ou isso é claramente um bug do kernel?

Eu já tentei:

# wpa_cli bss_expire_age 10
# wpa_cli bss_expire_count 2

e não resolveu meu problema.

Responder1

Então, depois de muita pesquisa, descobri que o problema era por causa do rtlwifidriver do kernel. Para mim, parece que o rtl8192cudriver deveria ser responsável por lidar com beacons perdidos, chamando a função ieee80211_beacon_loss, mas essa chamada não foi encontrada em lugar nenhum. Removi o suporte IEEE80211_HW_BEACON_FILTERno rtlwifidriver e o problema foi corrigido.

Essecorreçãosão essencialmente as mesmas alterações que fiz, e os comentários nestearquivosão parte do que me levou a esta resposta.

informação relacionada