espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.63k stars 7.28k forks source link

Wi-Fi connection fails to Cisco enterprise network with 802.11b rates disabled (IDFGH-1720) #3956

Closed ghost closed 4 years ago

ghost commented 5 years ago

Environment

Problem Description

With latest ESP-IDF from master Wi-Fi connections to Cisco based corporate wifi networks fails most of the time. The network uses WPA2 Enterprise (EAP-PEAP-MSCHAPv2).

Bisecting the problem shows that the problem was introduced in the following commit:

commit 45dd6175cddc5a9103a89566df995a522cbe6703
Author: liu zhifu <liuzhifu@espressif.com>
Date:   Tue Jul 16 10:17:48 2019 +0800

    esp_wifi: optimize wifi rx

//Detailed problem description goes here.

When checking sniffer logs it seems that with the above mentioned patch ESP32 ACKs all management frames with 802.11b 1Mbit/s data rate.

The network is configured with the lower datarates disabled and it appears the then AP simply ignores all 1Mbit/s ACKs. In sniffer log this show as AP continuously retransmit the management frames.

ESP32 knows that AP does not support the 1Mbit/s data rate through beacons, probe responses and even acknowledge this by sending assoc requests with correct supported rates tag (though strangely the frame is sent with a 1Mb/s data rate).

Expected Behavior

ESP32 should only send frames with negotiated supported data rates.

Actual Behavior

ESP32 with the "esp_wifi: optimize wifi rx" patch sends ACKs and management frames with 1Mb/s data rate.

ESP32 without the "esp_wifi: optimize wifi rx" patch sends ACKs and management frames with a mix of 1Mb/s and 6Mb/s data rates. Even though this appears to be accepted by the AP and a connection can be established, ESP32 should ideally only send frames with the negotiated data rates.

Steps to repropduce

  1. Configure ESP32 with proper wifi network settings
  2. Try to connect to Cisco wifi enterprise network with 802.1b (and more) data rates disabled.
  3. Notice that connection fails nearly 100% of the times.

Debug Logs

Sniffer logs attached

ghost commented 5 years ago

Sniffer logs attached rx-optimized-fail.tar.gz

liuzfesp commented 5 years ago

Hi @mikaelkanstrup it's new introduced by commit 45dd6175cddc5a9103a89566df995a522cbe6703, we will fix it soon.

ghost commented 5 years ago

Hi @mikaelkanstrup it's new introduced by commit 45dd617, we will fix it soon.

@liuzfesp great! Thanks!

esp-daiwei commented 5 years ago

This issue is fixed by: cf0caaec

Alvin1Zhang commented 5 years ago

@mikaelkanstrup Would you please help try with the commit and see whether your issue is resolved? Thanks.

kanstrup commented 5 years ago

@esp-daiwei @Alvin1Zhang Most likely that will solve the issue, it's a revert of the commit causing the issue after all. But it's not available on master branch. Only available on v4.0.

liuzfesp commented 4 years ago

Hi @kanstrup master fix commit: b7334b03, we already merged the fix. However, it may take several days before you can view it on the github IDF master branch.

ghost commented 4 years ago

I've done some initial testing and still see that ESP32 use non-negotiated data rates. However ESP32 has stopped ACKing with only 1Mbit data rate which indicates whatever was done in 45dd617 is nowreverted. I am able to connect again so problem appears to be solved.

@liuzfesp how is b7334b0 related to 45dd617 that introduced the problem? Under our config we end up with default ESP32_WIFI_IRAM_OPT=y and ESP32_WIFI_RX_IRAM_OPT=y so don't how see b7334b0 can be the solution to this problem.

negativekelvin commented 4 years ago

Probably the fix is included in the library update in https://github.com/espressif/esp-idf/commit/a9c1970c031301f232d0c8473dcacdb7c9c12f7e

ghost commented 4 years ago

@negativekelvin OK thanks. I'll do some more testing before closing the issue.

liuzfesp commented 4 years ago

@mikaelkanstrup,b7334b0 has no relationship with this problem. b7334b0 actually involves several WiFi changes which is related to WiFi receiving, one of these change is to revert 45dd617.

ghost commented 4 years ago

@liuzfesp Thanks for info and thanks for solving this issue. After some more testing done I can confirm this is fixed.