mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #702] wifi doesn't connect after exiting the captive portal with ESP core 2.4.2 #587
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#587
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 @andysc on GitHub (Aug 16, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/702
This might be for "upstream", but between ESP8266 core 2.4.1 and 2.4.2, connectWifi comes back with WL_IDLE_STATUS (0) and doesn't connect to the newly set wifi credentials.
With 2.4.1, the portal closes itself correctly and the device connects correctly to the new credentials.
With 2.4.2, the same code leaves the portal window open and gives WL_IDLE_STATUS and doesn't connect.
This is with a Wemos R2 D1 mini device.
@tablatronix commented on GitHub (Aug 16, 2018):
what branch?
@tablatronix commented on GitHub (Aug 16, 2018):
you can try development branch and post logs
@andysc commented on GitHub (Aug 16, 2018):
0.14.0
@andysc commented on GitHub (Aug 16, 2018):
(assuming you meant WiFiManager, not ESP core?)
@andysc commented on GitHub (Aug 16, 2018):
yes, development branch of WiFiManager works correctly.
Any chance you could backport that part of the code (startConfigPortal) to the current codebase?
That looks like a huge re-write you're doing in development branch! wow :)
@tablatronix commented on GitHub (Aug 16, 2018):
yeah I have no idea what the issue is to fix though
@andysc commented on GitHub (Aug 21, 2018):
I'll just go back to the earlier version of the core, as I know that works with the current released WiFimanager.
Keep up the great work :)
@andysc commented on GitHub (Aug 21, 2018):
do you "need feedback" from me? #justchecking
@tablatronix commented on GitHub (Aug 21, 2018):
I need debug logs of failure or reproductions
@andysc commented on GitHub (Aug 22, 2018):
OK. This is the console output from when I save the new wifi config to where it goes round again (having failed to connect to the new wifi due to the Connection result 0 (WL_IDLE_STATUS).
How do I turn on more useful debug?
@tablatronix commented on GitHub (Aug 22, 2018):
is this a hidden ap ?
If you get a chance turn on esp debugging wifi level
In development you can try
setSaveConnectTimeout(seconds); to increase the connection wait loop, by default it uses waitforconnectresult, maybe there is a bug in there, or problems with your router
@tablatronix commented on GitHub (Aug 22, 2018):
connect result 0 is idle_status I think, which is weird
( ah i see the first post )
@andysc commented on GitHub (Aug 22, 2018):
No, not hidden - it's the WiFi hotspot on my iPhone - usually works fine.
I tried esp debugging wifi but it just inserted lots of WiFi event 7 into the stream, like this:
Yes, result 0 is WL_IDLE_STATUS, which, yes, is weird.
I'll try changing setConnectTimeout... thanks.
@andysc commented on GitHub (Aug 22, 2018):
That didn't help - I set
wifiManager.setConnectTimeout(5);It just waited 5 seconds then gave the same result...
@tablatronix commented on GitHub (Aug 22, 2018):
have you tried staging master latest ?
Sorry I forgot you said you are using wm master, going to test now
@tablatronix commented on GitHub (Aug 22, 2018):
cannot reproduce with wm master and esp8266 staging
@tablatronix commented on GitHub (Aug 22, 2018):
oh which lwip are you using ?
@andysc commented on GitHub (Aug 22, 2018):
not sure what you're asking - current release of wifimanager with not-released-yet version of ESP core? (sorry, I don't use GitHub very much)
I tried the dev branch of wifi manager with the current release of ESP core and that works fine, so when that's released, all should be good.
lwip is "v2 lower memory"
@tablatronix commented on GitHub (Aug 23, 2018):
Hmm I didnt see any changes to esp core since last release that would have fixed any issues.
Ill test 2.4.2 also.
Maybe try lwip 1.4? There are some outstanding bugs with wifi disconnect/reconnect
@andysc commented on GitHub (Aug 23, 2018):
it's 2.4.2 core that's causing the problem with v0.14 of WiFiManager.
@andysc commented on GitHub (Aug 23, 2018):
no, lwip 1.4 didn't fix it.
BTW, is it possible to change how long it tries to connect before it gives up and goes into captive portal mode? A bit longer would be useful :)
@andysc commented on GitHub (Aug 23, 2018):
ah, that's exactly what setConnectTimeout() does :) TVM
@tablatronix commented on GitHub (Aug 23, 2018):
I wonder if adding a disconnect before begin() in connectwifi would fix this hmm
@andysc commented on GitHub (Aug 23, 2018):
I was just putting some trace into ESP8266WiFiSTA.cpp to explore some things like that :)
Apart from a couple of checks for _persistent mode, it doesn't seem to be any different between 2.4.1 and 2.4.2
@andysc commented on GitHub (Aug 23, 2018):
I also tried putting the mode(STA) before the connection attempt rather than after it's succeeded (which has always seemed inexplicable to me)... that makes the portal window close, but doesn't help the reconnect problem.
@andysc commented on GitHub (Aug 23, 2018):
WiFi.mode(WIFI_STA);, I meant@tablatronix commented on GitHub (Aug 23, 2018):
yeah thats why I suggested lwip.
I just tested this and could not reproduce master branch 2.4.2
@tablatronix commented on GitHub (Aug 23, 2018):
I suspected when it says idle_status it is between modes, or thinks sta is not on.
so disconnect then begin() fixes it ( this is implemented in development branch already )
@andysc commented on GitHub (Aug 23, 2018):
\o/ yay! That worked :)
WiFi.disconnect(false);before the connect.
@tablatronix commented on GitHub (Aug 23, 2018):
pushed to hotfixes as test
@tablatronix commented on GitHub (Aug 23, 2018):
I have no idea what causes this, but this is the workaround, you can test hotfixes branch if you want. Not merging into master just yet, until I know whats going on
@andysc commented on GitHub (Aug 23, 2018):
didn't see your commit before I tried that.
Where is the WiFi_Disconnect() function defined? I get a compile error as it can't find that.
@tablatronix commented on GitHub (Aug 23, 2018):
oops
hmm there is already a disconnect in the code
but only for existing creds
@andysc commented on GitHub (Aug 23, 2018):
where does
wifi_station_disconnectlive? Is that preferred?@andysc commented on GitHub (Aug 23, 2018):
the UART stuff wrapped round it looks a bit like it's probably not preferred ;)
@tablatronix commented on GitHub (Aug 23, 2018):
thats how it is in WiFi.disconnect but I am not sure if its needed for the config saving or the disconnect
@tablatronix commented on GitHub (Aug 23, 2018):
If you use WiFi.disconnect you have to toggle persistent off and stuff or else it can erase your creds.
Not sure what you mean by preferred, I prefer it..
@tablatronix commented on GitHub (Aug 23, 2018):
Hey I added a debug status to hotfixes, if you can test that if you have time and let me know what the debug output says I would appreciate it.
I am curious if it will tell us anything , If it does it might be a way to check for this condition in the future I am curious if status is useful ( there are reasons to not always do a disconnect here, it causes a 2 second delay ) which is bad for battery devices
@andysc commented on GitHub (Aug 23, 2018):
yup - the version in hot fixes works.
The two times that status gets printed, right at the start, and here when it reconnects, it's 0 both times...
@andysc commented on GitHub (Aug 23, 2018):
hmm, hang on, I've done something and it's stopped working again - BRB
@tablatronix commented on GitHub (Aug 23, 2018):
Heh story of my life. Debugging debugs
@andysc commented on GitHub (Aug 23, 2018):
very odd - it's not working now. I think I had the wrong lwip version, but I've tried with 2 and 1.4 and neither work.
@tablatronix commented on GitHub (Aug 23, 2018):
you said you put a mode(sta) before maybe that is what fixed it ?
@andysc commented on GitHub (Aug 23, 2018):
OK ... so it doesn't work for me with your fix:
but it DOES work with my earlier suggestion:
(with lwip 2 and 2.4.2 core)
@andysc commented on GitHub (Aug 23, 2018):
I'll try putting the mode(STA) back in with your version... l8r
@andysc commented on GitHub (Aug 23, 2018):
putting in
WiFi.mode(WIFI_STA);before your debug status line only has the effect of closing the portal window.It still doesn't connect.
I think we might have to go with my fix ;)
@andysc commented on GitHub (Aug 23, 2018):
ah, best to put in the mode change too - otherwise the portal window closes after the device reconnects...
@andysc commented on GitHub (Aug 23, 2018):
OK - actually the mode change doesn't affect the window closing.
so my change to your hot fix is:
@tablatronix commented on GitHub (Aug 23, 2018):
hmm, it is literally the same code
@tablatronix commented on GitHub (Aug 23, 2018):
could it be a race condition ?
add delay(500) after it
SO sorry man, makes no sense, no idea whats going on, I can change it to WiFi.disconnect but probably wrap it in WiFi.persistent(false) to prevent erasing config
@tablatronix commented on GitHub (Aug 23, 2018):
curious have you tried erasing flash or using another esp, did I ask that already ?
@andysc commented on GitHub (Aug 23, 2018):
oh wow, so it is the same code - that's nuts. ...<--- apart from setting the config object... ;)
Yeah - could be race condition - I'll try that.
No, haven't tried either of those things, and no you didn't ask... good call - I'll try that too
@andysc commented on GitHub (Aug 23, 2018):
adding a delay between the disconnect code and the begin didn't help.
@tablatronix commented on GitHub (Aug 23, 2018):
Well what ever works, until someone else reproduces just use whatever you need to
ill try changing it later
@andysc commented on GitHub (Aug 23, 2018):
just had a thought - I'm configuring the same wifi credentials each time (I turn off my wifi hotspot so the ESP doesn't see it, it goes into config portal and then I turn the wifi on and then reconfigure the same wifi settings in WM).
So... in wifi.begin() it checks to see if the config is the same, and does something different (does a set config) if so.
In my case, it is the same (well, as far as SSID/password concerned) so maybe that's causing something?
I erased the wifi credentials and it worked fine. Then the next time it didn't (once I'd set some credentials).
@andysc commented on GitHub (Aug 23, 2018):
aha!
So, with the existing code, when it tries to reconnect it says:
If I go into
Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.2/libraries/ESP8266WiFi/srcand change
ESP8266WiFiSTA.cppin function
begin(...)if (sta_config_equal(conf_compare, conf)) {to
if (0)i.e. so even if the new credentials are the same, it still calls
wifi_station_set_config_currentThen it works! (with your hot fix version of
WiFiManager.cpp).The output this time is:
BTW I couldn't work out how to get the output from that DEBUGV in there to say the STA config is the same, so I replaced it with a
Serial.printlnand it displayed that (before I made the change!) when the wifi credentials were the same. So that confirmed it wasn't calling the set config when the credentials are the same.@andysc commented on GitHub (Aug 23, 2018):
BTW, how do I turn off WM debug? It just seems to be on all the time
@PProvost commented on GitHub (Aug 29, 2018):
Any updates on resolving this with the current ESP Core, etc.? From the thread above, it isn't clear that the hotfix will resolve it. Thanks.
I have confirmed, as @andysc discovered a couple of messages back, that it seems to be caused by re-using the same SSID & creds. Basically, if I full reset the ESP back to the stock AT firmware, it is fine the next time, but once it restarts, we're back to the "Connection result: 0" issue.
@tablatronix commented on GitHub (Aug 29, 2018):
Yeah this is a well know persistent begin bug.
Ill take a look and see. Not sure why you see a different result sometimes. Yeah that is not the best test method either. There are also bugs in wm that are fixed in develoment.
@andysc commented on GitHub (Aug 29, 2018):
my fix (forcing it to call
wifi_station_set_config_current, whatever the wifi settings), is working fine for me.@tablatronix commented on GitHub (Aug 29, 2018):
I know what the issue is I think.
Gonna check
@tablatronix commented on GitHub (Aug 29, 2018):
ok can you post exactly how to reproduce
Is this correct?
@tablatronix commented on GitHub (Aug 29, 2018):
I think this is related to a bug fix I made in 2.4.2
https://github.com/esp8266/Arduino/pull/3798/files
@tablatronix commented on GitHub (Aug 29, 2018):
can you try
WiFi.enableSTA(false);right before the begin()Actually that will probably not work
hmm
@tablatronix commented on GitHub (Aug 29, 2018):
I added some test fix
forcing connect in begin, and some debugging
@PProvost commented on GitHub (Aug 29, 2018):
@andysc - above you mentioned that your fix (forcing it to set...) seems to be working. Did you make that fix against the current release or against the hotfix branch? It is unclear trying to follow the thread how to make the workaround. I don't suppose you have a fork repo with the change already in place? :)
@tablatronix commented on GitHub (Aug 29, 2018):
That was a kludge in esp lib code not wm.
It is the symtom not really a fix
@andysc commented on GitHub (Aug 30, 2018):
I agree it was a kludge ;)
But the WM code was the vanilla 0.14.0 master branch install.
The hack was to a file in the ESP wifi core code
@andysc commented on GitHub (Aug 30, 2018):
re:
>ok can you post exactly how to reproduceYes, that's right
Just to be clear:
After the reconnect fails (because the AP is off), and it enters AP mode,
turn back on the APThen when the CP window opens, your (previously configured) AP is visible.
Select the previously configure AP, enter passwordclick save@andysc commented on GitHub (Aug 30, 2018):
what do you want me to try?
Not the "actually that will probably not work"...
the test fix?
or just this bit?
@tablatronix commented on GitHub (Aug 30, 2018):
yes, and I committed that to hotfixes so you can try the branch if you want
@andysc commented on GitHub (Aug 30, 2018):
now I'm running the right code on the device...
core 2.42 with your hot fix ...
@andysc commented on GitHub (Aug 30, 2018):
(that
STA config unchangedis a line of debug I left in ESP8266STA.cpp (line 149)@tablatronix commented on GitHub (Aug 30, 2018):
oh you might have to add a connecttimeout
mine took a delay to work
I will test again with waitforconnectresult
EDIT
oh its says with timeout.. hmmmmmm
@andysc commented on GitHub (Aug 30, 2018):
I've got a connect timeout of 30...
wifiManager.setConnectTimeout(30);There's a 30 sec gap between these two lines:
@tablatronix commented on GitHub (Aug 30, 2018):
so strange, Do you have esp debugging on ? Is the wifi not doing anyhting, I mean we are calling wifi connect now it should be looking for the ap or something
use debug flag wifi
@andysc commented on GitHub (Aug 31, 2018):
The debug is very boring...
I put debug round the call to
wifi_station_connectjust to check:@andysc commented on GitHub (Aug 31, 2018):
Note if I clear the WiFi credentials (in the IDE), it works great...
(even though the res return code is 6... that looks better than '0' for a successful subsequent connection)
@bepehr commented on GitHub (Dec 3, 2018):
I have same problem too , so i downgrade it to v 0.13.0
@tablatronix commented on GitHub (Dec 3, 2018):
Anyone figure this out?
@andysc commented on GitHub (Dec 4, 2018):
I'm using 0.14.0, but (copied from way up there ^^ ) ...
you need to go into
Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.2/libraries/ESP8266WiFi/src
and change ESP8266WiFiSTA.cpp
in function begin(...)
if (sta_config_equal(conf_compare, conf)) {
to
if (0)
i.e. so even if the new credentials are the same, it still calls
wifi_station_set_config_current
Then it works!
(this is with ESP core 2.4.2)
@bepehr commented on GitHub (Dec 4, 2018):
I just want to confirm @andysc solution is worked for me .
Library : 0.14.0
Esp core : 2.4.0
@andysc commented on GitHub (Dec 4, 2018):
:)
@tablatronix commented on GitHub (Dec 4, 2018):
can you guys debug this and tell me which condition is met, if persistent?
I still cannot reproduce, it must be something in user code that triggers it
( or make a minimal reproduction sketch )
@tablatronix commented on GitHub (Dec 4, 2018):
I will have to reread this but I think the premise is, we turn off sta, then when saving the same wifi we cannot reconnect, because sdk thinks we are already connected, even though we are not, and setting config current does not renable wifi properly.
can you guys try removing the if connect() condition and always do
wifi_station_connect();in there as a work around instead of bypassing the config check and see if that helps also?( I thought this was working in hotfixes already )
@andysc commented on GitHub (Dec 4, 2018):
yes, that is the premise (and the test case... re-configure onto same wifi).
Where is the "if connect()" condition you want us to change?
I'll try it
@tablatronix commented on GitHub (Dec 20, 2018):
a few lines below that other kludge in begin
@andysc commented on GitHub (Dec 20, 2018):
thanks - got distracted - I'll try it this weekend
@quique123 commented on GitHub (Oct 29, 2019):
Did you guys work out the bit where the Esp got disconnected from the successfully configured ssid after exiting the config portal?