ESP32 Forum

Hello Team,

We were using ESP32 IDF 3.2 into one of our product and migrated to SP32 IDF 4.4 in which following component has been kept as older ESP32 IDF 3.2

TCP/IP Adapter

So, We have ported our application with that and it is also running fine into normal case.

ESP32 is working as AP+STA Mode in which STA mode is working while into AP mode devices are not able to connect.

But, We are facing issues after couple of days into few hardware like Mobile Device or any other device which is trying to connect to ESP32 (ESP32 as AP Mode) is not able to connect and continuous join and leave prints are coming.

It was working fine till few days and after that issue is being faced randomly without any change into device side.

Below are logs for reference

I (23226) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

I (23226) wifi b2:33:2e:ce:80:57 join, AID=1, bgn, 20

I (27236) wifi b2:33:2e:ce:80:57 leave, AID = 1, bss_flags is 658530, bss:0x3fff9240

I (27236) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

I (29266) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

I (29276) wifi b2:33:2e:ce:80:57 join, AID=1, bgn, 20


I (33276) wifi b2:33:2e:ce:80:57 leave, AID = 1, bss_flags is 658530, bss:0x3fff9240

I (33276) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

I (35306) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

I (35316) wifi b2:33:2e:ce:80:57 join, AID=1, bgn, 20

I (35326) wifi b2:33:2e:ce:80:57 leave, AID = 1, bss_flags is 658530, bss:0x3fff9240

I (35326) wifi<6,0>, old:<6,0>, ap:<6,2>, sta:<6,0>, prof:1

Let me know if anyone has faced similar kind of issues at their end.

Note - If we change wifi configuration or flash firmware again then it is started to work normally.

Hello Espressif Team,

As per further debugging from our end like it seems Password has been corrupted into NVS Storage location of wifi configuration.

Still, We will compare both working and non working NVS partition of both device and will let you know.

Because, when we set wifi configurations into non working device through CLI at that time it is started to working.

Hello ESP_Sprite or Espressif Developers,

We have looked issue into details, and it seems like NVS location is going to corrupt for wifi configurations or may be particular region is going to corrupt.

Do we have any tool or utility to read NVS data specific for AP SSID and Password which are stored into NVS Memory? so that we can execute that command directly into non-working board and can check like what are the configurations are stored into NVS Flash Memory

Also, It would be good if you can share some more information and details about NVS Storage perspective just for understanding perspective.

Hello Espressif Team or Developer Team,

We have further looked into issues and did some testing from our end as per possible test-cases and observed that when we are dumping NVS Memory from Non-working system into working system then also it is working fine.

Initially we have doubt that there are some issues into NVS section where AP SSID and Password are stored but when we taken NVS partition from non-working system to working system then it is working fine without any issues.

So, now, we don't have any clue that why it is not working into few boards in which Access Point is not working.

Also, I have one request that do we have any document or flow like how AP and STA wifi configurations are stored into NVS while changing both configurations many times? is there any Link List or kind of traverse mechanism is being managed into it for number of AP and STA SSID and Password to be stored as per configurations?

Hello Espressif Team or Developer Team,

Would you please help us to isolate issue if anyone has any expertise into it? Because it is really critical issue for us like we must need to take device from customer field and resolve issue manually when this issue is faced at customer end.

Let me know if anyone has any clue for the same.

Did you find anything with regards to this problem? I have this behavior as well.

DrMickeyLauer wrote: ↑

Wed Mar 27, 2024 2:10 pm

Did you find anything with regards to this problem? I have this behavior as well.

I suggest you create an issue on https://github.com/espressif/esp-idf
with information about the soc/module, idf version and related log.

Damn same issue here too (but connection to wifi on windows PC) .... It looks it is related to ESP32S3 chips only because I can not reproduce the same failure behavior (connect and 2 seconds later misterious disconnection when ESP chip is in AP mode) on other simple ESP32 chips.
ESP32 works fine (same code compiled) ... ESP32S3 continues to refuse all incomming connections with following logs
So smells to something related to handshaking when ESP32S3 is in AP mode.

Voila ..... I finally catch the damn thing. Problem was that I also used NVS for storage of some data. So everytime new data is stored to NVS, Commit is called but I didnt have CLOSE NVS HANDLE right after commit but at some other place, so when reset (from debbuging) or regular reset happens and NVS handle was not closed, corruption in NVS happens, which then makes problems on next reboot with credentials (or other things stored by wifi driver into NVS) and any try to connect to that AP fails followed by immediate disconnection.

Edit:
I don't want to oversize this thread so I decided to put some additional info about changes I made during hunting for this nasty behavior in this post. So in my setup, ESP acts as an AP. I also had changed security level threshold from WPA3 down to WPA2 (still didn't try to bring it back to WPA3 and re-test) but that alone didn't fix the problem, then I found a possible branches in code where reset can occur leaving nvs handle not closed, so I put nvs_close_handle after each commit. And after that I have never experienced issue related to immediate disconnection. Also, by design, only one STA at the time is allowed to connect, however I left max allowed connection to 4 because I am not sure how DHCP on esp AP handle used IP address once STA is disconnected. I mean, does it release imediatelly or it stays as reserved for some time which (if it is the case) could refuse another connections for a while if only 1 max connection is allowed. So I set it up to 4 to avoid such or simmilar possibly denies related to DHCP on AP.

Interesting. I doubt that this is the problem here, but it's worth a shot. So it should not happen when the partition is clean and no app code is using NVS. Let me do some tests.