Wifi occasionally won't connect to dual-band router with same SSID (IDFGH-4064)

[scubachristopher]

Environment

• Development Kit: ESP32-Wrover-Kit (Hazzah Feather32)

• Module or chip used: ESP32-WROOM-32

• IDF version 2.0 (Platformio)

• Build System:
  PlatformIO Core 5.0.1
  Python 3.8.4-final.0
  System Type darwin_x86_64
  Platform macOS-10.15.7

• platformio.ini
  [env:esp32dev]
  platform = espressif32
  board = featheresp32
  framework = arduino

• Compiler version: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0

• Operating System: macOS

• IDE: MS Code / Platformio 5.0.1

• Power Supply: USB

Problem Description

I have a Synology AC2600 dual-band router advertising a single SSID on 2.4 and 5ghz. OCCASIONALLY (no firmware change), it will simply not connect to Wifi. MOST of the time, it does. When it fails, it is consistent and has the same behavior if I re-flash or even clear the flash. I have a web server running on the softAP that allows me to change the credentials.

I have a Pi that is in AP mode (2.4ghz) and it connects immediately to that. Switch back the creds to the dual-band and it won't connect.

Flashed the same firmware to my Olimex ESP32-EVB and it connected fine. I believe, eventually, it would exhibit the same behavior. I reflashed the same firmware to the Feather32 and the behavior was the same -- won't connect to dual-band. Perhaps this is because the MAC's are different.

So I decided to test this by watching the serial output and disabling my 5ghz advertisement and BAM, it immediately connects.

This is a SUBSTANTIAL issue because these instruments will be in the field connecting to a local AP that may be dual-band as well.

Expected Behavior

It should consistently connect to a dual-band wifi AP with a 2.4ghz station.

Actual Behavior

It OCCASIONALLY, repeatedly, won't connect.

Steps to reproduce

I've seen posts about people solving this by turning off their 5ghz radio on their router as a solution, which is not a solution. Since it's occasional, seems it might be triggered by distance from AP and how crowded the 2.4ghz channel is with other traffic -- dunno.

Code to reproduce this issue

    WiFi.begin(ssidSTA, passwordSTA);
    WiFi.setAutoReconnect(true);

    while (WiFi.status() != WL_CONNECTED && ticks++ < 20) {
      WiFi.begin(ssidSTA, passwordSTA);
      vTaskDelay(pdMS_TO_TICKS(500UL));
    }

Debug Logs

Reading from EEPROM, ssidSTA is (Christopher), passwordSTA is (XXXXXX)
SoftAP (LRI_ESP_30:AE:A4:26:69:40) IP address is (192.168.4.1), AP MAC address is (30:AE:A4:26:69:41).  Web server listening on port 80
ESP Network name is (Box-0448), Box ID is (ESP_30:AE:A4:26:69:40)
Attempting to connect to Wifi Station (Christopher) with password (XXXXXX)
Successful getting local time: 2020-10-02 17:54:19
Connected to Wifi Station (Christopher), IP address: (192.168.1.184), our hostname is (Box-0448-v1000) and our public IP is (XXXXXXXXX)
SETUP COMPLETE.
Secure MQTT connected, subscribed to (LRI/All) and (LRI/ESP_30:AE:A4:26:69:40)

----------  If failing --------
Wifi is disconnected, status is (1), attempting reconnect
Attempting to connect to Wifi Station (Christopher) with password (XXXXXXXX)
...

[ghost]

Can confirm this hapenning aswell. Unfortunately I didn't save any logs from when this was hapenning, though turning all possible debug on verbose, I found that it failed with a "auth timeout" and proceeded to blacklist the wifi - which is really bad, because I believe you have to restart or reinitialize the whole wifi stack to remove your AP from that blacklist.

[scubachristopher]

Yeah this is stunningly bad / problematic. Thanks for confirming I'm not crazy. I am concerned it might be a corner case based on distance to station and traffic on 2.4ghz.

Anyone else confirm this? Anyone supporting esp-idf care to comment?

[ghost]

I've brought a device home for the weekend to test, here is a really verbose output - it failed to connect multiple times, but I've got my code set to retry 4 times, so it eventually connected. It practically never connects on the first try, and it did fail completely a few times, but I did not have verbose output turned on yet at that point.

Note: 'wifi_manager' is my module, so take those outputs with a grain of salt, or ignore them

https://gist.github.com/istokm/bbce565b2492918a159abccf201d03d8

My wifi setup is as follows:
AP1 (TP-Link EAP225)
2.4GHz SSID: qwerty, BSSID: 74-da-88-50-11-f6
5GHz SSID: qwerty, BSSID: 74-da-88-50-11-f7

AP2 (TP-Link EAP225)
2.4GHz SSID: qwerty, BSSID: 50-d4-f7-34-5b-26
5GHz SSID: qwerty, BSSID: 50-d4-f7-34-5b-27

So essentially, both APs broadcast a dual-band signal with the same SSID

After the ESP finally connected, the RSSI reported by the AP stabilized at around -59

I've got my scan method set to fast, if set to all channels, the output changes to this: (unfortunately CMD trimmed the initialization, but I think most of the useful data is there)
https://gist.github.com/istokm/48b2c813008c6cf08889e6fb32c1d141

[scubachristopher]

Looks like in all instances in your gists the AP at 2.4 was found (mac f6 or 26).

How are you retrying?

My loop:

...
WiFi.begin(stationData.ssidSTA, stationData.passwordSTA);

while (WiFi.status() != WL_CONNECTED && ticks++ < 20) {
      WiFi.begin(stationData.ssidSTA, stationData.passwordSTA);
      vTaskDelay(pdMS_TO_TICKS(500UL));
}
...

If I fail to connect, I just retry this code segment. Are you suggesting that if you let it retry long enough, it will connect? Because mine never connects until I temporarily turn off dual-AP mode on my Synology. As soon as I do, it instantly connects.

Thanks for the work on this Marek (hope that is correct) ;)

[ghost]

I'm not using Arduino, but straight ESP-IDF, so my code is a bit different, but essentially the same thing:

case WIFI_EVENT_STA_STOP:
	// Retry the connection
	if (parent->state_ == STATE_CONNECTING &&
		parent->retry_counter_ < CONFIG_TWIN_WIFI_RETRY_COUNT) {
		ESP_LOGW(TAG, "[%s]: Connection failed, retrying", __func__);

		parent->retry_counter_++;
		parent->esp_connect(CONFIG_TWIN_WIFI_CONNECTION_TIMEOUT * 1000);
	}

esp_connect being just a small wrapper for:

esp_err_t err;

err = esp_wifi_start();
if (err != ESP_OK) {
	ESP_LOGE(TAG, "[%s] esp_wifi_start(): %d %s",
   	__func__, err, esp_err_to_name(err));
	return ERR_INTERNAL;
}

err = esp_wifi_connect();
if (err != ESP_OK) {
	ESP_LOGE(TAG, "[%s] esp_wifi_connect(): %d %s",
		__func__, err, esp_err_to_name(err));
	return ERR_INTERNAL;
}

The timeout you see in those functions is my internal timer that stops the wifi connection automatically after 5 seconds if it didn't connect yet - sometimes it just hangs in a "connected" state, but I never receive a IP from the DHCP - which is when my actual code is meant to start, so that never happens.

Well, here comes the weird part, I've been working on other stuff today, so I turned off verbose output and it refuses to connect a lot - without a restart, but the moment I turn on verbose log output it works "fine" - like my previous logs, connecting after a few attempts. I'm starting to think there are some timing issues in the wifi code, otherwise that wouldn't make sense (log output to UART is painfully slow)
Which would also coincide with a weird issue I've been experiencing for a long time now, and that is ESP_ERR_WIFI_STOP_STATE errors in the WIFI_EVENT_STA_STOP event, meaning it's not stopped yet, but I receive an event anyways.. which is really hard to work around btw. Discussed here - I actually never got a reply on that.. I should follow that up here on github I guess.

Here's the normal failures I tend to see: https://gist.github.com/istokm/c5269a1cf7874d899ca9087d48d2ca19
I just stopped it after 60 seconds because I was bored.

Edit:
I've managed to get it to refuse to connect a large amount of times on info debug level, here
I've also noticed that reflashing, or especially erasing the flash, and flashing the code fresh increases the odds of a failure - maybe something to do with the NVS?

[HarveyRong-Esp]

Hi @scubachristopher,

Can you post the 2.4G and 5G configuration of the router here?
Can you provide a wireless packet capture corresponding to the unconnected wifi log?

The recommended Macbook's built-in packet capture tool does not require a packet capture card. It can be used to capture 802.11a/b/g/n/ac packets:
https://osxdaily.com/2015/04/23/sniff-packet-capture-packet-trace-mac-os-x-wireless-diagnostics/
Or you can use the tutorial on the official Espressif website to capture packets using Wireshark
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wireshark-user-guide.html

[scubachristopher]

Hi @HarveyRong-Esp,

Tried to recreate the problem and, if course, after many attempts with 2 different boards, I have been unsuccessful. But this is REAL.

Here are my router settings for my Synology AC-2600:

Perhaps @istokm is able to do what you're asking. Apologies.

[HarveyRong-Esp]

HI @scubachristopher,

Have you tried to capture unencrypted wireless packets?

[scubachristopher]

Hey @HarveyRong-Esp,

Find the attached pcaps for both 5GHz and 2.4GHz. I reset the esp32 during these captures and saw it re-attach successfully. Hope this helps.

MacBook Air_ch3_2020-10-22_08.23.14.209.pcap.gz
MacBook Air_ch44_2020-10-22_08.21.36.552.pcap.gz

[HarveyRong-Esp]

@scubachristopher, @istokm,

D (6543) wifi:auth timeout I (6543) wifi:state: auth -> init (200)

This seems to be the connection failure caused by the ESP device not receiving the auth within the specified time.

There are two possibilities for not receiving auth:
1.The AP does not send auth.
2. The AP sent the ESP but did not receive it.

It can be analyzed by capturing packets.

@scubachristopher, Sorry, because the captured packets you provided are encrypted, I cannot view the relevant information. Can you provide unencrypted wireless data packets?

[ghost]

I apologize, but I currently have no way of capturing packets... I'll post a capture as soon as I can.
@scubachristopher You need to disable the password on your AP so that the packets are not encrypted. I did try it on the same setup, but without a password (and hidden SSID), and it still exhibits quite a lot of trouble connecting.

[scubachristopher]

@HarveyRong-Esp,

Hmm -- I am able to open these in Wireshark. Not experienced with packet capture tools, but I've installed Wireshark and did a few more captures. I am able to open and view them, as well as the old ones.

Can you try viewing them in Wireshark?

[HarveyRong-Esp]

Hi, @scubachristopher, can you provide some information?

1. sdkconfig
2. Device Log corresponding to the captured packet. Log level is Info
3. Unencrypted AP. AP is set to open mode

[scubachristopher]

Hi @HarveyRong-Esp,

Tried for hours to repeat the scenario and I cannot, unfortunately.

1). sdkconfig.gz

2).

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac

Fw Version: 1.000
Restarts = 872
EEPROM checksum valid: magicGUID is (lri) ssidSTA is (Christopher), passwordSTA is ()
ESP Network name is (Box-5452-v1000), Box ID is (ESP_3C:71:BF:8C:3E:60)
Attempting to connect to Wifi Station (Christopher) with password ()
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 0 - WIFI_READY
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 14 - AP_STOP
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 15 - AP_STACONNECTED
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 15 - AP_STACONNECTED
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:353] _eventCallback(): Reason: 202 - AUTH_FAIL
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 7 - STA_GOT_IP
[D][WiFiGeneric.cpp:381] _eventCallback(): STA IP: 192.168.1.227, MASK: 255.255.255.0, GW: 192.168.1.1
Not successful getting local time: 1970-01-01 01:00:06
Connected to Wifi: (Christopher) MAC: (3C:71:BF:8C:3E:60) IP: (192.168.1.227) ESP hostname: (Box-5452-v1000) public IP: (69.207.163.85)
SoftAP (LRI_ESP_3C:71:BF:8C:3E:60) IP address is (192.168.4.1), AP MAC address is (3C:71:BF:8C:3E:61).  Web server listening on port 80
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 15 - AP_STACONNECTED
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 14 - AP_STOP
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 14 - AP_STOP
Wakeup was not caused by deep sleep: 0
SETUP COMPLETE.
[V][ssl_client.cpp:56] start_ssl_client(): Free internal heap before TLS 161904
[V][ssl_client.cpp:58] start_ssl_client(): Starting socket
[V][ssl_client.cpp:93] start_ssl_client(): Seeding the random number generator
[V][ssl_client.cpp:102] start_ssl_client(): Setting up the SSL/TLS structure...
[V][ssl_client.cpp:115] start_ssl_client(): Loading CA cert
[V][ssl_client.cpp:163] start_ssl_client(): Loading CRT cert
[V][ssl_client.cpp:170] start_ssl_client(): Loading private key
[V][ssl_client.cpp:180] start_ssl_client(): Setting hostname for TLS session...
[V][ssl_client.cpp:195] start_ssl_client(): Performing the SSL/TLS handshake...
[D][ssl_client.cpp:208] start_ssl_client(): Protocol is TLSv1.2 Ciphersuite is TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
[D][ssl_client.cpp:210] start_ssl_client(): Record expansion is 29
[V][ssl_client.cpp:216] start_ssl_client(): Verifying peer X.509 certificate...
[V][ssl_client.cpp:225] start_ssl_client(): Certificate verified.
[V][ssl_client.cpp:240] start_ssl_client(): Free internal heap after TLS 120156
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
Secure MQTT connected, subscribed to (LRI/All) and (LRI/ESP_3C:71:BF:8C:3E:60)
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
MQTT buffer allocated of size 1000 bytes
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
[V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request...
Heap summary for capabilities 0x00001000:
  At 0x3ffbdb28 len 52 free 0 allocated 4 min_free 0
    largest_free_block 0 alloc_blocks 1 free_blocks 0 total_blocks 1
  At 0x3ffb8000 len 6688 free 0 allocated 6208 min_free 0
    largest_free_block 0 alloc_blocks 28 free_blocks 0 total_blocks 28
  At 0x3ffb0000 len 25480 free 0 allocated 24768 min_free 0
    largest_free_block 0 alloc_blocks 42 free_blocks 1 total_blocks 43
  At 0x3ffae6e0 len 6192 free 0 allocated 5856 min_free 0
    largest_free_block 0 alloc_blocks 18 free_blocks 1 total_blocks 19
  At 0x3ffaff10 len 240 free 0 allocated 120 min_free 0
    largest_free_block 0 alloc_blocks 5 free_blocks 1 total_blocks 6
  At 0x3ffb6388 len 7288 free 0 allocated 6920 min_free 0
    largest_free_block 0 alloc_blocks 21 free_blocks 0 total_blocks 21
  At 0x3ffb9a20 len 16648 free 24 allocated 15536 min_free 4
    largest_free_block 0 alloc_blocks N64 free_blocks 5 tota[V][ssl_client.cpp:279] send_ssl_data():l Writing HTTP request...
_blocks 69
  At 0x3ffcad20 len 86752 free 6832 allocated 77648 min_free 64
    largest_free_block 4376 alloc_blocks 135 free_blocks 17 total_blocks 152
  At 0x3ffe0440 len 15072 free 7752 allocated 6752 min_free 680
    largest_free_block 2648 alloc_blocks 31 free_blocks 7 total_blocks 38
  At 0x3ffe4350 len 113840 free 48544 allocated 65184 min_free 43732
    largest_free_block 48544 alloc_blocks 4 free_blocks 1 total_blocks 5
  Totals:
    free 62868 allocated 209236 min_free 44480 largest_free_block 48544

3). ESP_successful_dual.pcapng.gz

I tried toggling 5GHz on the router on and off, rebooted as well. Now, of course, I cannot repeat the issue.

:/

[ghost]

If someone has written a convenient ESP32 code for capturing packets I could try and get the logs and captures that you need - I just don't have the time to write a packet capture tool (that doesn't use a SD card, as I don't have any SD equipped dev boards around), and I also don't have any other packet capture capable devices.

[HarveyRong-Esp]

@scubachristopher, There is no problem with sdkconfig. It is the default configuration. Can both Log and data packets be connected normally?

We have purchased Synology AC2600 on the Amazon platform, but due to customs and other issues, we need to deliver it at the end of the month. Once delivered, we will try to reproduce the problem locally.

[scubachristopher]

Yeah all connects normally now. Unclear what was going on, apologies for not getting a pcap when it was happening.

I was thinking about what @istokm said above:

I've also noticed that reflashing, or especially erasing the flash, and flashing the code fresh increases the odds of a failure - maybe something to do with the NVS?

I did add protection for my EEPROM-stored credentials in my project, as I do switch between different boards. Not sure if that's relevant, as I don't know what dependencies Wifi libraries have on stored data. But that might be a clue.

Since I've implemented validation checks (magic string + checksum), I haven't seen it...

[HarveyRong-Esp]

Hi @scubachristopher , Our Synology AC2600 has arrived, unfortunately I cannot reproduce it locally.
I think this may be related to the router can be configured to 2.4G/5G automatic switching mode. When the ESP32 connection route fails, it may be caused by the router being in the 5G frequency band.

[scubachristopher]

@HarveyRong-Esp, yes, my router is configured with dual-band enabled, a single SSID.

I am not familiar with the ESP32's Wifi hardware, but I wonder: if the device is only capable of 2.4GHz, how could a 5GHz station create a problem?

Disappointing that we both cannot reproduce it. But it is real.

Deeply appreciate your effort to solve this -- thank you for putting the effort into this.

[HarveyRong-Esp]

@scubachristopher, I suspect that the 2.4G/5G option is automatically selected for routing and not 2.4G and 5G exist at the same time, switch to a certain frequency band according to the scene at the same time。When the 5G frequency band is selected for routing, 2.4G does not actually exist. Since the ESP32 device does not support 5G, the device connection may fail.

[AxelLin]

When the 5G frequency band is selected for routing, 2.4G does not actually exist. Since the ESP32 device does not support 5G, the device connection may fail.

It should be very easy to verify it.
e.g. Use a 5G device to join AP first, then...
You can use some tool (e.g. wifi analyzer app) to check if you can still find the AP in 2.4G.
You can also check if other 2.4G devices (non esp32 devices) works or not, to clarify if it's esp32 issue or not.

[scubachristopher]

Guys, what I meant was "since the ESP32 doesn't support 5GHz, how is this happening?"

[HarveyRong-Esp]

Yes, esp32 doesn't currently support 5G frequency band.

[HarveyRong-Esp]

Hi @scubachristopher ,
Since we are currently unable to reproduce the issue, can we close the issue now?
if it can be reproduced, please feel free to reopen and provide Log and non-encrypted wireless packet capture?

[QuentinFarizon]

Our customers with dual-band router with same SSID all have this issue, this ticket should still be open.

We use SDK v4.3.2

[doom369]

Yes. The issue is still there.

[tibbis]

We have the same problem but with several 2.4GHz routers with the same SSID name. do you also have several routers (mesh) with the same name or only one with 2.4+5ghz?

[jBernavaPrah]

Yes, confirming that is still present. I was unable to connect until I disabled the 5ghz on my router.

More information that I found during my tests in order to successfully connect to my router:

• Before reading this thread, I tried to connect at least 50 times (in loops, with reset the esp, manually, ecc), but every time the connection failed (I was also thinking that my esp was broken).
• Doing a scan with both bands enabled, the ssid of my router was found. (Unfortunately, I did print the bssid, so I don't know which specific band was found.)
• After disabling the 5ghz the connection magically worked and I was connected to the router.
• If I leave only the 5ghz enabled, doing a scan will not show my ssid.
• If I leave only the 4ghz enabled, doing a scan will show my ssid and the bssid, correctly.
• After disabling, connecting and enabling the 5ghz again (and left enabled with the 2.4ghz), the esp connects correctly to the router every time.

I hope this will help on find a working solution.
Thanks!

[jeffreyameyer]

Hi - adding to this thread here with an additional use case: trying to get ESPresence working with a Google WiFi network (no control over 2.4GHz / 5GHz bands, multiple 2.4GHz BSSIDs). In this environment, if I successfully set up a device in my office and then try to move it to another room, there's a very small chance it will wake up and associate properly. If I instead go to a physical location where I plan to deploy an ESP32 sensor and then reset the wireless from there, I can improve those odds, but it would be nice to be able to just give an SSID and have the ESP32 manage across all the different BSSIDs associated with that SSID.

My ESP: AITRIP 5PCS ESP-WROOM-32 ESP32 ESP-32S Type-C USB

Here's a little more info on my network and my setup:

scubachristopher - am I missing something here? I looked for another ticket, but couldn't find one - if this is appropriate, should we reopen or start a new issue?

[AxelLin]

@HarveyRong-Esp @Alvin1Zhang
Many people report this issue (see above) , I'm wondering if this issue should be re-opened or you prefer people to create a new issue?

[Fedack]

Yeah, I'm also experiencing the same. It's very frustrating and causes big headaches because now it's standard.

[Irfan93]

So I might be experiencing these at few sites. But I haven't look into it deeply yet. I do know a site that uses Ubiquiti routers seems to cause this a lot often than other routers so far.
What would be the best way to get debugs, logs, data on this issue?

[abhishekbn]

We are experiencing a similar issue with the Google Nest Wifi and unfortunately, we can't get enough debug data as it's in the field and we can't get any logs. The behaviour that we are experiencing is, every time the device reboots, it connects successfully to the given credentials and it drops the connection after 10-15 minutes of the reboot and it fails to connect back again.
Is there any solution to this issue? @HarveyRong-Esp, looks like many are facing this issue. Can we please get some help from ESP folks?
Thanks

[bad-jesus]

We also have hundreds of issues where customers are having this issue on select equipment in dual band and have not been able to track it down to anything specific. Only occurs with our esp32-wroom product. Other 2.4ghz only devices have no issues.

[Xiehanxin]

hi @bad-jesus @abhishekbn @Irfan93 could you provide some details, I wonder if there is just one dual-band router or there are some routers

[scubachristopher]

@Xiehanxin: Are you joking? Is there not enough data above on this issue that has hung out there for 3 YEARS?

[bad-jesus]

@Xiehanxin: Are you joking? Is there not enough data above on this issue that has hung out there for 3 YEARS?

Going to have to agree here.
The data on this post, and hundreds of others online is quite abundant. All with proper tests and some data logging.

We have issues with a lot of ISP specific routers here in Canada and our US customers also experience issues with various products including Cisco/Meraki and Ubiquiti. We find that these brands are MORE stable but always rock solid when bands are split into different SSID's.

A lot of cheaper products by Linksys also have this issue. TP link seems to be rock solid across the product types we have tried. Orbi also has this issue.

You should not need any of us to provide more data at this point. It's been years, it's THOUSANDS of conflicts. I am not sure what more you need.

The Espressif C5 can not come out fast enough. It keeps being pushed and it's ridiculous. We should have this in testing NOW.

[DCStrato]

It is not router specific but VERY device specific. I have four identical ESP32-S3FN8 sitting next to each other and three will perform an initial connect every time to my dual band rounter. One will not. Multiple retries after a delay does get it to connect, because it seems to work only after it has first failed to work. Wifi.begin() with no SSID, PASSWORD after a successful login is much more reliable. I have not worked with the ESP32 since the first version, but remember having this same issue years ago. Figured it would have been fixed by now.

[DheeranYuvaraj]

Hi,

Anyone find the Solution?

[tank104]

@tibbis I am getting the issue like you - when its a mesh setup it is really unstable. Turn off the mesh (i.e. only one wifi access point) and it works fine.

Not sure how wifi drivers are supposed to handle mesh networks, but seems ESP32 S3 has an issue with it.