"wpa supplicant: No network configuration found for current AP" - carl9170-driven wifi adapter glitching on Debian 7

Question

I've got a Debian 7 machine with Linux3.2 kernel and a USB wifi adapter with Atheros chipset (D-Link DWA-16 Xtreme N Dual Band), which in theory should work.

Indeed, I managed to establish a wifi communication with NetworkManager and it worked more or less fine for ~30 minutes, but then disconnected and failed to reestablish the connection.

I failed to reestablish the connection with NetworkManager, it successfully associates and authenticates, starts 4-way handshake, but then deauthenticates due to reason 15 (4-way handshake timeout).

Then I tried to do the same via the good old ifupdown by creating an entry in /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

When I sudo ifup wlan1, it behaves reasonably, until:

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

(from /var/log/syslog). Wireshark sees ARP packages going from my wifi adapter to the router, but the router doesn't reply.

Do you have any ideas about what could that mean and how to troubleshoot this?

SOLUTION: Thanks to suggestion by peterph, I tried to create wpa_supplicant.conf and run wpa_supplicant as a standalone program both in foreground and background and then used wpa-conf wpa_supplicant.conf in /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

I had the first part of troubles (with spontaneous disconnect after "status: associated") disappear, when I killed a running instance of NetworkManager. It seems to have interfered.

Second part of trouble was with the 4-way handshake failing. It passed ok, when I disabled MAC address filtration on the Access Point. My wifi interface's MAC was in the list of available MACs, but for some reason it still was failing to connect with MAC filtering on the router.

UPDATE 2: The problems are back. 4-way handshake is failing again. Reload of the driver won't help.

Solution 1

This kind of problem is better divided into independent parts. In this case, circumventing ifupdown completely and doing all the steps manually - that is:

1. run wpa_supplicant with an appropriate config file

2. once connection is established, running dhcp client,

To check how ifupdown runs wpa_supplicant - it has to pass it some sort of configuration in a file, that you could intercept - check the output of ps fax | grep wpa_supplicant when ifupdown is running - the parameter of the -c option is the name of the (probably on-the-fly generated) configuration file.

If you decided to switch from ifupdown for some reason, you might be interested in wicd, which consists of a daemon controlled by various UIs (ncurses, GTK, Qt).

By the way, some DHCP clients are able to set up the wireless connection by spawning wpa_supplicant on their own (I have seen dhcpcd doing that) - which can be quite intriguing (and interfering) when one tries to debug connection problems.

Solution 2

This is the order of things I'd try when debugging a flaky wireless device.

1. Does a reboot resolve the issue?

2. Try unloading the kernel drivers related to the wireless device. Something to the effect of the following:

   $ 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. Investigate any messages related to the wireless device being reported via dmesg. For example:

   $ 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
   

Comments

[peterph]

Could you possibly circumvent ifupdown completely and do all the steps manually? That is: 1. run wpa_supplicant with an appropriate config file and then a dhcp client, once the wifi connection is stable. You might want to check how the ifupdown runs wpa_supplicant - it has to pass it some sort of configuration in a file, that you could intercept - output of ps fax | grep wpa_supplicant when ifupdown is running should give you an idea where to look for the generated config file - it is the parameter of the -c option.

[CoOl]

@peterph Thank you so much, peterph, for your suggestion. I'm writing now right through the troublesome interface (though, not sure yet, whether it is going to work stable). See the edit of the post for details and also you could post your comment as an answer, so that I could accept it.

[peterph]

I'm glad I could help. I've also put it into an answer for the posterity. :)

[CoOl]

Thanks, the problem seems to have disappeared due to some wpa_supplicant tweaking. Hm, it seems strange to me that reloading a kernel module can resolve the issue. Did it happen in your experience?

[CoOl]

Unfortunately, the problems are back. I'm still getting "4-way handshake failed". Reload of the driver helped once, but now it is still failing to connect. I suppose, I should go badger Johannes Berg and folks, who written the driver. Thanks for your suggestions, though.

[peterph]

Maybe a silly question, but do you have the pre-shared key right in wpa_supplicant.conf? The psk parameter should hold the actual passphrase, not its hash (as it sometimeas happens). Also sometimes it might help switching off (or on) IPv6 (echo 0 or 1 to /proc/sys/net/ipv6/conf/all/disable_ipv6) - I have seen connection problems with IPv6 enabled, although I don't recall any more whether it was with this error .

[CoOl]

I've tried both with psk passphrase and its hash (in case of pure passphrase, I used "" around it). Thanks for ipv6 suggestion, I'll try it