Captive Web Portal's Registration Period

  • 1
  • Question
  • Updated 3 years ago
I wan't to achieve the following: an open SSID with the registration with CWP as the authentication method and where the registration type is set to 'Use Policy Acceptance'. Upon connecting to the SSID and accepting the policy, the user should not be greeted by the CWPs login page for a period of one month. So I don't want users to accept the policy each time they they connect to this SSID, but once every month.

If I go to Edit Captive Web Portal > Optional Advanced Configuration > Registration Period, I can "set the length of time that a registered user with an active sessions remains registered". According to Help,
If the user closes one session and later starts a new one while the AP still has a roaming cache entry for his client (one hour by default), he does not have to register with the captive web portal again. On the other hand, if the user closes a session and then starts a new session after the roaming cache entry has been removed, he must complete the registration process again even if the new session begins within the registration period.
My question is: If I enter the value that corresponds to 30 days in Registration Period, will I achieve the result I'm looking for? Because if I read the above correctly, a new CWP registration is not needed if the AP still has a roaming cache entry for his client (not ALL APs for ALL registered clients?). And since this value is only one hour, will having a Registration Period of more than hour even do anything?
Photo of systemerror


  • 0 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Sorry, but as you've read, what you desire is not possible using only the AP-hosted CWP.

Your user would have to stay constantly connected to that or another AP for the entire registration period with no more than one hour of inactivity to keep the roaming cache in the APs current. (After the first AP in the hive has authenticated you and populated it's own roaming cache, it then informs its neighbors so that roaming is seamless (and when you do roam, that new anchor AP informs it's neighbors, etc.)). 

I think the new identity management functions in the version of HiveManager-NG releasing this weekend may be a better approach to consider. 
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

How would I solve this architecturally today?

I would add a RADIUS VSA to specify if a CWP should be skipped or not to be included in the Access-Accept where this is desired.

Then, as long as MAC-authentication or 802.1X authentication takes place first, if the attribute has come back with the expected value, skip the CWP.

This would allow something to be whipped up with FreeRADIUS and PostgreSQL to decide when to show a CWP or not.