mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 09:05:56 +03:00
[GH-ISSUE #979] ESP32 shows captive portal every second time #833
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#833
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 @ElToberino on GitHub (Dec 8, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/979
Basic Infos
Hardware
WiFimanager Branch/Release:
Esp8266/Esp32:
Hardware: ESP-12e, esp01, esp25
**ESP32 Core Version:
current
Description
There is a problem with WiFi-Connections of ESP32 in combination with certain routers/APs.
The issue is described here: https://github.com/espressif/arduino-esp32/issues/2501#issue-413808401
A WiFi connection can only be established on every second attempt. A far as I know, the reason for that bug is still unknown. There are some workarounds for that problem, but they are not perfect and they don't work using WiFiManager.
WiFiManager (with saved credentials!) connects only every second time - the other times it starts the ESP32-AP with the captive portal.
If you're facing this ESP32 issue, you can't use WifiManager. I know that this issue isn't caused by WifiManager itself, but I'd like to ask if a workaround for that issue could be implemented or how I could use WifiManager anyway.
@tablatronix commented on GitHub (Dec 8, 2019):
This sounds like a not real bug, or a very specific edge case.
Have you done an NVS erase?
Are you using the lastest staging esp32 lib ?
Are you using rev 0 hardware?
@tablatronix commented on GitHub (Dec 8, 2019):
You would have to provide some detailed logs with debugging on and maybe wireshark logs if possible.
@TheNitek commented on GitHub (Feb 16, 2020):
I'm having the same issue using my ESP32 with a FritzBox. Without the WifiManager I just have to call WiFi.disconnect(); once if the connection attempt fails and try to connect a second time. With WifiManager (develeopment branch) I'll just end up in AP mode.
Log looks like this:
*WM: [2] ESP32 event handler enabled
*WM: [2] Connecting as wifi client...
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set
*WM: [3] WIFI station disconnect
*WM: [1] Connecting to SAVED AP: ***
*WM: [3] Using Password: ***
*WM: [3] WiFi station enable
*WM: [1] connectTimeout not set, ESP waitForConnectResult...
*WM: [2] [EVENT] WIFI_REASON: 202
*WM: [2] Connection result: WL_CONNECT_FAILED
*WM: [3] lastconxresulttmp: WL_STATION_WRONG_PASSWORD
*WM: [3] lastconxresult: WL_STATION_WRONG_PASSWORD
*WM: [1] AutoConnect: FAILED
*WM: [2] Starting Config Portal
*WM: [2] AccessPoint set password is VALID
@TheNitek commented on GitHub (Feb 16, 2020):
This seems to work:
(For some reason I had to add the
WiFi.mode(WIFI_OFF);line to make it work)@tablatronix commented on GitHub (Feb 16, 2020):
So it sounds like autoconnect is not connecting for some reason the first time, it says connect failure 302, are you using an up to date esp32 lib?
This is rather strange and almost defiantly a esp32 bug or race condition.
Did you erase nvs ?
Also you realize configportal will timeout if you set it to do so.
@TheNitek commented on GitHub (Feb 18, 2020):
I am up to date on wifimanager and esp32 platform.
I'm quite sure it's a platform issue ( https://github.com/espressif/arduino-esp32/issues/2501#issue-413808401 )
I don't think the configportal timeout will help, because it still won't be connected
@tablatronix commented on GitHub (Feb 18, 2020):
I never have this issue, are you sure you guys are erasing your esps
@tablatronix commented on GitHub (Feb 18, 2020):
try now, fetch latest
@TheNitek commented on GitHub (Feb 19, 2020):
Works like a charm now using setCleanConnect(true). Thank you very much!
@tablatronix commented on GitHub (Feb 19, 2020):
That is what it was before, I turned it off... lol you just turned it back on
@TheNitek commented on GitHub (Feb 19, 2020):
Ok, now you got me confused :-D
So I gave it another try and actually neither "true" nor "false" work: After every 2 seconds reset the portal opens up. If I just reset again (without doing anything) it connects fine.
Still wonder what I tested earlier but probably it(/I) didn't flash the most current firmware
@tablatronix commented on GitHub (Feb 19, 2020):
Interesting, I was having issues with reconnects also but they went away when I removed that disconnect. Could be a race condition, what if you add a delay(2000) before autoconnect?
@tablatronix commented on GitHub (Feb 19, 2020):
Do you have anything in your code that could be starting wifi before wm starts wifi, sometimes that causes issues.
You might also want to enable esp wifi debugging and log everything
I will keep testing also
@TheNitek commented on GitHub (Feb 20, 2020):
There is nothing happening before the wm starts and a delay does not seem to help. Me feeling is that his is highly depending on the access point type and it's key handling.
I'll try to collect debugging logs.
@TheNitek commented on GitHub (Feb 20, 2020):
results in
Wild guess: The ESP stores some credentials for faster reconnection without full authentication with the WiFi after DeepSleep/Reset. These seem to expire for some reason (maybe that's where the router model comes into play) and the AUTH_FAIL is required for the ESP to realize that is has to connect using the PSK again.
@tablatronix commented on GitHub (Feb 20, 2020):
Never heard of anything like that, are you using deep sleep? or just reseting, can you post a full log of it working then not working ? do you have esp debugging turned on ?
You are not doing anything else? setting hostname or static ip ?
@TheNitek commented on GitHub (Feb 20, 2020):
I read about this quite some time ago, so I am not 100% sure I remember correctly.
Currently I am not using deep sleep, just reset. The code I posted is the only wifi related code.
@tablatronix commented on GitHub (Feb 20, 2020):
Nice, and you are using esp32 staging from github?
@tablatronix commented on GitHub (Feb 20, 2020):
Have you tried disabling sleep.
@TheNitek commented on GitHub (Feb 20, 2020):
It's release 1.11.2 through platform.io
What do you mean by "disabling sleep"?
@tablatronix commented on GitHub (Feb 20, 2020):
WiFi.setSleep(false);@tablatronix commented on GitHub (Feb 20, 2020):
You did a full erase etc?
@TheNitek commented on GitHub (Feb 20, 2020):
Disabling sleep seems to do the trick:
I don't do a full erase everytime I flash, no.
@tablatronix commented on GitHub (Feb 20, 2020):
no not everytime just once is good when changing sdk and esp versions
@tablatronix commented on GitHub (Feb 21, 2020):
https://github.com/espressif/arduino-esp32/issues/2501
Definitely something going on here in SDK. Seems to be something with NVS
@tablatronix commented on GitHub (Feb 21, 2020):
Let me know how stable you are now with no sleep
@TheNitek commented on GitHub (Feb 21, 2020):
Yesterday the no sleep looked fine, today it does not anymore (?!). I feel like it changed the behaviour from "every second time" to "every now and then"
@tablatronix commented on GitHub (Feb 22, 2020):
Lol to me that sounds like a race condition for sure. Very hard to debug, ill keep looking for hints, I wonder if we can turn off nvs and connect with credentials each time just to see
@tablatronix commented on GitHub (May 11, 2020):
I have been having issues where waitforconnectresult takes the entire timeout period, something is definitely wrong with routers allowing reconnect or esp lib..
@tablatronix commented on GitHub (May 25, 2020):
#1067
@fhpa-git commented on GitHub (Sep 15, 2020):
Hi to everybody,
I have/had the same issue too since many months. I am using a Fritzbox 7590. Up to now i always connected my ESP32 wifi through the fritzbox.
But just minutes ago i connected via an extra access point from Fritz-LAN to a different WLAN. And my problem went away. I checked an started many times...
The extra access point is a TP-LINK TL MR3020 V1.9
best regards & good luck
fhpa-git
@tablatronix commented on GitHub (Nov 19, 2020):
I added capability to add retries to autoconnect, hope it helps someone, feel free to test it
@Patronics commented on GitHub (May 3, 2021):
This fixed (or successfully worked around, at least) this issue for me, thanks!
Interestingly, it seems to consistently fail twice, and succeed on the 3rd reconnect attempt. Also, when will you be releasing the next release? It adds some complexity to need to install from git instead of from the boards manager directly (and your 2.0.3 alpha release didn't have the retries feature).
@lyricnz commented on GitHub (Nov 24, 2024):
FWIW I have the same symptom (connects every second boot, with 100% reliability). Adding the retries didn't help for me. The AP password is 100% correct, and it connects cleanly every second time.