Problematic WiFi connection to certain types of AP's

[wibbit]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• [n] I have tested that the issue is present in current master branch (aka latest git). Tested against 3.1.2 not sure how to test against latest.
• I have searched the issue tracker for a similar issue.
• [na] If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [ESP826EX - Lolin D1 Mini v4 (and v3)]
• Core Version: [3.1.2 release, not sure how to update to latest]
• Development Env: [Arduino IDE]
• Operating System: [Fedora 37]

Settings in IDE

• Module: [Wemos D1 mini r2]
• Flash Mode: [Default, not sure]
• Flash Size: [4MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [dtr]
• Flash Frequency: [40MHz]
• CPU Frequency: [80MHz]
• Upload Using: [SERIAL]
• Upload Speed: [115200]

Problem Description

I'm having issues getting the ESP8266EX to connect to one of my WiFi AP's, this is an Asus RT-AX86U Pro, it has no issues connecting to an older Asus model that is also providing WiFi for the same SSID.

I've put together a minimal sketch to try and help debug this issue, and the output that I get is as at the end.

FYI, I did try going to the esp8266 forum, however, there appears to be a problem with my registration (no email was received).

I see several other tickets raised relating to something similar #7965 #8299 and I've tried both fixes and changes that appear to have helped them, most notably.

WiFi.setPhyMode(WIFI_PHY_MODE_11G); <- Added both before and after WiFi.begin, which no change

And changing the board to esp8266 generic, and changing to nonos-sdk2.2.1+61 (190313)

MCVE Sketch

#include <ESP8266WiFi.h>

void setup()
{
Serial.begin(115200);
Serial.setDebugOutput(true);
Serial.println();

WiFi.begin("HumptyDumpty", "Not_A_Real_SSID_for_me_at_least");

Serial.print("Connecting");
while (WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.print(".");
}
Serial.println();

Serial.print("Connected, IP address: ");
Serial.println(WiFi.localIP());
Serial.printf("Wi-Fi mode set to WIFI_STA %s\n", WiFi.mode(WIFI_STA) ? "" : "Failed!");
Serial.printf("Connection status: %d\n", WiFi.status());
WiFi.printDiag(Serial);

}

void loop() {}

Debug messages go here

I have the following information from my router, which may be helpful
Stations List

idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
7C:87:CE:BE:20:D4 Yes Yes -56dBm g No No No No 1 20M 54M 1M 00:00:03

So, I don't believe signal strength is an issue.

connected with HumptyDumpty, channel 6
dhcp client start...
ip:192.168.1.250,mask:255.255.255.0,gw:192.168.1.1
switch to channel 1
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 33
cnt

connected with HumptyDumpty, channel 6
dhcp client start...
ip:192.168.1.250,mask:255.255.255.0,gw:192.168.1.1
switch to channel 1
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
scandone
no HumptyDumpty found, reconnect after 1s
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 26
cnt

connected with HumptyDumpty, channel 6
dhcp client start...
ip:192.168.1.250,mask:255.255.255.0,gw:192.168.1.1
switch to channel 1
bcn_timout,ap_probe_send_start
pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 25
cnt

[castrofernando]

I'd like to see this response too. I'm also facing same problem. There are routers that it connect perfectly and other simply never connect.

[TD-er]

Try forcing the ESP to only use 802.11g

Make sure the router/access point allows clients to connect in "g" mode and thus not set to be "N-only".

[asturcon3]

Same here. 321 esp's in 50 locations country-wide, each with a random ISP provided router and well, that makes live interesting. Usually a random NONOSDK version makes the trick. On some sites it was impossible, I had to send them a cheap 2.4 AP to make it work.
Of course, every of those routers have exactly 0 issues with any random smartphone or wifi camera my customer has.
BTW, my code cycles phy-mode. That's not the problem.

[TD-er]

There are other tricks you can try:

• Add delay(1000); right after a call to WiFi.begin()
• Enable WiFi.setAutoConnect(...) and/or WiFi.setAutoReconnect(...)
• Add delay(100); right after each WiFi command you call which might do something to the WiFi radio (e.g. set mode, etc)
• Explicitly call WiFi.disconnect(); before WiFi.begin();
• Force 802.11g as I mentioned.

[wibbit]

So, for me, updating the code to include the delay(1000) right after WiFi.begin() appears to result in a reliable connection each time.

[wibbit]

This may not be the right place, but could anyone perhaps point me in the right direction of adding the delay when using WifiManager?

[php4fan]

So, for me, updating the code to include the delay(1000)
right after WiFi.begin() appears to result in a reliable connection each time.

@wibbit can you confirm (now that some time has passed) that this workaround actually worked for you?

I mean, that it wasn't just a coincidence and then the issue reappeared later?

@TD-er what is the rationale behind such a workaround? I mean, in the original code without the workaround, there's a loop with many delays anyway, so it's hard to understand how an additional initial delay can make a difference. Does it have to do with not calling status() immediately after begin()?

[TD-er]

I've noticed that whenever you make a call to a function in the WiFi class which actually does something to the hardware, it may not be done yet when the function returns.
Either the WiFi radio isn't actually stable yet or immediately doing something else may demand too much from the (often poorly designed) power supply on most boards.
Also a lot of stuff is done when calling delay() like processing incoming data, maintaining WiFi connections, processing events, etc.
To illustrate this last claim, you can try running some blocking code which takes > 100 msec which isn't somehow calling delay() or yield() and you will see your WiFi connection is much less reliable.

Anyway, by adding some delay() calls after each WiFi call that actually does interact with the hardware, you will see things go a lot more smoothly.

On some access points you may even need to have automatic reconnect enabled and do like a delay(1000) right after WiFi.begin() to make sure the SDK code has ample opportunity to act on quick disconnects and do a quick reconnect.
I've mainly seen this on Fritzbox, but I doubt it is limited to those.

If I'm not mistaken, MikroTik also uses something similar when using hidden SSID.
At least you should try to connect to those using explicitly the BSSID and channel and cannot try to connect to them the usual way with just the SSID name and password.

Lots of newer APs also try to steer you away to another band or to another access point. But when you force 802.11g on the ESP and don't allow 802.11n (on the ESP), those quick disconnects are no longer attempted by those access points.

[php4fan]

@TD-er ok but consider the code without adding the delay(1000):

WiFi.begin("HumptyDumpty", "Not_A_Real_SSID_for_me_at_least");

Serial.print("Connecting");
while (WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.print(".");
}

Note it already has lots of delay()s.

According to your explanation of how delay() helps, how can all those delays in the loop not already do the trick?

The only difference in adding a single delay(1000) immediately after begin() is that the delay goes between begin() and the first call to status().
Even assuming a lack of delay there might negatively affect the first call to status() somehow, things should become the exact same after the first iteration of the loop, right?

[TD-er]

It is like you're doing this:

WiFi.begin("HumptyDumpty", "Not_A_Real_SSID_for_me_at_least");
Serial.print("Connecting");
do 
{
  delay(500);
  Serial.print(".");
} while (WiFi.status() != WL_CONNECTED);

With the exception that Serial.print() may also cause different behavior.

But I would even go a bit further and do something like this:

WiFi.setMode(WIFI_STA);
delay(100);
WiFi.disconnect();
delay(100);
WiFi.begin("HumptyDumpty", "Not_A_Real_SSID_for_me_at_least");
Serial.print("Connecting");
do 
{
  delay(500);
  Serial.print(".");
} while (WiFi.status() != WL_CONNECTED);

[php4fan]

WiFi.disconnect();

I already do:

WiFi.persistent(false);
WiFi.mode(WIFI_OFF);

before WiFi.setMode(WIFI_STA).

If after that, a disconnect() before begin() makes any difference whatsoever, that would certainly be a bug in itself.

[TD-er]

If after that, a disconnect() before begin() makes any difference whatsoever, that would certainly be a bug in itself.

Well there is one thing you can be sure of and that's that there are bugs in the closed source WiFi code.
So don't make assumptions based on "nah that wouldn't make sense" when thinking about ESP WiFi code.