raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.12k stars 4.98k forks source link

On-board WiFi EAPOL key exchange not responding #3213

Open jantheman opened 5 years ago

jantheman commented 5 years ago

Trying to connect to WPA-EAP Enterprise with phase2=MSCHAPV2 network using Raspberry Pi Zero W revision 1.1, image reference 2019-07-10.

When I plug-in an external WiFi USB dongle, "RTL8188CUS 802.11n WLAN Adapter" everything works as expected, it connects to the network and receives IP address from DHCP and internet works.

With exactly the same configuration, the on-board WiFi connects, but does not receive any IP. If I use static IP address, I could not even ping the gateway. Here is a packet trace from bringing the interfaces up (I changed the MAC address using macchanger to match the external adapter to rule out any MAC filtering).:

Screenshot

Nisca is the Raspberry Pi, Cambridg is the AP. The right one contains the working connection attempt through external dongle. Starting with packet 28, EAPOL key exchange is initiated, exchanging 4 key messages and 2 group key messages. The built-in non-working one on the left side has the same connecting trace, the first key message from AP being packet 28, but the Raspberry Pi never responds to that message. The AP tries a couple of times and then gives up.

I am left with no other options than blaming the wireless driver.

System

lategoodbye commented 5 years ago

Please provide your dmesg, so we can check this is related to the following wpa_supplicant issue.

mitch-davenport commented 5 years ago

Same issue on Raspberry Pi 3 B+ using MSChapv2.

I tested a different image on the same hardware running 4.14.79-v7+ it works fine with PEAP. WLAN Controller shows it passes radius auth but PI doesn't respond so I believe it's failing step 3 of EAP process. This one has no issue connecting a PSK network. dmesg.log

Which model of Raspberry Pi? Pi 3 B+ Which OS and version (cat /etc/rpi-issue)? 175dfb027ffabd4b8d5080097af0e51ed9a4a56c, stage2 Which firmware version (vcgencmd version)? version 0e6daa5106dd4164474616408e0dc24f997ffcf3 (clean) (release) (start) Which kernel version (uname -a)? Linux raspberrypi 4.19.66-v7+ Attaching the dmesg log.

Here's my supplicant. ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=US

network={ ssid="SecureNet" key_mgmt=WPA-EAP identity="piuser" password="pass" eap=PEAP phase1="peaplabel=0" phase2="auth-MSCHAPV2" }

lategoodbye commented 5 years ago

According to the dmesg this looks like the mentioned wpa_supplicant 2.8 regression. So in this case it isn't a kernel issue.

Try to use another wpa_supplicant version (2.7 or 2.9).

jantheman commented 5 years ago

Any luck @mitch-davenport with newer wpa_supplicant?

I confirm I had 2.8 too, I tried 2.9, but it got worse. Previously, it exchanged certificates at least, but with 2.9, it won't even associate. wpa_cli writes:

CTRL-EVENT-SCAN-STARTED
CTRL-EVENT-SCAN-RESULTS
Trying to associate with SSID 'mynetwork'
CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code 16
... few repeats ...
CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid='mynetwork' auth_failures=4 duration=77 reason=CONN_FAILED

When I use the external wifi dongle, it still works with the same config:

CTRL-EVENT-SCAN-STARTED
CTRL-EVENT-SCAN-RESULTS
SME: Trying to authenticate with 9c:50:ee:xx:xx:xx (SSID='mynetwork', freq=2312 MHz)
Trying to authenticate with 9c:50:ee:xx:xx:xx (SSID='mynetwork', freq=2312 MHz)
Associated with 9c:50:ee:xx:xx:xx
CTRL-EVENT-EAP-STARTED EAP authentication started
...

(by the way, unplugging the wifi dongle completely hangs the pi, requiring power cycling)

EDIT: I reflashed the whole system and installed wpa_supplicant 2.4 as per https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=244731#p1498661 and it did not help. I also tried to put the SD card into another raspberry pi zero and that worked. Either way, it is apparent the original issue is caused by wpa_supplicant rather than a kernel.