Open alerighi opened 3 weeks ago
@alerighi can I have the commit ID of the IDF on which you are seeing this issue ? Also can you share the sniffer capture during the disconnection.
Hi, @alerighi Thanks for reporting this issue, and sorry for the late response. From the debug log, seems like the AP can not receive the ACK frame from the DUT (esp32c6), and then the AP sends the deauthentication to DUT, letting the DUT disconnect with the AP. I have tried to reproduce it in my testbed, but it works fine. Have you used other APs to test this case?
Hi,
the commit I'm using is the one corresponding to the 5.2.1 release:
commit a322e6bdad4b6675d4597fb2722eea2851ba88cb (HEAD, tag: v5.2.1)
Have you used other APs to test this case?
I've tried with other AP that are only Wi-Fi 4 2.4GHz and it works. The AP that I'm having issues so far is only the Ubiquity that I've mentioned above. This AP has configured a network that has both the band 2.4 and 5GHz and uses the Wi-Fi 6 standard.
I can try to reproduce the issue on another Wi-Fi AP that has Wi-Fi 6 networks, and I will get you back.
Hi,
the commit I'm using is the one corresponding to the 5.2.1 release:
commit a322e6bdad4b6675d4597fb2722eea2851ba88cb (HEAD, tag: v5.2.1)
Have you used other APs to test this case?
I've tried with other AP that are only Wi-Fi 4 2.4GHz and it works. The AP that I'm having issues so far is only the Ubiquity that I've mentioned above. This AP has configured a network that has both the band 2.4 and 5GHz and uses the Wi-Fi 6 standard.
I can try to reproduce the issue on another Wi-Fi AP that has Wi-Fi 6 networks, and I will get you back.
@alerighi Thanks for the reply, Also wireless sniffer capture with the Ubiquity AP will be helpful to pin point the issue.
Hi @nishanth-radja,
I've reproduced the issue and captured with Wireshark the packets. wireshark-capture.zip
To see the traffic of the device you can use the filter: wlan.addr == 40:4c:ca:41:83:10
@alerighi Thanks for the captures,How far is the STA from the AP and also is the environment very noisy.I see that STA is not able to reply to most of the packets from AP.Also can you disable beam-forming on the AP and disable RTS protection.This will reduce the channel noise. Can you try these and send the capture if the problem persist ?
Hi, the AP is near to the STA (approximately 5 meters).
The environment is noisy since we have a lot of Wi-Fi devices, and also there are a lot of Wi-Fi networks and devices from nearby offices (that we don't have control).
I will try what you suggested and get you back.
Hi, I've tried to find the options you mentioned in the Ubiquity configuration page, but it seems that I cannot control that configurations.
Is there something else that I can try?
@alerighi If all the device are on channel 1 ,can you move your AP to channel 11 and try. Noise will be lesser in channel 11.Can you provide a sniffer capture on channel 11 during the association.We can see if the problem persist.
Answers checklist.
IDF version.
v5.2.1
Espressif SoC revision.
esp32c6
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-C6-DevKitC-1
Power Supply used.
USB
What is the expected behavior?
When configuring the board to activate both the AP mode and the STA mode (WIFI_MODE_APSTA) the STA connection to a Wi-Fi AP (in my case an Ubiquity Unifi U6-Pro) does initially succeed (the device gets an IP address), but when making the first network request it fails. Note that the connection to the same AP works correctly if only the STA mode is activated (WIFI_MODE_STA).
What is the actual behavior?
The AP connect successfully and network requests succeed.
Steps to reproduce.
I've was able to reproduce the issue by modifying the example "softap_sta" by adding an HTTP request at the end.
Debug Logs.
More Information.
The disconnect reason seems to be
WIFI_REASON_MISSING_ACKS
. Here a screenshot of the AP settings. As you can see it's using the default settings.Thanks, Alessandro