[GH-ISSUE #308] configPortalTimeout improvements #259

Closed
opened 2026-02-28 01:24:23 +03:00 by kerem · 13 comments
Owner

Originally created by @tablatronix on GitHub (Feb 7, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/308

only timeout configportal if ap has no client

Originally created by @tablatronix on GitHub (Feb 7, 2017). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/308 only timeout configportal if ap has no client
kerem 2026-02-28 01:24:23 +03:00
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

pr
https://github.com/tzapu/WiFiManager/pull/310

<!-- gh-comment-id:278342566 --> @tablatronix commented on GitHub (Feb 8, 2017): pr https://github.com/tzapu/WiFiManager/pull/310
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

My fix was simple and to keep configportal open if a client was connected to AP. Essentially ignore timeout if someome is connected to AP.

This avoids dealing with last request timestamp bumping and all the problems that creates and fails to solve for.

This may require a new timeout fallback to prevent someone from just sitting on configportal and it never timing out.

I do see how this could create a problem with not a way to timeout a user stuck in webportal....
I was trying to address 2 things

AP is not found, unit gets stuck in configportal...
so implement a short configportaltimeout, so that it keeps retrying AP, but then when you are using the configportal you can timeout in the middle of using it.

I think the only perfect solution is to implement some keep alive when someone is on the web portal.

configportaltimeout is pretty unusable if you can get kicked out of the portal at anytime..

<!-- gh-comment-id:278346674 --> @tablatronix commented on GitHub (Feb 8, 2017): My fix was simple and to keep configportal open if a client was connected to AP. Essentially ignore timeout if someome is connected to AP. This avoids dealing with last request timestamp bumping and all the problems that creates and fails to solve for. This may require a new timeout fallback to prevent someone from just sitting on configportal and it never timing out. I do see how this could create a problem with not a way to timeout a user stuck in webportal.... I was trying to address 2 things AP is not found, unit gets stuck in configportal... so implement a short configportaltimeout, so that it keeps retrying AP, but then when you are using the configportal you can timeout in the middle of using it. I think the only perfect solution is to implement some keep alive when someone is on the web portal. configportaltimeout is pretty unusable if you can get kicked out of the portal at anytime..
Author
Owner

@tzapu commented on GitHub (Feb 8, 2017):

in my mind, the timeout should be paused or reset if there is a client connected to the ap or maybe just increase the timeout interval with 30 seconds (for example) each time the loop happens, it has not timed out yet and there is someone connected... this should give in effect a timeout that will happen 30 seconds + whatever was left of the timeout after the client disconnected...

a bit hacky maybe, but not bloated i think

<!-- gh-comment-id:278352088 --> @tzapu commented on GitHub (Feb 8, 2017): in my mind, the timeout should be paused or reset if there is a client connected to the ap or maybe just increase the timeout interval with 30 seconds (for example) each time the loop happens, it has not timed out yet and there is someone connected... this should give in effect a timeout that will happen 30 seconds + whatever was left of the timeout after the client disconnected... a bit hacky maybe, but not bloated i think
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

So just add a static global timeoutbuffer variable and add it to the timeout calculations ?
Probably do not want to modify user timeout variable, nor the configportalstart timestamp variable, unless we rename it to something more logical , but someone might be using it.

Maybe we should extend the timeout from disconnect, This way a user knows exactly when a timeout will occur, not a fan of the black box timeout buffer.

configPortalTimeout = timeout after last user disconnects, or if no user connected.
seems simpler.

unless user clicks cancel ?
see this just gets more and more complicated use cases. hmm

<!-- gh-comment-id:278356254 --> @tablatronix commented on GitHub (Feb 8, 2017): So just add a static global timeoutbuffer variable and add it to the timeout calculations ? Probably do not want to modify user timeout variable, nor the configportalstart timestamp variable, unless we rename it to something more logical , but someone might be using it. Maybe we should extend the timeout from disconnect, This way a user knows exactly when a timeout will occur, not a fan of the black box timeout buffer. configPortalTimeout = timeout after last user disconnects, or if no user connected. seems simpler. unless user clicks cancel ? see this just gets more and more complicated use cases. hmm
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

hows this?( I also abstracted it so it can be enhanced in the future )

boolean WiFiManager::configPortalHasTimeout(){
    if(_configPortalTimeout == 0 || wifi_softap_get_station_num() > 0){
      _configPortalStart = millis(); // kludge, bump configportal start time to skew timeouts
      return false;
    }
    return (millis() > _configPortalStart + _configPortalTimeout);
}
<!-- gh-comment-id:278371589 --> @tablatronix commented on GitHub (Feb 8, 2017): hows this?( I also abstracted it so it can be enhanced in the future ) ``` boolean WiFiManager::configPortalHasTimeout(){ if(_configPortalTimeout == 0 || wifi_softap_get_station_num() > 0){ _configPortalStart = millis(); // kludge, bump configportal start time to skew timeouts return false; } return (millis() > _configPortalStart + _configPortalTimeout); } ```
Author
Owner

@tzapu commented on GitHub (Feb 8, 2017):

that looks brilliant to me, thank you very much

<!-- gh-comment-id:278378618 --> @tzapu commented on GitHub (Feb 8, 2017): that looks brilliant to me, thank you very much
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

pushed to PR

<!-- gh-comment-id:278382601 --> @tablatronix commented on GitHub (Feb 8, 2017): pushed to PR
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

In the future maybe implement a keep alive headers or a microajax keepalive, and use that data to determine page access.

<!-- gh-comment-id:278385557 --> @tablatronix commented on GitHub (Feb 8, 2017): In the future maybe implement a keep alive headers or a microajax keepalive, and use that data to determine page access.
Author
Owner

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

It looks there might be a problem with this solution.

Depending on how the client disconnects, wifi_softap_get_station_num continues to report client connected.

<!-- gh-comment-id:281181749 --> @tablatronix commented on GitHub (Feb 20, 2017): It looks there might be a problem with this solution. Depending on how the client disconnects, wifi_softap_get_station_num continues to report client connected.
Author
Owner

@tablatronix commented on GitHub (Feb 21, 2017):

This seems to be caused as with a ton of other problems, by bad sta connect while trying to run softap, it seems it causes issues with dhcp as well.

I was able to stabilize this a bit by WiFi.disconnect(true); before enabling softap if not connected.
setting mode(WIFI_AP) was not enough.

Ill keep testing

<!-- gh-comment-id:281444031 --> @tablatronix commented on GitHub (Feb 21, 2017): This seems to be caused as with a ton of other problems, by bad sta connect while trying to run softap, it seems it causes issues with dhcp as well. I was able to stabilize this a bit by `WiFi.disconnect(true);` before enabling softap if not connected. setting `mode(WIFI_AP)` was not enough. Ill keep testing
Author
Owner

@FernandoGarcia commented on GitHub (Apr 6, 2017):

Hi @tablatronix @tzapu!

After this update the portal never goes to timeout even without any client.

Best regards.

<!-- gh-comment-id:292156250 --> @FernandoGarcia commented on GitHub (Apr 6, 2017): Hi @tablatronix @tzapu! After this update the portal never goes to timeout even without any client. Best regards.
Author
Owner

@FernandoGarcia commented on GitHub (Apr 6, 2017):

I'm sorry was my mistake I don't know the reason but I changed the timeout from seconds to milliseconds. :D
So my timeout was 300 000 seconds.

<!-- gh-comment-id:292164188 --> @FernandoGarcia commented on GitHub (Apr 6, 2017): I'm sorry was my mistake I don't know the reason but I changed the timeout from seconds to milliseconds. :D So my timeout was 300 000 seconds.
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2018):

added webclient checking to bump timeouts, good enough until I decide to add js and ajax keepalives.

1c4011bfb4

both can be toggled

    //if true, timeout captive portal even if a STA client connected (true), suggest disabling if captiveportal is open
    void          setCaptivePortalClientCheck(boolean enabled);
    //if true, reset timeout when webclient connects (true), suggest disabling if captiveportal is open    
    void          setWebPortalClientCheck(boolean enabled);
<!-- gh-comment-id:364206366 --> @tablatronix commented on GitHub (Feb 8, 2018): added webclient checking to bump timeouts, good enough until I decide to add js and ajax keepalives. 1c4011bfb4debe15952239fa6861b4e04cebba4f both can be toggled ```C++ //if true, timeout captive portal even if a STA client connected (true), suggest disabling if captiveportal is open void setCaptivePortalClientCheck(boolean enabled); //if true, reset timeout when webclient connects (true), suggest disabling if captiveportal is open void setWebPortalClientCheck(boolean enabled); ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
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#259
No description provided.