WiFi / WLAN: a autenticação WPA2 parece ser bem-sucedida, mas o dhclient não recebe uma resposta

Question

Estou tentando usar um adaptador WiFi USB para se conectar a um roteador sem fio.

Suponho que o adaptador é ativado com o driver correto, porque # iwconfig fornece uma saída razoável:

wlan0     IEEE 802.11bg  ESSID:"MYNET"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:1C:4A:A6:8F:0E   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=70/70  Signal level=-40 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:49   Missed beacon:0

Além disso, suponho que a autenticação entre o roteador e meu adaptador foi bem-sucedida, porque # wpa_cli status diz "COMPLETED" :

Selected interface 'wlan0'
bssid=00:1c:4a:a6:8f:0e
ssid=MYNET
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
address=00:0d:0b:35:ca:14

Pergunta 1: Com informações como esta, estou certo em assumir que meu adaptador roda bem como interface wlan0 , e que o roteador aceitou minha chave e está pronto e disposto a estabelecer uma conexão? Não estou tendo problemas de autenticação do WPA2?

Agora, para usar wlan0 , ele precisa de um endereço IP e o roteador é configurado como um servidor DHCP, com endereços DHCP variando de 192.168.2.100 a 192.168.2.199. Tanto quanto eu entendo o processo de negociação DHCP, dhclient deve trabalhar com os padrões, ou seja, ele transmite em 255.255.255.255, eo roteador deve responder como 0.0.0.0, finalmente, a emissão de um endereço disponível. De qualquer forma, # dhclient wlan0 -v , apenas desiste depois de um tempo:

Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/00:0d:0b:35:ca:14
Sending on   LPF/wlan0/00:0d:0b:35:ca:14
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Pergunta 2: (Provavelmente, a parte mais difícil de responder?) Por que a transmissão DHCPDISCOVER não recebe uma resposta adequada, ou seja, um DHCPOFFER?

Mais algumas informações e sugestões sobre possíveis enganos que eu possa ou não estar incorrendo:

• O roteador não usa a filtragem de MAC.
• Usando um ip estático fora do intervalo de DHCP do roteador (192.168.2.70), consegui me conectar e até mesmo entrar na ferramenta de configuração html do roteador em 192.168.2.1.
• A caixa da qual estou tentando se conectar tem uma interface com fio (eth0). Alguma chance de que a solicitação do cliente DHCP de wlan0 não seja enviada pelo ar para estabelecer uma conexão IP DHCP em 192.168.2.0, mas em minha sub-rede com fio (192.168.1.0/255.255.255.0)? Não há servidor DHCP na sub-rede com fio, então a solicitação DHCP pode acabar sendo perdida em 192.168.1.0/24? Como eu depuraria e descartaria algo assim?
• A caixa tem o Debian wheezy (7.0) instalado. Tendo usado a caixa em uma sub-rede com fio com endereços IP estáticos, posso ter esquecido de alterar uma configuração em algum lugar que possa ser necessário para que o dhclient funcione.

Answer 1

Eu tive um problema semelhante com a minha configuração. Meu roteador (Linksys E2500) não daria uma oferta de DHCP até que a concessão original do DHCP para o MAC da máquina expirasse.

Para corrigir isso, tive que remover manualmente a entrada da tabela de concessões do meu roteador e tentar recuperar a interface wlan.

Não sei por que isso acontece; talvez alguém mais familiarizado com o funcionamento do hardware e do DHCP no Debian possa nos esclarecer.