[GH-ISSUE #1711] WiFi settings are not saved if ESP32 is restarted in SaveConfigCallback #1452

New issue

Closed

opened 2026-02-28 01:30:07 +03:00 by kerem · 26 comments

kerem commented 2026-02-28 01:30:07 +03:00

Owner

Copy link

Originally created by @rusty-labs on GitHub (Feb 14, 2024).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1711

Basic Infos

Hardware

WiFimanager Branch/Release: Master

Esp8266/Esp32:

Hardware: Heltec wifi-lora-32-v3

Core Version: 2.4.0, staging

Description

Steps to reproduce

• Connect to AP
• Set incorrect wifi password and save
• Add setSaveConfigCallback to code
• Restart ESP32
• Connect to AP
• Provide correct password and save
• Web shows "Saved" and ESP32 is restarted
• ESP32 is trying to connect to previously provided, incorrect password

Settings in IDE

Module: Heltec wifi-lora-32-v3

Sketch

void saveConfigCallback()
    {
        delay(2000);
        ESP.restart();
    }

        WiFi.mode(WIFI_STA);

        wm.setSaveConfigCallback([&]()
                                 { saveConfigCallback(); });

        wm.setBreakAfterConfig(true);

        wm.addParameter(&paramMqttServer);
        wm.addParameter(&paramMqttPort);
        wm.addParameter(&paramMqttUser);
        wm.addParameter(&paramMqttPassword);

        std::vector<const char *> wm_menu = {"wifi", "exit"};
        wm.setShowInfoUpdate(false);
        wm.setShowInfoErase(false);
        wm.setMenu(wm_menu);

        bool res = wm.autoConnect(_SSID);

Originally created by @rusty-labs on GitHub (Feb 14, 2024). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1711 ### Basic Infos #### Hardware WiFimanager Branch/Release: Master Esp8266/Esp32: Hardware: Heltec wifi-lora-32-v3 Core Version: 2.4.0, staging ### Description Steps to reproduce - Connect to AP - Set incorrect wifi password and save - Add setSaveConfigCallback to code - Restart ESP32 - Connect to AP - Provide correct password and save - Web shows "Saved" and ESP32 is restarted - ESP32 is trying to connect to previously provided, incorrect password ### Settings in IDE Module: Heltec wifi-lora-32-v3 ### Sketch ```cpp void saveConfigCallback() { delay(2000); ESP.restart(); } WiFi.mode(WIFI_STA); wm.setSaveConfigCallback([&]() { saveConfigCallback(); }); wm.setBreakAfterConfig(true); wm.addParameter(&paramMqttServer); wm.addParameter(&paramMqttPort); wm.addParameter(&paramMqttUser); wm.addParameter(&paramMqttPassword); std::vector<const char *> wm_menu = {"wifi", "exit"}; wm.setShowInfoUpdate(false); wm.setShowInfoErase(false); wm.setMenu(wm_menu); bool res = wm.autoConnect(_SSID); ```

kerem closed this issue 2026-02-28 01:30:07 +03:00

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 14, 2024):

I suspect breakafterconfig i will test

<!-- gh-comment-id:1944769013 --> @tablatronix commented on GitHub (Feb 14, 2024): I suspect breakafterconfig i will test

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 14, 2024):

Yeah, if I don't use setBreakAfterConfig my callback is not even called

<!-- gh-comment-id:1944779809 --> @rusty-labs commented on GitHub (Feb 14, 2024): Yeah, if I don't use setBreakAfterConfig my callback is not even called

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 15, 2024):

Ok there're multiple issues

Settings are not saved if no successful connection occurred,

  WiFi.persistent(true);
  ret = WiFi.begin(ssid.c_str(), pass.c_str(), 0, NULL, connect);
  WiFi.persistent(false);

So I toggled off wm.setSaveConnect(false);
I assume if user saves settings, settings should be saved no matter what, and connection procedure should be out of this block

WiFi.persistent(true);
ret = WiFi.begin(ssid.c_str(), pass.c_str(), 0, NULL, false);
WiFi.persistent(false);
// Try to connect here

Other issue is within the UI
Opening configuration portal second time shows my previously selected SSID in gray color and I assumed I don't need to select it again, so I changed only password.
However on the next bootup SSID is empty while the updated password is there

<!-- gh-comment-id:1945144773 --> @rusty-labs commented on GitHub (Feb 15, 2024): Ok there're multiple issues Settings are not saved if no successful connection occurred, ``` WiFi.persistent(true); ret = WiFi.begin(ssid.c_str(), pass.c_str(), 0, NULL, connect); WiFi.persistent(false); ``` So I toggled off `wm.setSaveConnect(false);` I assume if user saves settings, settings should be saved no matter what, and connection procedure should be out of this block ``` WiFi.persistent(true); ret = WiFi.begin(ssid.c_str(), pass.c_str(), 0, NULL, false); WiFi.persistent(false); // Try to connect here ``` Other issue is within the UI Opening configuration portal second time shows my previously selected SSID in gray color and I assumed I don't need to select it again, so I changed only password. However on the next bootup SSID is empty while the updated password is there

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 15, 2024):

I uploaded the fix addressing UI issue and saving empty ssid

<!-- gh-comment-id:1945240862 --> @rusty-labs commented on GitHub (Feb 15, 2024): I uploaded the fix addressing UI issue and saving empty ssid

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 15, 2024):

Yeah there is a other issue about that thanks
Its already saves if its placeholder. I will think of a better way to represent this like disable until clicked or something

<!-- gh-comment-id:1945259230 --> @tablatronix commented on GitHub (Feb 15, 2024): Yeah there is a other issue about that thanks Its already saves if its placeholder. I will think of a better way to represent this like disable until clicked or something

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 15, 2024):

For the sake of consistency it'd be better to use value instead of a placeholder, since custom parameters are using values
I also checked behavior on my router in client mode, and it also keeps SSID as a value even if it's wrong

<!-- gh-comment-id:1945273178 --> @rusty-labs commented on GitHub (Feb 15, 2024): For the sake of consistency it'd be better to use value instead of a placeholder, since custom parameters are using values I also checked behavior on my router in client mode, and it also keeps SSID as a value even if it's wrong

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 15, 2024):

Custom params can also use placeholders.
Connect fails never save but it ahould not overwrite if ssid was blank. I thought I just fixed this but maybe it was bad or not pushed. Thanks

<!-- gh-comment-id:1945292966 --> @tablatronix commented on GitHub (Feb 15, 2024): Custom params can also use placeholders. Connect fails never save but it ahould not overwrite if ssid was blank. I thought I just fixed this but maybe it was bad or not pushed. Thanks

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 15, 2024):

I used placeholder because I do not want wifi args resubmitting if only changing params. This way they do not get sent in plain text everytime you save, if not needed. Also we cannot populate password.

hmm I thought this fixed this

0e2016879b
9df7acdeeb

Also why are you restarting in the callback function anyway?
saveConfigCallback() and not using return or status? Just Curious

I wonder if wifi_ssid is not populated becuase esp32 wifi was not init or connected yet

<!-- gh-comment-id:1945413768 --> @tablatronix commented on GitHub (Feb 15, 2024): I used placeholder because I do not want wifi args resubmitting if only changing params. This way they do not get sent in plain text everytime you save, if not needed. Also we cannot populate password. hmm I thought this fixed this 0e2016879b66dc3b4f200b1d91fde5ae9a501f37 9df7acdeeb6a7f614cdcba4a3f8c117ab7c23718 Also why are you restarting in the callback function anyway? saveConfigCallback() and not using return or status? Just Curious I wonder if wifi_ssid is not populated becuase esp32 wifi was not init or connected yet

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 15, 2024):

Sending SSID in a plain text is totally fine.

saveConfigCallback() and not using return or status? Just Curious
Yeah, I can restart after connection complete too, I just prefer callbacks, in case if I want to use non-blocking mode etc.

I believe the root cause of these problems is that WiFi_SSID and _ssid are not synced, should be setter/getter instead

<!-- gh-comment-id:1945455892 --> @rusty-labs commented on GitHub (Feb 15, 2024): Sending SSID in a plain text is totally fine. # > saveConfigCallback() and not using return or status? Just Curious Yeah, I can restart after connection complete too, I just prefer callbacks, in case if I want to use non-blocking mode etc. I believe the root cause of these problems is that WiFi_SSID and _ssid are not synced, should be setter/getter instead

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 16, 2024):

Password has the same problem

• Provide correct ssid and pass, save
• Load configuration portal again
• Change custom parameters
• Save
• Can't connect to WiFi because password is gone

<!-- gh-comment-id:1947723697 --> @rusty-labs commented on GitHub (Feb 16, 2024): Password has the same problem - Provide correct ssid and pass, save - Load configuration portal again - Change custom parameters - Save - Can't connect to WiFi because password is gone

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 16, 2024):

Ok I fixed all the issues above in my fork

github.com/rusty-labs/WiFiManager@981a540793/WiFiManager.cpp (L2110C3-L2116C4)

github.com/rusty-labs/WiFiManager@981a540793/wm_strings_en.h (L66)

github.com/rusty-labs/WiFiManager@981a540793/WiFiManager.cpp (L1293C3-L1303C4)

I did some other fixes but I think these 3 should be sufficient to solve the problem

<!-- gh-comment-id:1948949171 --> @rusty-labs commented on GitHub (Feb 16, 2024): Ok I fixed all the issues above in my fork https://github.com/rusty-labs/WiFiManager/blob/981a540793fd1c1b501be7f6071da42fe5aaa3de/WiFiManager.cpp#L2110C3-L2116C4 https://github.com/rusty-labs/WiFiManager/blob/981a540793fd1c1b501be7f6071da42fe5aaa3de/wm_strings_en.h#L66 https://github.com/rusty-labs/WiFiManager/blob/981a540793fd1c1b501be7f6071da42fe5aaa3de/WiFiManager.cpp#L1293C3-L1303C4 I did some other fixes but I think these 3 should be sufficient to solve the problem

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 16, 2024):

What browser? Ssid and pass empty should do nothing

<!-- gh-comment-id:1949473185 --> @tablatronix commented on GitHub (Feb 16, 2024): What browser? Ssid and pass empty should do nothing

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 17, 2024):

It has nothing to do with a browser

1. _ssid = server->arg(F("s")); returns empty ssid, because it's a placeholder not a value
2. handleWifiSave() makes _ssid empty
3. connect=true
4. processConfigPortal saves empty _ssid to flash

<!-- gh-comment-id:1949507528 --> @rusty-labs commented on GitHub (Feb 17, 2024): It has nothing to do with a browser 1. _ssid = server->arg(F("s")); returns empty ssid, because it's a placeholder not a value 2. handleWifiSave() makes _ssid empty 3. connect=true 4. processConfigPortal saves empty _ssid to flash

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 17, 2024):

I still dont understand this issue, or see it..
Where is your example failing?

     if(_ssid == "" && _pass != ""){
      _ssid = WiFi_SSID(true);
     ....
      // skip wifi if no ssid
      if(_ssid == ""){
        #ifdef WM_DEBUG_LEVEL
        DEBUG_WM(WM_DEBUG_VERBOSE,F("No ssid, skipping wifi save"));
        #endif
      }

Empty ssid should not be saved, unless you change pw but it should use WIFI_SSID, what is the test case that this returns "" ? What wifi mode are you in when saving by chance?

<!-- gh-comment-id:1949622343 --> @tablatronix commented on GitHub (Feb 17, 2024): I still dont understand this issue, or see it.. Where is your example failing? ```C++ if(_ssid == "" && _pass != ""){ _ssid = WiFi_SSID(true); .... // skip wifi if no ssid if(_ssid == ""){ #ifdef WM_DEBUG_LEVEL DEBUG_WM(WM_DEBUG_VERBOSE,F("No ssid, skipping wifi save")); #endif } ``` Empty ssid should not be saved, unless you change pw but it should use WIFI_SSID, what is the test case that this returns "" ? What wifi mode are you in when saving by chance?

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 17, 2024):

Ok I got your latest changes
Your fix doesn't work if I provide incorrect SSID and correct Password first, and then after restart provide correct SSID
But for the steps I described above it works

Btw this code shouldn't be called if _connectonsave = false
github.com/tzapu/WiFiManager@d8f8d5478a/WiFiManager.cpp (L1038C3-L1043C4)
Also I don't understand why
if(_aggresiveReconn && _connectRetries<4) _connectRetries=4;
If I set _connectRetries = 2, why all of a sudden it becomes 4 ? Why do you even need _aggresiveReconn ?

Overall the logic is becoming too tangled, the code needs a cleanup, too many states contradicting each other

<!-- gh-comment-id:1949780107 --> @rusty-labs commented on GitHub (Feb 17, 2024): Ok I got your latest changes Your fix doesn't work if I provide incorrect SSID and correct Password first, and then after restart provide correct SSID But for the steps I described above it works Btw this code shouldn't be called if _connectonsave = false https://github.com/tzapu/WiFiManager/blob/d8f8d5478a646a9ec14d0418aa0c4b96c1899b58/WiFiManager.cpp#L1038C3-L1043C4 Also I don't understand why `if(_aggresiveReconn && _connectRetries<4) _connectRetries=4;` If I set _connectRetries = 2, why all of a sudden it becomes 4 ? Why do you even need _aggresiveReconn ? Overall the logic is becoming too tangled, the code needs a cleanup, too many states contradicting each other

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 17, 2024):

It says it in the source

    bool          _aggresiveReconn        = true; // use an agrressive reconnect strategy, WILL delay conxs
                                                   // on some conn failure modes will add delays and many retries to work around esp and ap bugs, ie, anti de-auth protections
                                                   // https://github.com/tzapu/WiFiManager/issues/1067

It will probably be removed from prod, or optional, but it resolved almost 100% of connection failures reported n issues

#1067

<!-- gh-comment-id:1950228289 --> @tablatronix commented on GitHub (Feb 17, 2024): It says it in the source ``` bool _aggresiveReconn = true; // use an agrressive reconnect strategy, WILL delay conxs // on some conn failure modes will add delays and many retries to work around esp and ap bugs, ie, anti de-auth protections // https://github.com/tzapu/WiFiManager/issues/1067 ``` It will probably be removed from prod, or optional, but it resolved almost 100% of connection failures reported n issues #1067 

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 17, 2024):

I will remove it and see if the bug is fixed, and see if I can move this into a workaround check for specific versions and or failure codes. Without it this was causing a absolute failure of esp connection sucess on restarts

<!-- gh-comment-id:1950229275 --> @tablatronix commented on GitHub (Feb 17, 2024): I will remove it and see if the bug is fixed, and see if I can move this into a workaround check for specific versions and or failure codes. Without it this was causing a absolute failure of esp connection sucess on restarts

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 19, 2024):

_aggresiveReconn is always true and there is no public setter for this, instead you can just
_connectRetries = max(connectRetries, 4); at least the logic would be explicitly expressed instead of some hidden bool state
But I'd get rid of it too, those who have troubles with a connection can increase number of retries in a client code
The library code shouldn't fix specific problems, it should provide an interface to do so
Also delay(1000); should be after wifiConnectNew, otherwise execution is just delayed for nothing

<!-- gh-comment-id:1951628243 --> @rusty-labs commented on GitHub (Feb 19, 2024): _aggresiveReconn is always true and there is no public setter for this, instead you can just `_connectRetries = max(connectRetries, 4);` at least the logic would be explicitly expressed instead of some hidden bool state But I'd get rid of it too, those who have troubles with a connection can increase number of retries in a client code The library code shouldn't fix specific problems, it should provide an interface to do so Also delay(1000); should be after wifiConnectNew, otherwise execution is just delayed for nothing

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 19, 2024):

The delay is necessary for this failure mode

<!-- gh-comment-id:1951718721 --> @tablatronix commented on GitHub (Feb 19, 2024): The delay is necessary for this failure mode

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 19, 2024):

Delay yes, but _aggresiveReconn no, if it's always true

<!-- gh-comment-id:1951765339 --> @rusty-labs commented on GitHub (Feb 19, 2024): Delay yes, but _aggresiveReconn no, if it's always true

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@rusty-labs commented on GitHub (Feb 19, 2024):

Btw delay not needed, you already have _connectTimeout which is not used, set _connectTimeout = 1000 and it will work as a delay

<!-- gh-comment-id:1951797138 --> @rusty-labs commented on GitHub (Feb 19, 2024): Btw delay not needed, you already have _connectTimeout which is not used, set _connectTimeout = 1000 and it will work as a delay

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Feb 20, 2024):

They function differently. Timeout is not the same as delay for reconnect.
I added both those options after that test was implemented as a result of its feedback.

i just need to decide how to reimplement it better so its not always required.

E (5966) wifi:Association refused temporarily, comeback time 1048 mSec

<!-- gh-comment-id:1953318493 --> @tablatronix commented on GitHub (Feb 20, 2024): They function differently. Timeout is not the same as delay for reconnect. I added both those options after that test was implemented as a result of its feedback. i just need to decide how to reimplement it better so its not always required. `E (5966) wifi:Association refused temporarily, comeback time 1048 mSec`

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@real-bombinho commented on GitHub (Mar 9, 2024):

I have version 2.0.17 and it seems this is not fixed in this version by the looks of?

I am just porting some working stuff from ESP8266 to the ESP32 and it keeps forgetting the WiFi credentials on each restart on the ESP32.

<!-- gh-comment-id:1986983455 --> @real-bombinho commented on GitHub (Mar 9, 2024): I have version 2.0.17 and it seems this is not fixed in this version by the looks of? I am just porting some working stuff from ESP8266 to the ESP32 and it keeps forgetting the WiFi credentials on each restart on the ESP32.

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Mar 10, 2024):

@real-bombinho please create a new issue with some information, unrelated to this issue

<!-- gh-comment-id:1987033463 --> @tablatronix commented on GitHub (Mar 10, 2024): @real-bombinho please create a new issue with some information, unrelated to this issue

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Mar 10, 2024):

Your fix doesn't work if I provide incorrect SSID and correct Password first, and then after restart provide correct SSID
But for the steps I described above it works

Is this really a issue? who does this?

<!-- gh-comment-id:1987034132 --> @tablatronix commented on GitHub (Mar 10, 2024): > Your fix doesn't work if I provide incorrect SSID and correct Password first, and then after restart provide correct SSID But for the steps I described above it works Is this really a issue? who does this?

kerem commented 2026-02-28 01:30:08 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Mar 10, 2024):

Closing unless you can provide how to reproduce and provide logs. I tested this as much as I can and have no issue

<!-- gh-comment-id:1987034325 --> @tablatronix commented on GitHub (Mar 10, 2024): Closing unless you can provide how to reproduce and provide logs. I tested this as much as I can and have no issue

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

revert-1849-master

feature_fastconnect

feature_auth

feature_slimable

PEAP

feature_statichtmlparams

feature_asyncwebserver

feature_pagestringsref

parameter-smart-ptr

gh-pages

Legacy_v1

hotfixes

autochannelselect_feature

travis

smartconfig

v2.0.17

v2.0.16-rc.2

v2.0.15-rc.1

v2.0.0-rc.1

v2.0.14-beta

v2.0.13-beta

v2.0.12-beta

v2.0.11-beta

v2.0.10-beta

v2.0.9-beta

v2.0.8-beta

2.0.7-beta

2.0.6-beta

2.0.5-beta

2.0.4-beta

0.16.0

2.0.3-alpha

0.15.0

0.14

0.13

0.12

0.11

0.10

0.9

0.8

0.7

0.6

0.5

v0.4

v0.3

v0.2

v0.1

Labels

Clear 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

Mirrored from GitHub Pull Request

  

wontfix

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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/WiFiManager#1452

No description provided.