starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 00:55:52 +03:00

[GH-ISSUE #1468] What does WIFI_REASON: 4 Mean #1259

New issue

Closed

opened 2026-02-28 01:29:17 +03:00 by kerem · 9 comments

kerem commented

2026-02-28 01:29:17 +03:00

Owner

Originally created by @GeorgeIoak on GitHub (Aug 6, 2022).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1468

I'm trying to debug a minor problem that happens when I change to a new network. Everything works fine but after it restarts I need to manually restart the board once or twice before the application runs properly. This only happens happen I run WM. When I check the log I find this:

parsed json
*wm:[2] Added Parameter: key_custom
*wm:[2] Added Parameter:
*wm:[1] AutoConnect 
*wm:[2] ESP32 event handler enabled 
*wm:[2] Connecting as wifi client... 
*wm:[2] setSTAConfig static ip not set, skipping 
*wm:[1] Connecting to SAVED AP: TheIoaks
*wm:[1] connectTimeout not set, ESP waitForConnectResult... 
*wm:[2] [EVENT] WIFI_REASON:  4

and at this point I need to restart the board. I searched but I cannot seem to find the meaning of "4"

Originally created by @GeorgeIoak on GitHub (Aug 6, 2022). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1468 I'm trying to debug a minor problem that happens when I change to a new network. Everything works fine but after it restarts I need to manually restart the board once or twice before the application runs properly. This only happens happen I run WM. When I check the log I find this: ``` parsed json *wm:[2] Added Parameter: key_custom *wm:[2] Added Parameter: *wm:[1] AutoConnect *wm:[2] ESP32 event handler enabled *wm:[2] Connecting as wifi client... *wm:[2] setSTAConfig static ip not set, skipping *wm:[1] Connecting to SAVED AP: TheIoaks *wm:[1] connectTimeout not set, ESP waitForConnectResult... *wm:[2] [EVENT] WIFI_REASON: 4 ``` and at this point I need to restart the board. I searched but I cannot seem to find the meaning of "4"

kerem closed this issue

2026-02-28 01:29:17 +03:00

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 9, 2022):

WIFI_REASON_ASSOC_EXPIRE

@tablatronix commented on GitHub (Aug 9, 2022): WIFI_REASON_ASSOC_EXPIRE

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@GeorgeIoak commented on GitHub (Aug 10, 2022):

So that seems to be not expected after you've entered the new WiFi AP information, correct?

@GeorgeIoak commented on GitHub (Aug 10, 2022): So that seems to be not expected after you've entered the new WiFi AP information, correct?

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 10, 2022):

Is it every other reboot?

@tablatronix commented on GitHub (Aug 10, 2022): Is it every other reboot?

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@GeorgeIoak commented on GitHub (Aug 10, 2022):

You know it might be. I need to do some additional debugging before I really bother you but that's why I was trying to understand the normal flow. In general though it seems that once I change the WiFi AP I have to manually reboot twice before the board runs the code normally. After that it always runs fine.

@GeorgeIoak commented on GitHub (Aug 10, 2022): You know it might be. I need to do some additional debugging before I really bother you but that's why I was trying to understand the normal flow. In general though it seems that once I change the WiFi AP I have to manually reboot twice before the board runs the code normally. After that it always runs fine.

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 10, 2022):

Yeah its a known esp issue #1137

@tablatronix commented on GitHub (Aug 10, 2022): Yeah its a known esp issue #1137

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@GeorgeIoak commented on GitHub (Aug 11, 2022):

Reading through the older issues and replies am I correct that a workaround for this issue is to add a setConnectRetries(3) ?

@GeorgeIoak commented on GitHub (Aug 11, 2022): Reading through the older issues and replies am I correct that a workaround for this issue is to add a `setConnectRetries(3)` ?

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 11, 2022):

You can try that, yes, and add longer connect timout, this issue only presents with some routers, you can also try

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

Also try using newer versions of esp lib core

@tablatronix commented on GitHub (Aug 11, 2022): You can try that, yes, and add longer connect timout, this issue only presents with some routers, you can also try 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 Also try using newer versions of esp lib core

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 11, 2022):

#1067

@tablatronix commented on GitHub (Aug 11, 2022): #1067

kerem commented

2026-02-28 01:29:17 +03:00

Author

Owner

@GeorgeIoak commented on GitHub (Aug 11, 2022):

I'm developing in VSCode with PIO and it's showing 5.1.0 is installed which was recently updated I see (11 days ago). I'll review #1067 and run some tests to see if anything changes for the better.

@GeorgeIoak commented on GitHub (Aug 11, 2022): I'm developing in VSCode with PIO and it's showing 5.1.0 is installed which was recently updated I see (11 days ago). I'll review #1067 and run some tests to see if anything changes for the better.