To prevent the CWP page from loading for existing Guests that have already signed in to SSID. Due to Roaming away and returning the next day or during the day.

  • 24 January 2019
  • 7 replies

  • Anonymous
  • 0 replies



I believe I have found the answer, however I would like to check if this has any unwanted affects to roaming.


I have a CWP for Guest self-registration over the Open SSID aerohive cloud RADIUS auth. This works well by sending the username and key to guests. 

The difference is the duration of the Usergroup is 6 mths, as these are trusted-non-staff, but not your general public guest, when normally a guest would have a few days duration.


The issue is each time users come back from departing the office during the day etc they are forced to re-enter their username/password over the CWP.



By using the defaults of the SSID for:

Roaming Cache Update Interval 60sec

Roaming Cache ageout 60

I understand this provides a 1hr Total roaming cache (60 sec x 60 = 3,600sec)


Currently I changed to:

Roaming Cache Update Interval 60sec

Roaming Cache ageout 1000 (max allowed)

Understand this provides 16hrs total roaming cache.


If I change the settings to:

Roaming Cache Update Interval 15,550 sec

Roaming Cache ageout 1000 (the max allowed)

I understand this provides a 6mths Total roaming cache (15,550 sec x 1000 = 4,320hrs)


I understand that the CWP setting Web Server Registration Period of 720mins does not change the period when the CWP is forced to be displayed forcing users to re-sign in.


If this is the best way to prevent users from seeing the CWP and re-entering their credentials, Do you think this is cause any unwanted issues with roaming.






7 replies

@Sam Pirok​ Hoping this is an easy one for you to clarify.

BTW: since this particular use case is for trusted-guests, I have recommended to use the self-registration PPSK SSID (with the accompanying registration open SSID).

This gives them more flexiblity with a secure PPSK, elimating the CWP requirement after the initial registration.

Userlevel 1

Hi Jason, thanks very much for the detailed explanation! You're on the right track here, we'd just want to tweak this a bit. I would recommend leaving Roaming Cache Update Interval roughly at default, the setting you want to focus on would be the Roaming Cache Ageout. While your math isn't technically wrong, having the Roaming Cache Update Interval that high will essentially break roaming.


The APs will eventually drop inactive client cached information, meaning when users come back in to the network they would need to re-authenticate as if they were a new user. The setting Roaming Cache Ageout is the way we adjust how long the APs hold on to inactive client information, and unfortunately we can't go beyond the stated maximum. We could put in a feature request for a longer max Ageout setting if you'd like? You can do this in the HiveManager by clicking on the chat bubble icon along the right hand side of the screen, and/or I can do this on your behalf internally.

Hi, if you could please raise a Feature Request internally for this, I'm sure customers will appreciate this, even if it is increased from 1000 to 10,000, to allow for 1 week.


Most customers don't like the dual SSID self-registration PPSK method, even though it is more flexible, secure than the open SSID self-reg method.


In this 6 month case, the customer understands it's not conventional guest wifi, as these guys are 'trusted' guests that stay for a long time.

@Sam Pirok​ I appreciate that this is an old post but I have similar (but different) symptoms that I would like some advice on. I do have a case raised however I am taking a multi pronged approach to try and resolve.


In my case I have an Open SSID using RADIUS auth with CWP(provided by A3). In my case, a mobile device(Windows is not affected), will get an IP address in the registration VLAN and the client is redirected to the CWP where they are presented with option to register; either SMS or email. Both sources work successfully. From A3 and the associated AP, I can see that the CoA has taken place however the device does not get an IP address in the new vlan without disabling/enabling Wi-Fi.


I have since read that adjusting the 'Roaming Cache Ageout' under the SSID may help? Does this sound probable and if so are there any downsides to this approach in my scenario?



Userlevel 1

Lowering the Roaming Cache Ageout low enough to cause the device to be forgotten directly after registration would likely cause some odd network behavior. For example, this would mean clients who have authenticated and then roamed to a new AP would likely have to re-authenticate each time they roamed because they wouldn't be in the roaming cache any longer. I unfortunately do not have much hands on experience with A3, so a case might be your best route to a solution here.

@Sam Pirok​ Hi Sam,

I was wondering if there was any traction on the FR to increase the Roaming Cache Ageout from 1000 to 10,000 (or similar number).

I try to encourage the Guest SSID duration to 24 hours or max of 7 days, but one customer has asked for 60 days.


They will expect to not have to log back in each time the following day, or after the weekend, (using Cloud RADIUS Self-Registration) so I suspect the min cache to be 63 hours to cover from Fri 5pm to Mon 8am.

Total roaming cache: 120sec x 1000 = 33hrs. Plan to increase Roaming cache update interval to 240sec to achieve 66 hours.

Do you feel increasing from the default 60sec will have any adverse impact to AP roaming?




Userlevel 1

Hi Jason, unfortunately I don't have visibility in to feature requests any more, you'd want to ask your sales engineer to see where that request stands today. If you're unsure who to reach out to for your sales engineer I can email you their contact information, just let me know.


Also, I don't think you'd have any issues with roaming using the settings you've outlined.