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.

[AnonymousM]

Hi,

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.

thanks,

Jason

[barry_mcnicholl]

@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?

Thanks

[AnonymousM]

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.

[samantha_lynn]

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.

[AnonymousM]

@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.