Captive Portal - timing out

zegor_mjol · June 23, 2020, 3:47pm

Background:

Balance 380 with multiple AP One AC minis connected to a
Very well-connected network (1 GB symmetric fiber)
An SSID associated with a
VLAN dedicated to
A Captive Portal with tokens as the only authorization mechanism, and
A set of Apple products (macs, iPads, iPhones) connecting using the portal

Issue:
When entering a token for a connection (mostly after a previous token has been exhausted, it seems) the splash page returns with a “timeout” error:

And the connection is still dead.

After submitting the same token again, one receives the same error message.

However, ignoring that error message and simply opening another browser window such as guest2.ic.peplink.com/, the connection confirmation pane (“start browsing”) may come up, and all is well. Until the next time it happens.

Observations:

I have not identified any pattern w.r.t. when the error manifests.
Turning Wi-Fi off and on again sometimes seems to fix the problem.

Any thoughts? Seems too quirky for public use, but there may be some setting that I am missing?

Suyi_Ho · June 24, 2020, 12:54am

Hi Zegor,
This error message means your client fails to login on the device until timeout.
Checked that after your first token quota exceeded, one of your client (luft) is disconnected from the device “claremont” and connected to another device “claremont AP3 SM Office - XXXX” with other SSID KDSM that does not configured with Captive Portal. And it got some disconnections in between and connected to the device “claremont” again that your client was able to sign in with another new token.
You may either change your settings or forget the SSIDs of device “claremont AP3 SM Office - XXXX” from your client to make sure that you got a clean environment for the testing.
If problem still persists, feel free to raise a ticket at Peplink Ticketing System.

zegor_mjol · June 24, 2020, 10:21am

To summarize my understanding:
In a multi-SSID environment where a device is enabled for more than one SSID, when choosing an SSID with a portal the authentication protocol may be disrupted by the connection to the portal changing (or being briefly halted) as part of the protocol, and the device then switching to another non-portal SSID.

Thus when the portal responds, the connection for the response is no Ionger there and hence the time-out.

Thanks for checking and identifying the cause (which would generally not apply in the production environment for this use case).

This was (as usual ) very helpful.