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`>
       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.

  • 1
    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.
    – peterph
    Sep 18, 2013 at 19:53
  • @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. Sep 21, 2013 at 23:43
  • I'm glad I could help. I've also put it into an answer for the posterity. :)
    – peterph
    Sep 23, 2013 at 14:12

3 Answers 3


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.

  • 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. Sep 23, 2013 at 15:26
  • 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 .
    – peterph
    Sep 23, 2013 at 20:41
  • 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 Sep 24, 2013 at 13:47

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 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
  • 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? Sep 21, 2013 at 23:53
  • @Bob - yes, I would experience frequent problems with the N-1000 Intel Centrino network card. I still encounter problems but I've been able to mitigate them so that I only 1-2 times a month have to unload the drivers and reload them. Unloading drivers is similar to a soft reset of sorts. I've encountered other hardware where this has cleared issues up with the hardware too.
    – slm
    Sep 21, 2013 at 23:56

Had hand shake + FAIL issues for long too. Neither any solution from (gentoo|Arch) forums nor stackexchange worked for me.

I am on a bare bones void linux, using only essential programs dhcpcd, wpa_supplicant.

What finally worked, took me ages but there was no other chance because:

  • the LAN cable female connector also is broken without any replacement part available at any electronics distributor from DigiKey|Farnell|Reichelt|Conrad|Mouser|Amazon as it is a half height variant without part label|number|hint.
  • soldering individual strands to the mainboard, what a crazy endeavour, do not do it at home haha, while working, requires thin (very thin) flexible wires to not short or break!
  • a replacement WLAN chip (to rule out broken hardware) was not in the hard coded supported hardware whitelist within the Lenovo bootloader. Yes, really great, compatible but simply not listed and thus failing, wow, just wow. Hard coded white list! Lenovo! Common sense?

Thus after heaps of trial and error, debugging time another fix (possibility) emerged, which I'd like to share with the community.

Solution that works for me every time after reboot: 1

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

2 (May be run automatically after boot.)

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

Make sure dhcpcd, wpa_supplicant, correct network interface are up| and running and that the network interface e.g. wlan0 or wlp2s is used in the /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".

It appears that NetworkManager has some effect that is the fix! I have not had time yet to investigate which it is.

  • Note this also works when moving from one WLAN connection to another. Execute enable_network <id> within wpa_cli before starting, terminating NetworkManager and restarting dhcpcd,
    – Radagast
    Apr 9, 2017 at 17:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .