Raspberry Pi wifi scan working, but cannot connect to wifi

Question

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
update_config=1
country=DE

network={
   ssid="correctWifiSSID"
   psk="correctWifiPassword"
}

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 127.0.0.1/8 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 192.168.178.53/24 brd 192.168.178.255 scope global dynamic noprefixroute 
 eth0
   valid_lft 863628sec preferred_lft 755628sec
inet6 2002:5fd0:e3c6:0:29ac:d9de:cfdc:a73b/64 scope global dynamic mngtmpaddr 
noprefixroute
   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.

Answer 1

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             192.168.50.51/24 fe80::dea6:32ff:fe7f:3892/64

It must also have an ipv4 address (e.g. 192.168.50.51/24). 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.