Closed ghost closed 4 years ago
Sniffer logs attached rx-optimized-fail.tar.gz
Hi @mikaelkanstrup it's new introduced by commit 45dd6175cddc5a9103a89566df995a522cbe6703, we will fix it soon.
Hi @mikaelkanstrup it's new introduced by commit 45dd617, we will fix it soon.
@liuzfesp great! Thanks!
This issue is fixed by: cf0caaec
@mikaelkanstrup Would you please help try with the commit and see whether your issue is resolved? Thanks.
@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.
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.
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.
Probably the fix is included in the library update in https://github.com/espressif/esp-idf/commit/a9c1970c031301f232d0c8473dcacdb7c9c12f7e
@negativekelvin OK thanks. I'll do some more testing before closing the issue.
@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.
@liuzfesp Thanks for info and thanks for solving this issue. After some more testing done I can confirm this is fixed.
Environment
git describe --tags
to find it): v4.1-dev-58-g02c7c3885xtensa-esp32-elf-gcc --version
to find it): esp32-2019r1Problem 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:
//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
Debug Logs
Sniffer logs attached