“suplicante wpa: Nenhuma configuração de rede encontrada para o AP atual” - adaptador wi-fi carl9170-driven glitching no Debian 7

Question

Eu tenho uma máquina Debian 7 com kernel Linux3.2 e um adaptador wifi USB com chipset Atheros (D-Link DWA-16 Xtreme N Dual Band), que em teoria deve funcionar .

De fato, consegui estabelecer uma comunicação wifi com o NetworkManager e ele funcionou mais ou menos bem por ~ 30 minutos, mas depois desconectou e não conseguiu restabelecer a conexão.

Não consegui restabelecer a conexão com o NetworkManager, ele associa e autentica com êxito, inicia o handshake de 4 vias, mas depois des-autentica devido a razão 15 (tempo limite de handshake de 4 vias) .

Depois tentei fazer o mesmo com o bom e velho ifupdown criando uma entrada em /etc/network/interfaces :

allow-hotplug wlan1
iface wlan1 inet static
       wpa-ssid MyNet
       wpa-psk <My key hash generated by 'wpa_passphrase MyNet key'>
       address 192.168.1.2
       netmask 255.255.255.0
       broadcast 192.168.1.255
       gateway 192.168.1.1
       dns-nameservers a.b.c.d

Quando eu sudo ifup wlan1 , ele se comporta razoavelmente, até:

wpa_supplicant[8258]: wlan1: Associated with <router's MAC>
wpa_supplicant[3402]: wlan1: No network configuration found for the current AP

(de /var/log/syslog ). Wireshark vê pacotes ARP indo do meu adaptador wifi para o roteador, mas o roteador não responde.

Você tem alguma idéia sobre o que isso pode significar e como solucionar isso?

SOLUÇÃO: Graças à sugestão da peterph, tentei criar wpa_supplicant.conf e executar wpa_supplicant como um programa independente em primeiro e segundo plano e depois usei wpa-conf wpa_supplicant.conf em /etc/network/interfaces .

sudo wpa_supplicant -iwlan1 -c/etc/wpa_supplicant/wpa_supplicant.conf -d
sudo wpa_supplicant -iwlan1 -c/etc/wpa_supplicant/wpa_supplicant.conf -B

Eu tive a primeira parte dos problemas (com a desconexão espontânea após "status: associated") desaparecer, quando eu matei uma instância em execução de NetworkManager . Parece ter interferido.

A segunda parte do problema foi com o handshake de 4 vias falhando. Ele passou ok, quando eu desabilitei a filtragem de endereço MAC no Access Point. O MAC da minha interface wifi estava na lista de MACs disponíveis, mas por algum motivo ainda não estava conseguindo se conectar com a filtragem MAC no roteador.

UPDATE 2: Os problemas estão de volta. O handshake de 4 vias está falhando novamente. Recarregar o driver não ajudará.

    

Answer 1

Esse tipo de problema é melhor dividido em partes independentes. Neste caso, contornando ifupdown completamente e fazendo todos os passos manualmente - isto é:

1. execute wpa_supplicant com um arquivo de configuração apropriado

2. uma vez estabelecida a conexão, executando o dhcp client,

Para verificar como ifupdown é executado wpa_supplicant - ele precisa passar algum tipo de configuração em um arquivo, que você poderia interceptar - verifique a saída de ps fax | grep wpa_supplicant quando ifupdown estiver em execução - o parâmetro do -c option é o nome do arquivo de configuração (provavelmente gerado instantaneamente).

Se você decidiu mudar de ifupdown por algum motivo, talvez esteja interessado em wicd , que consiste em um daemon controlado por várias UIs (ncurses, GTK, Qt).

A propósito, alguns clientes DHCP são capazes de configurar a conexão sem fio gerando wpa_supplicant por conta própria (eu vi dhcpcd fazendo isso) - o que pode ser bastante intrigante (e interferir) quando alguém tenta problemas de conexão de depuração.

    

Answer 2

Esta é a ordem das coisas que eu tentaria ao depurar um dispositivo sem fio.

1. A reinicialização resolve o problema?

2. Tente descarregar os drivers do kernel relacionados ao dispositivo sem fio. Algo para o efeito do seguinte:

   $ lsmod | grep iw
   iwlagn                209751  0 
   iwlcore               195714  1 iwlagn
   mac80211              229095  2 iwlagn,iwlcore
   cfg80211              134981  3 iwlagn,iwlcore,mac80211
   
   $ sudo rmmod iwlagn
   $ sudo rmmod iwlcore
   
   $ modprobe iwlagn
   

3. Investigue todas as mensagens relacionadas ao dispositivo sem fio sendo relatado por dmesg . Por exemplo:

   $ dmesg
   ...
   ...
   [207981.191849] mac80211: Unknown parameter 'ieee80211_disable_40mhz_24ghz:Disable'
   [207988.895378] mac80211: 'Disable' invalid for parameter 'ieee80211_disable_40mhz_24ghz'
   [208280.841725] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d
   [208280.841727] iwlagn: Copyright(c) 2003-2010 Intel Corporation
   [208280.841826] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
   [208280.841857] iwlagn 0000:03:00.0: setting latency timer to 64
   [208280.842798] iwlagn 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C
   [208280.863413] iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels
   [208280.863582] iwlagn 0000:03:00.0: irq 48 for MSI/MSI-X
   [208280.898025] iwlagn 0000:03:00.0: loaded firmware version 128.50.3.1 build 13488
   [208280.898725] phy1: Selected rate control algorithm 'iwl-agn-rs'
   [208281.154937] ADDRCONF(NETDEV_UP): wlan0: link is not ready
   [208282.101156] wlan0: authenticate with 30:46:9a:47:4c:d4 (try 1)
   [208282.104128] wlan0: authenticated
   [208282.104164] wlan0: associate with 30:46:9a:47:4c:d4 (try 1)
   [208282.106911] wlan0: RX AssocResp from 30:46:9a:47:4c:d4 (capab=0x411 status=0 aid=3)
   [208282.106914] wlan0: associated
   [208282.111520] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
   [208292.608637] wlan0: no IPv6 routers present
   

Answer 3

Tinha hand shake + FAIL problemas por muito tempo também. Nenhuma solução dos fóruns ( gentoo | Arch ) nem stackexchange funcionou para mim.

Eu estou com um esqueleto void linux, usando apenas programas essenciais dhcpcd , wpa_supplicant .

O que finalmente funcionou demorou, mas não houve outra chance porque:

• o conector fêmea do cabo LAN também está quebrado sem qualquer peça de reposição disponível em qualquer distribuidor de eletrônicos da DigiKey | Farnell | Reichelt | Conrad | Mouser | Amazon, pois é uma variante de meia altura sem rótulo de peça | número | dica.
• soldando fios individuais na placa-mãe, o que é um esforço louco, não faça isso em casa haha, enquanto trabalha, requer fios flexíveis finos (muito finos) para não encurtar ou quebrar!
• um WLAN chip de substituição (para descartar hardware quebrado) não estava no hardware whitelist suportado com código fixo no bootloader da Lenovo. Sim, realmente ótimo, compatível, mas simplesmente não listado e, portanto, falhando, wow, apenas wow. %código%! Lenovo! Senso comum?

Assim, após muitos testes e erros, tempo de depuração, outra correção (possibilidade) surgiu, que gostaria de compartilhar com a comunidade.

Solução que funciona para mim todas as vezes após a reinicialização: 1

sudo wpa_cli  # fail
sudo xbps-install -Syv NetworkManager
sudo ln -s /etc/sv/NetworkManager /var/service/

2 (pode ser executado automaticamente após a inicialização)

sudo sv up NetworkManager
sudo wpa_cli  # works half way (scan possible but association fails)
sudo sv down NetworkManager
sudo wpa_cli  # fail
sudo sv restart dhcpd
sudo wpa_cli  # works

Certifique-se de que o dhcpcd, wpa_supplicant e a interface de rede correta estejam ativados | e em funcionamento e que a interface de rede, e. wlan0 ou wlp2s é usado no /etc/wpa_supplicant/wpa_supplication.conf, id est:

 sudo vi /etc/sv/wpa_supplicant/run  # Change all occurrences of the default interface name like e.g. "wlan0" to the correct interface as shown by ip link command, exempli gratia "wlp2s".

Parece que o NetworkManager tem algum efeito que é a correção! Ainda não tive tempo de investigar qual é.