esp-idf: wifi: EAP re-authentication does not work (IDFGH-345)

Environment

Development Kit: [none]
Kit version (for WroverKit/PicoKit/DevKitC): [-]
Core (if using chip or module): [ESP32]
IDF version): 30545f4
Development Env: [Make]
Operating System: [Ubuntu]
Power Supply: [external 5V]

Problem Description

EAP re-authentication is non-functional. EAP/enterprise wifi networks may be configured to re-authenticate at certain intervals to regenerate new crypto keys. This function does not work on ESP32 causing wifi disconnects. Also after being disconnected the chip appears stuck in some invalid state causing it to never perform new connect attempts.

Expected Behavior

Successfully connect to EAP/enterprise wifi network
Wait for network to initiate EAP re-authentication
EAP re-authentication completes
Wifi connection is kept

Actual Behavior

Successfully connect to EAP/enterprise wifi network
Wait for network to initiate EAP re-authentication
ESP32 does not respond to network initiated EAP re-authentication
After re-auth timeout ESP32 is disconnected by network (or STA depending on who timed out first)
After being disconnected no more connect attempts are performed.

Steps to repropduce

Configure a test EAP (PEAP-MSCHAPv2) network using hostapd
Set eap_reauth_period in hostapd.conf to a low value (like 60) to have the network perform re-authentication often.
Connect to network using ESP-IDF wpa2_enterprise example code
Wait for EAP re-authentication to occur
Notice the disconnect
Notice that no new connect attempt is done.

Debug Logs

I (144671) example: IP:192.168.5.5
I (144671) example: MASK:255.255.255.240
I (144671) example: GW:192.168.5.1
I (144671) example: ~~~~~~~~~~~
I (145311) wifi: state: run -> init (2c0)
I (145311) wifi: pm stop, total sleep time: 137439245 us / 140408103 us

I (145311) wifi: n:3 0, o:3 0, ap:255 255, sta:3 0, prof:1
D (145321) event: SYSTEM_EVENT_STA_DISCONNECTED, ssid:Kanstrup, ssid_len:8, bssid:34:13:e8:62:a3:40, reason:204
V (145331) event: enter default callback
V (145331) tcpip_adapter: check: local, if=0 fn=0x400e554c
0x400e554c: tcpip_adapter_down_api at esp-idf/components/tcpip_adapter/tcpip_adapter_lwip.c:1082

Other items if possible

Attached files (logs.tar.gz:

trace.pcapng - air sniffer packet log
esp32.txt - esp serial log (verbose level)
hostapd-filtered.txt - hostapd log (probe req/resp frame log line among others filtered due to security concerns)

To decrypt traffic in air sniffer packet log (eapol packets for EAP re-auth are encrypted) use the following PMK 25638c633b709113ec73401621f08a8ca6a1d01193e9997cd44ed8dd9c49b27e

If wireshark is used the decrypt key can be configured under: Edit->Preferences->Protocols->IEEE 802.11->Decyption keys->Edit…

Add a WPA-PSK key with the key above.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 50 (20 by maintainers)

Most upvoted comments

We have fixed this internally. Unfortunately, it may take some time to be available on github. Hoping to get it done by early next week.

sagb2015 on Nov 13, 2019

This bugfix is internally ready-to be merged and should be available on master soon. We will update once done.

sagb2015 on Aug 28, 2019

😃 Looks good! I had 5 devices running over the weekend and three didn’t have any reconnect at all. The other two had a few but without any relation to the half hour seen before. I think they just have worse reception (office complex). Thank you so much! Please keep me updated on merging to master/release

PaulFreund on Dec 9, 2019

Okay maybe it was really a connection issue, now I’m running three hours without problems, I’ll keep you updated 😃 I will roll out the test firmware on more devices tomorrow

PaulFreund on Dec 5, 2019

Okay I have to investigate a little more, after one hour the device is no longer online at all. I will get back to you.

PaulFreund on Dec 5, 2019

And I am sorry that we could not make the fix available sooner. We have quite a CI backlog internally, We will prioritise this and get it merged this week.

sagb2015 on Dec 2, 2019

After seeing that @PaulFreund still had issues with the fix for this issue I looked more closely at some sniffer logs from the tests I did to confirm this issue was solved. Then found that I was wrong. The fix (3b606aa21f49566bbee796381861ad4868b65611) does handle re-authentication but not the way it should be done. The re-authentication shall be done with frame exchange encrypted with currrent keys. esp-idf do all 4-way handshakes unencrypted. Only the initial one can be.

Please see the attached logs and sniffer logs. Sniffer logs for both a test with wpa_supplicant under linux and with esp_supplicant attached.

For decryption with Wireshark the following PMKs can be used:

wpa_supplicant:
18b069d3a262256e2bd2aa1eb64518f894edc59b64f15774efa26cf66a67e97b
6f0ee8d2a59d3a7e27c282dab58c163d58bdba70eb7bcd78a7a0f9f6c7a25632

esp_supplicant:
4f30904463755fcf4a17d8fb56923c80ec782887852c6fc0ef52ced6cdd03107
7b3e4601eb7cff34c1f714adc9d9f622770c08a817b6619af24b630ca6f11a76
44902000134fcab831cf14f7c280aeae229034f5d9487974a77b5d213a49a349

Compare unencrypted 4-way handshake messages 2/4 and 4/4 from ESP in esp_supplicant.pcapng: 102, 103, 104, 127, 129, 131, 132

With same frames encrypted with wpa_supplicant.pcapng frames: 268, 270

logs.tar.gz

ghost on Oct 14, 2019

Thanks for implementing this!

Just wanted to confirm that reauth now works. In my test setup I’ve just completed ~50 successful re-authentications without dropping wifi connection.

ghost on Sep 13, 2019