Open marchingband opened 2 years ago
We have similar issues were the ESP32 drops its connection and in many cases it wont reconnect until you do a power cycle. This tends to only happen on mesh systems only.
How is this related to WM?
Because flakiness on repeater systems can be improved with changes in the WiFi initialization process which is all in the wm code.
What changes?
It's been a long time, I forget now. They were very technical, and there were lots of slightly different opinions that came up when I did my research online. Are you the library maintainer? I'd be happy to help dig up that research again if it helps.
Yes, and I am not familiar with any issue like this, why did you open an issue if you have no details or debug logs?
The only thing I know of that affects wifi, and I have no idea why mesh or repeaters would matter, unless there is some low level phy stuff that can be tweaked, ttl power level, , which can still be done nothing is stopping you.. Is adc and interrupts or known esp bugs like core issues interfering with wifi.
Your code is way to complex to even look into this, but would need a minimal example
I have no debug logs because like my post says, I havnt reproduced the issue locally. I only have reports from users of my device, and many others online reporting similar issues with repeater networks. I posted the code I have because that's what your issue submission asked for. I don't think anything in my code is the cause. Repeater networks are not very common, and the fix I found was something I thought you would want to implement in your library. If you like, I can do that research again and post some links to the solutions here. Otherwise you can close the issue if you aren't interested.
Someone reports that using WiFi.begin(ssid,pass, 0,0,true) fixes the issue. I do not understand why, just FYI.
I see, I didn't know what you meant by customers.
Those are the defaults
wl_status_t begin(char* ssid, char *passphrase = NULL, int32_t channel = 0, const uint8_t* bssid = NULL, bool connect = true);
This sounds like a workaround for an esp bug that affected bssid scanning. hard to tell there were many of them
https://github.com/espressif/arduino-esp32/issues?q=is%3Aissue+WIFI_ALL_CHANNEL_SCAN+is%3Aclosed
have you tried
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
before using wifi
I havnt tried anything. I may ask one of the users which brand of mesh repeater they are having problems with, purchase it, and go into trying to reproduce and debug. It's a bit beyond my skill set to go into the lower level networking code, so I had hoped you, or someone else here, may know more, or have experience with this situation, and we could perhaps put a fix into the library, so others don't face the issue. These mesh networks are gaining popularity so it could become a bigger issue soon, if Arduino doesn't solve it upstream.
I think you just need multiple aps with the same ssid, not necessarily a mesh.
If you sell wifi devices you should defineltly have a wifi lab. I use use cheap linux boxes with wifi adapters and just start up ad hoc networks
Well that’s a very common scenario, SO many people have some kind of a range extender in the home. If this bug effects all of them that is a big deal indeed!
I have been selling wiFi dev boards for a few years, but only just started selling consumer items, and this is the first time I've encountered an issue. I think you're right I need to improve my WiFi test equipment. In the meantime, are you able to reproduce the issue in your lab? If there is a 1-line fix, would it make sense to patch it into the WM lib?
I mean to test this issue, you do not need special mesh hardware I think you only need multiple aps with identical ssids.
I can add a option to allow roaming
, this is not a fix, but an option in ESP wifi.. but this can just be added to user code or set via a param
I don't understand enough about the issue to say exactly, but my feeling is that WM should work with repeaters by default, and if there is some other reason the setting should be different (ex. roaming?), it should be set via a config option to WM, with a note in the example code, or somewhere similar, stating that it will break repeater home networks.
It sounds like I could get a few ESP32 modules in AP mode, all advertising with the same network name, and then one ESP32 to join one of those networks, examine logs from this client ESP32, and likely reproduce this bug, is that accurate?
I am pretty sure this is just a wifi thing, esp library grabs the first AP and not the best one. Its not a bug its just how it works, to make connections faster. So you have to choose a better scanning option or lock to BSSID
WM has nothing to do with wifi, all esp wifi features are available via the native methods still.
I have some ideas though, but ultimately this is an ESP issue.
We really have to let the end user decide which one to choose, we can assume if there are duplicates that this is a mesh and force the option, which is probably the easiest change, the better one is to offer a checkbox in the GUI to lock to that ap BSSID
FYI,
An issue I opened up is similar to the one in this ticket, I use Google WiFi:
It seems unlikely to cause anyone problems to implement the easy route you outlined above, a checkbox would be great, but I would think defaulting it to checked (assume it's mesh) would be the best choice. These mesh networks are getting very popular.
Am I right in my understanding that this issue arises (also for me!) from the fact that WiFiManager is storing the credentials via the esp-idf functions and restores them using WiFi.begin()
, which stores not only the ssid but also the bssid and thus does not do a rescan on reconnect?
There was some changes recently to the default scan method on esp32. So yes wm uses whatever esp arduino does. There is now a parameter to change the scan method for faster connections. But I do not thinnk the bssid is saved unless you specify, I have to recheck this though
I started looking into a reasonable fix for this either way its a pita as we have to pass yet another option though
I havnt tried anything. I may ask one of the users which brand of mesh repeater they are having problems with, purchase it, and go into trying to reproduce and debug. It's a bit beyond my skill set to go into the lower level networking code, so I had hoped you, or someone else here, may know more, or have experience with this situation, and we could perhaps put a fix into the library, so others don't face the issue. These mesh networks are gaining popularity so it could become a bigger issue soon, if Arduino doesn't solve it upstream.
Hi, has this issue made any developments? I too am experiencing this issue on Mesh networks. Embarrassing as you say. But in my case the users report they have no connectivity after initial credential saving.
Customers router is a Nighthawk Mesh6. The esp32 is visibly connected on the network via the router login page. But a ping returns no packets.
Basic Infos
I have a program using WiFiManager that works very well on most systems, however customers who have a WiFi repeater, mesh network type WiFi system have reported frequent dropped connections.
Hardware
WiFimanager Branch/Release: Master
Esp8266/Esp32:
Hardware: ESP32 WROVER
Core Version: 2.4.0
Description
Problem description
Settings in IDE
Module: Arduino
Additional libraries:
Sketch
Debug Messages