CWP Setup. How to prevent splash screen coming back after accepting t&c

  • 1
  • Question
  • Updated 2 years ago
Hi Guys,

I am currently setting up CWP on our public wifi. 
When a user connects our wifi, they are presented with our t&c, which is great.

What I cannot workout, is how to prevent aerohive from forgetting a device that has already accepted the t&c. This only happens when they reconnect to the wifi after 30mins to an hour of being away from the office. 

The registration type is "use policy acceptance". 

I have set the "Registration Period" to 30 days (43800 minutes).
Photo of Warren


  • 2 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
In short, this is the result of the way the roaming cache works in an Aerohive system.

The APs only maintain knowledge about a client for as long as the client remains active in the roaming cache which is shared between APs in the Hive. If a client goes out of range of the APs (e.g. somebody going for lunch out of range of the network) so that they are no longer actively associated with any AP, the roaming cache entry starts aging out. If it ages out before the client re-associates, when they do, as far as the APs are concerned they are a new client - there is no "historical" knowledge of that client maintained.

The "registration period" determines how long the client remains registered while they are still there in the roaming cache, i.e. if you set this to 30 days, then a client that remains constantly connected for 30 days will be re-prompted with the UAP after 30 days. But if they disconnect and the roaming cache entry ages out, they will be represented with the UAP (or have to log on again for a logon type CWP).

I wrote up the behaviour some time ago, see below:

This is what the roaming cache entry looks like when the client has disconnected:

Cookie Size: 684
Supplicant Address(SPA): xxxx.xxxx.xxxx
User name:
User Profile ID: 2
VLAN ID: xxx
PMK(1st 2 bytes):fb26
PMKID(1st 2 bytes):9419
Session time: 42823 seconds
Idle timeout: 0 minutes
PMK Time left in cache: 3326
PMK age: 1175
Roaming cache update interval: 60
last time logout: 225 seconds ago
Authenticator Address: MAC=xxxx.xxxx.xxxx, IP=x.x.x.x
Roaming entry is got from neighbor AP: xxxx.xxxx.xxxx
PMK is got(Flag): Remotely
Station IP address: x.x.x.x
Station hostname: Dans-iPhone
Station default gateway: x.x.x.x
Station DNS server: x.x.x.x
Station DHCP lease time: 85225 seconds
Hops: 1
Acct multi session id: ec852fac66150019771e29d752fc9947333ab105
Additional auth flag: 0x0011
  Auth flag: not set
  CWP flag: set
  MAC based auth flag: not set
  MDM flag: not set
  Disconnected flag: not set
OS Name: Blackberry
Domain Name:
Mobile device policy original UPID: 2
WPA key mgmt: 2
R0KH: 0000:0000:0000
PMKR0 Name: 0000*
        Compliant status: Unknown
        Original UPID: 0
        Original VLAN: 0

The fields which are important are the “Session Time” and the “Last Time Logout”. (The “PMK Time Left in Cache” is also important, but only for PMK caching – i.e. fast roaming – but not for CWP).

When “Last Time Logout” exceeds “Session Time”, the roaming cache entry is removed – and the CWP will be displayed the next time the user connects.

If the user disconnects and later reconnects, the “Session Time” is decremented by “Last Time Logout” – this keeps “Session Time” correct based on the first time the user connected. That is:

User connects.

Session Time = 43200
Last Time Logout = 0

From this point on, Last Time Logout increments every second.

If you disconnect and reconnect, Session Time is decremented by whatever value Last Time Logout was at the point of reconnection and Last Time Logout is set back to 0. i.e.:

Session Time = 43200
Last Time Logout = 200

User disconnects and reconnects at this point.

Session Time = 43000
Last Time Logout = 0

Last Time Logout then continues to increment. This essentially means that the roaming cache entry is tracking the session time back to the first connection (when the user logged in via CWP).

When “Last Time Logout” exceeds “Session Time”, the roaming entry will be aged out and the user would have to reconnect and accept the AUP again.

[There was a “behaviour” when I tested this where if I set the CWP Registration Timer to a low value for testing (e.g. 3 minutes), the entry doesn’t age out as expected and the CWP was not represented. It looked to be that the PMK cache timeout parameter was preventing the CWP from being re-displayed. So in fact in that scenario the CWP is not being presented when we intended that it should be! I don’t know if this is a bug or “as designed” behaviour.]

So as long as the entry remains in the roaming cache, the CWP Registration Timeout does determinewhen the user will be re-presented with the CWP (default after 12 hours, but configurable).

If the user disconnects, the entry will remain in the roaming cache based on the roaming cache update settings under Hive Settings – default time is 60 minutes (calculated by 60 second update interval times ageout counter of 60, i.e. entries in the cache are updated every 60 seconds and 60 consecutive updates have to be missed for an entry to age out). But if the roaming entry itself is aged out, all information regarding the Registration Timeout is lost and therefore the user will have to re-authenticate.

While the roaming cache update settings can be modified to increase the roaming cache aging time, to get a very long aging time involves significantly increasing the roaming cache "update interval" which in turn could cause you problems with roaming. For example, to have a roaming cache aging time of 30 days, you would need an update interval of at least 2592 seconds (43 minutes) even with the maximum possible value of ageout counter (1000), which is likely to cause issues with roaming. Plus it would mean in some environments you would end up with a very large number of "stale" entries in the cache which could hit an architectural limit in some instances.

Other than aging out due to the user disappearing, the other reason a roaming cache entry may not be present is if the user roams between APs that are not one-hop neighbours (i.e. different AP management VLANs on the backhaul AND not in RF range or background scanning is not enabled/able to run AND no manual AMRP adjacencies are configured). An example of where this could be a problem is a network in a high rise building with a different AP management network per floor and no wireless coverage in the lifts. A user going from the top floor to the bottom floor (i.e. disassociating from an AP on the top floor and re-associating with an AP on the ground floor without roaming through the APs inbetween) will be seen as a new user and will get the CWP again.

I also submitted an "idea" here to improve the behaviour, but I don't believe it has changed from when I wrote this.

Photo of Dillan Horn

Dillan Horn

  • 8 Posts
  • 0 Reply Likes
Great info thanks for the details. 
Photo of Warren


  • 2 Posts
  • 0 Reply Likes
Thanks Roberto, that was very helpful and cleared up why I couldn't get it working. 
Photo of Dillan Horn

Dillan Horn

  • 8 Posts
  • 0 Reply Likes
Sounds like this is expected behavior based on the clients disconnecting/reconnecting. When you disconnect it resets the session timer back to 0 and requires CWP acceptance when you come back. 

I think the solution is to use guest pass manager for people that are going to be re-connecting frequently. They can self register a pass key and accept the policy, then they use that key until it expires.