I have a kinda strange WiFi issue. I just bought a WiFi USB adapter for my RPi2, and I can list the Wifi networks, but if I add the credentials to the wpa_supplicants file, it does not want to connect. Also if I do raspi-config, and want to edit the wifi settings there, it tells me, that it cannot communicate with the wpa_supplicant. Now I have read, that there are some driver issue with the WiFi adapter I am using, but some people seem to be using it without problems. The dongle is the TL-WN722N v2 EDIT: I now tried to access everything via the GUI. In the dialog I was told, there is no wireless interface installed.

EDIT 2: To answer a comment: I am on the newest release that comes with raspberry pi imager, Rasbian Buster. The wpa_supplicant.conf reads the following:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


I actually tried multiple different versions of this file, including one time, where I already created the file befor firing up the pi, as I read, that having lan connected sometimes messes with the wifi. This is the output from the ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
link/ether b8:27:eb:f4:ae:6f brd ff:ff:ff:ff:ff:ff
inet brd scope global dynamic noprefixroute 
   valid_lft 863628sec preferred_lft 755628sec
inet6 2002:5fd0:e3c6:0:29ac:d9de:cfdc:a73b/64 scope global dynamic mngtmpaddr 
   valid_lft 7063sec preferred_lft 3463sec
inet6 fe80::2840:a29f:80a9:caa3/64 scope link
   valid_lft forever preferred_lft forever
 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN 
 group default qlen 1000
link/ether d0:37:45:19:4b:10 brd ff:ff:ff:ff:ff:ff

I should also probably mention, that I tried this with multiple installs. I also tried it after updating via raspi-config and directly with apt.

  • Have you set the country in the wpa_supplicant file?
    – CoderMike
    Commented Sep 3, 2020 at 15:02
  • I tried a couple of things. I just follwed this qlcplus.org/forum/…. but it did not help -- edit: just to be clear, I also set the country multiple times, including in this instructions Commented Sep 3, 2020 at 15:08
  • What operating system and what version do you use? Raspberry Pi OS Buster? Please edit your question and add the output of these commands to it: ip addr and sudo cat /etc/wpa_supplicant/wpa_supplicant.conf. Obscure your psk (password).
    – Ingo
    Commented Sep 4, 2020 at 8:56
  • @Ingo, just updated the question Commented Sep 5, 2020 at 15:25

4 Answers 4


You answer your question and asked for details: "Can anyone explain this?". As shown with ip addr the wlan0 interface is down. So you have to look why it doesn't comes UP on bootup. Using /etc/network/interfaces for it isn't not a good idea because it may disable dhcpcd partial and you have exactly to know what you are doing.

Just for testing flash the Raspberry Pi OS (32-bit) Lite to an SD Card, and create the wpa_supplicant.conf file in its boot partition as usual. Then the wlan0 interface must be UP. Check with for example:

rpi ~$ ip -brief address show wlan0
wlan0            UP    fe80::dea6:32ff:fe7f:3892/64

It must also have an ipv4 address (e.g. If it is down then try to bring it up manual:

rpi ~$ sudo ip link set wlan0 up

If the interface is down it is still possible to scan for networks. That is why you can scan for networks even wlan0 is DOWN and not working for wpa_supplicant:

rpi ~$ sudo ip link set wlan0 down
rpi ~$ sudo iw dev wlan0 scan
BSS 34:31:c4:c7:f2:74(on wlan0)
        last seen: 64239.694s [boottime]
        TSF: 0 usec (0d, 00:00:00)
        freq: 2412
        beacon interval: 100 TUs
        capability: ESS Privacy ShortPreamble ShortSlotTime RadioMeasure (0x1431)
        signal: -60.00 dBm
        last seen: 0 ms ago
        SSID: [email protected]
--- snip ---

If wlan0 is DOWN after bootup then you should look at dhcpcd why it doesn't bring up WiFi. Wpa_supplicant is managed with its hook file in /lib/dhcpcd/dhcpcd-hooks. Look at man dhcpcd and search for hook, and maybe denyinterfaces, or allowinterfaces.

UPDATE with info from comments:
By default wpa_supplicant is executed with backend driver nl80211. This is the preferred driver as noted in man wpa_supplicant:

nl80211 Uses the modern Linux nl80211/cfg80211 netlink-based interface (most new drivers). wext Uses the legacy Linux wireless extensions ioctl-based interface (older hardware/drivers).

Obviously your USB/WiFi dongle does not understand the up to date backend driver nl80211 and has to use the wext driver. You forced to use it with adding this options to /etc/dhcpcd.conf:

env ifwireless=1
env wpa_supplicant_driver=wext

These are environment variables used by the hook script /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant of dhcpcd to manage wpa_supplicant and partial documented with man dhcpcd.conf. What exactly they do, have a look at the script.

  • Thank you, I did the steps you described, and the wifi will never go up. Is there any log I can maybe take a look at? Just took a log at /var/log/syslog, and I get a waiting for carrier, and following this a timout. Commented Sep 5, 2020 at 18:53
  • Check with journalctl -b | grep wpa_supplicant. Do you get any (error)message when executing sudo ip link set wlan0 up? I suspect there is a problem with the driver. Do you find something with journalctl -b | grep firmware? Something like "failing to load"?
    – Ingo
    Commented Sep 5, 2020 at 19:04
  • the first gets my the following two messages: -Condition check resulted in Copy user wpa_supplicant.conf being skipped. -wpa_supplicant[314]: Successfully initialized wpa_supplicant I do not get any error messages no, just the loading of the RPI kernel firmware and its hashcode Commented Sep 5, 2020 at 19:10
  • Hm... I'm out of ideas now. At next I would check what is /etc/network/interfaces doing to start the WiFi and what makes the difference to the standard setup.
    – Ingo
    Commented Sep 5, 2020 at 19:21
  • actually the sudo wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf -d works. Just had a typo in the supplicant config. Also when i log in, wpa_supplicant and dhcpcd are stared Commented Sep 5, 2020 at 21:49

I had to go into my WiFi security settings and disable 'WPA3 Personal / SAE' and 'WPA2 Personal with SHA256' To be able to connect. I left 'WPA2 Personal' as my only security setting enabled

Took me about 3 hours to find this out following all other answers or troubleshooting steps. I turned off my WiFi security and it would connect. Then after enabling WPA2 it would still connect. Enabling any other setting would make it unable to connect.

@RPI team; Maybe add a note somewhere that you can only use WPA2? I didn't see this noted anywhere.

  • This totally just bit me too on openwrt. Default setting was WPA2-PSK/WPA3-SAE MIXED MODE - does NOT work with raspberry pi wifi on raspberry pi os. Selecting WPA2-PSK on the router fixed the pi immediately. This is the ONLY device on my wifi with this problem including a bunch of random IOT devices. Strange huh! Commented Sep 3, 2023 at 14:54

I actually got it working, but I have no idea, why this was not configured correctly in the first place. I had to go into the /etc/network/interfaces and add:

auto wlan0
iface wlan0 inet dhcp
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

The file was completely empty, except a statement to include /etc/network/interfaces.d, an empty folder. It even seems odd to me, that Linux is working without any problem, as there is no loopback interface specified, and the eth0 connection also does not get mentioned. Can anyone explain this? I also have realised, that this configuration messes with dhcpd, but I cannot find any mention on how to add the wifi interface to dhcpdcd. Any suggestions here?

I actually am still working on this... Turns out my current configuration was not compatible with dhcpdcd, but the problem to me seems to be, that the hook from dhcpdcd launching the wpa_supplicant was not working, but as this is a completely different topic, I will start a new question.


I had to bring back my psk from 64 characters to 60 as suggested in the /var/log/syslog and there was no problem anymore.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Sep 9, 2022 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.