Soft AP does not reset AID of clients on power cuts (IDFGH-12159)

[SmartAppsML]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

release/v5.1

Espressif SoC revision.

ESP32-S3

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

esp-idf

Power Supply used.

USB

What is the expected behavior?

When disconnecting a client (ESP32) from the WiFi Soft AP (also ESP32), it triggers a STADISCONNECTED event, which is fine. However if the client connects again, this will lead to a new AID being assigned to the client without removing the old one. Repeating this 10 times leads to all the wifi slots being filled up, allowing no more connections to WiFi.

Also, it is not possible to use the deauth_sta function and remove the "faulty" AID.

What is the actual behavior?

The internal AID entry should be removed to free up the slot.

Steps to reproduce.

1. Set up Soft AP with ESP32-S3.
2. Set up client with ESP32-S3 and connect it to the Soft AP.
3. Reset the client, let it connect.
4. Repeat step 3 until the maximum AID is reached.
5. Now, no new devices are able to connect.

Debug Logs.

No response

More Information.

No response

[mhdong]

Hi @SmartAppsML
3. Reset the client, let it connect.
Are you trying to reconnect after reset using the same device?
If using the same device, multiple connections will obtain the same AID.
If different devices are used, due to a sudden power off, the connection is still considered to exist for SoftAP until the active timeout. At this point, a new device is attempting to connect and cannot use the already occupied AID.

By the way, if it's convenient, please provide the log you reproduced.

[SmartAppsML]

Thanks for the fast reply! Yes, I am using the same device to reconnect. The device automatically connects to the access point once started. So when I press RESET, let it connect and repeat the process, after 10 times all the slots are full and I can't connect any device to the network. mhdong ***@***.***> schrieb am Di., 20. Feb. 2024, 08:27:

…

Hi @SmartAppsML <https://github.com/SmartAppsML> 3. Reset the client, let it connect. Are you trying to reconnect after reset using *the same* device? If using the same device, multiple connections will obtain the same AID. If different devices are used, due to a sudden power off, the connection is still considered to exist for SoftAP until the active timeout. At this point, a new device is attempting to connect and cannot use the already occupied AID. By the way, if it's convenient, please provide the log you reproduced. — Reply to this email directly, view it on GitHub <#13215 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FE5ZDSP4GGIQUIBK4Y53YURF7FAVCNFSM6AAAAABDPT2Y32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTGYZDEMJYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mhdong]

Hi @SmartAppsML
Please provide the commit for IDF so that we can try to reproduce it. We have already fixed similar issues. If you are not using the latest release/v5.1, please use the latest and have a try.
d922d41

[SmartAppsML]

Thank you for the fast reply! I have tested the issue with the latest release/v5.1 but it is still a problem.

1. The access point connects to the Soft AP and gets AID 1.
   

2. Now I press "RESET" on the client. After resetting, it connects to the Soft AP again, receiving AID 2. AID 1 is not freed at this moment, so repeating this 10 times blocks all free slots.

3. Doing it again...

And so on. Thank you for looking into it!

[mhdong]

Hi @SmartAppsML
ap_aid_always_1.txt
sta_commit_d922d4178f0.txt

We tried to reproduce it locally using the demos of esp-idf/examples/wifi/getting_started/softAP and esp-idf/examples/wifi/getting_started/station by two ESP32S3 boards. And the idf commit was d922d41. It is indeed impossible to reproduce it, and the log is shown in the above file.

Please provide more logs for us to analyze.

[SmartAppsML]

Hey @mhdong indeed I checked the version again and was on an older version of 5.1. It is actually fixed using the latest commit! Thank you!

[AxelLin]

@mhdong
Could you share which commit fixed the issue? (I'd like to check if my firmware is impacted by this issue)

[SmartAppsML]

@AxelLin The latest one did it, as @mhdong mentioned: d922d41

[mhdong]

Hi @AxelLin
18ffa02 fixed this aid issue for release/v5.1.
79ddd24 for master