mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 09:05:56 +03:00
[GH-ISSUE #117] Seems there is no DHCP timeout #88
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#88
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 @noname000git on GitHub (Mar 5, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/117
My setup: router connecting internet, serving IP in lan and wifi repeater giving new ssid, but relying in router to serve IP. WifiManager configured and working to autoconnect with timeout to second ssid.
If I power off main router and reboot ESP, it finds second ssid, connects but as it can't get IP the system blocks forever waiting (neither failback to portal nor the failback function).
Does it mean that if DHCP server hangs all the ESP in lan will be unrecoverable in reboot?
Thanks
@tzapu commented on GitHub (Mar 5, 2016):
that sounds to me the same behaviour any device like a laptop would have, if there s no dhcp, the device won t get an ip, and won t work
depending on your configuration, and where it locks, you could add a check after autoConnect, and if IP is not ok, reboot.
@noname000git commented on GitHub (Mar 6, 2016):
the problem is I can't check anything after autoconnect because it never ends (autoconnect waits forever for the ip). Maybe It would be nice to timeout autoconnect after a fixed time, let execute the callback function to do offline tasking and continue to portal with timeout to loop again
@tzapu commented on GitHub (Mar 7, 2016):
hi,
thanks for this, it seems there are a number of edge cases, like yours, that i am now discovering, that involve autoConnect/waitForConnectionResult to stall forever. I will need to find a way to test this myself.
in the mean time, i have added a change in the latest commit that sorts at least some of these cases, probably not yours.
There s also a function to force a timeout on connection, mentioned here https://github.com/tzapu/WiFiManager#debug
try adding
wifiManager.setConnectTimeout(60);BEFORE autoConnectplease let me know what happens, these kind of errors have been making my life miserable, as people report some of them but I can t replicate :D
@tzapu commented on GitHub (Mar 8, 2016):
hi, i ve just made another commit to this, could you please try the github version of WiFiManager and see if anything changed for you?