mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #1426] WiFi connection drops frequently on mesh style network using repeater #1220
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#1220
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marchingband on GitHub (Jun 5, 2022).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1426
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
@millheat commented on GitHub (Oct 4, 2022):
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.
@tablatronix commented on GitHub (Oct 4, 2022):
How is this related to WM?
@marchingband commented on GitHub (Oct 4, 2022):
Because flakiness on repeater systems can be improved with changes in the WiFi initialization process which is all in the wm code.
@tablatronix commented on GitHub (Oct 4, 2022):
What changes?
@marchingband commented on GitHub (Oct 4, 2022):
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.
@tablatronix commented on GitHub (Oct 4, 2022):
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
@marchingband commented on GitHub (Oct 4, 2022):
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.
@marchingband commented on GitHub (Oct 4, 2022):
https://esp32.com/viewtopic.php?t=17814
@marchingband commented on GitHub (Oct 4, 2022):
Someone reports that using WiFi.begin(ssid,pass, 0,0,true) fixes the issue. I do not understand why, just FYI.
@tablatronix commented on GitHub (Oct 4, 2022):
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);@tablatronix commented on GitHub (Oct 4, 2022):
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
@tablatronix commented on GitHub (Oct 4, 2022):
have you tried
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);before using wifi@marchingband commented on GitHub (Oct 4, 2022):
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.
@tablatronix commented on GitHub (Oct 4, 2022):
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
@marchingband commented on GitHub (Oct 4, 2022):
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?
@tablatronix commented on GitHub (Oct 4, 2022):
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@marchingband commented on GitHub (Oct 4, 2022):
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?
@tablatronix commented on GitHub (Oct 5, 2022):
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.
@tablatronix commented on GitHub (Oct 5, 2022):
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
@tablatronix commented on GitHub (Oct 5, 2022):
#417
@dolanmiu commented on GitHub (Oct 31, 2022):
FYI,
An issue I opened up is similar to the one in this ticket, I use Google WiFi:
https://github.com/tzapu/WiFiManager/issues/1349
@marchingband commented on GitHub (Oct 31, 2022):
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.
@jhbruhn commented on GitHub (Apr 8, 2023):
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?@tablatronix commented on GitHub (Apr 8, 2023):
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
@gpena208777 commented on GitHub (Nov 6, 2024):
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.
@gpena208777 commented on GitHub (Nov 6, 2024):
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.
@emmby commented on GitHub (Aug 2, 2025):
I also have this problem regularly on Google Nest Wifi Pro. I am able to repro myself and can help with logs if that's helpful
@emmby commented on GitHub (Aug 9, 2025):
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN)seems to work around the issue for me on Nest Wifi Pro.@tablatronix commented on GitHub (Aug 10, 2025):
Yeah this a known issue with esp arduino and default scan method, It wont change bssids without a custom scan method