cancel
Showing results for 
Search instead for 
Did you mean: 

Users have to re-authenticate

it_support_6355
New Contributor II
Hi,

We have a Zonedirector that's broadcasting 2 SSID, one for guests and one for internals that has Web Authentication configured with our AD.

We've had several users complaining that they lose connection and have to re-login to the portal. In the log we see the following entry when it's happening:

2014/02/13 13:40:45 Low User[user1] fails to join WLAN[Internal] from AP[ap01]
2014/02/13 13:49:27 Low AP[ap1] radio [11g/n] detects User user1 in WLAN[Internal] roams from AP[ap1]
2014/02/13 13:49:27 Low AP[ap1] radio [11a/n] detects User user1 in WLAN[Internal] roams out to AP[ap01]
2014/02/13 13:40:45 Low User[user1] of WLAN[Internal] is authorized at AP[ap01]

It looks like it's roaming between the radios and then fails to join. Is there any way to find out why it's failing?
7 REPLIES 7

sid_sok
Contributor II
Primož Marinšek is correct, though "spoiled children" might be a bit strong, but essentially correct. In this situation we have to separate two things, 802.11 connection state and the system authorization state.

As noted earlier if you do not have the grace period set, every time a client disconnect, the system will clear the client's authorization state, so when it comes back in it has to re-login, to prove it's identity. With the grace period set the next question to address is the client 802.11 connection/disconnection state.

Unfortunately there is no standards for client behavior, only some general rule power level, data rates and medium access protocol and a few others. Clients have different roaming algorithm, some may look at only signal, some take into account datarate, retries, beacon health, security and so on. To add to that, in a dual band environment the client now has a choice between band with the exact same settings. A good client behavior, give all things being equal should chose the band that has more bandwidth, 5 GHz for example, but generally speaking 5 GHz coverage may vary a lot more then 2.4 especially where the channels goes from the lower/mid band to the higher band. Client may not like the 5 GHz for that reason. Client behavior will vary between chipset and in some cases even with the same chipset different laptop vendor can also add their own flavor as well, so generally client behavior is unpredictable.

Some client allow user to control some of these behavior, Intel dualband client for example allows you to set the roaming aggressiveness, not what it uses to decide to roam but how aggressive it uses the algorithm. It also allow you to set a band preference, but even then it's a preference and not a strict mandate to stay on a single band. That's just the surface, with this one example, the radio can be controlled by Windows (WLAN services), Intel's Proset or a third party supplicant like Odyssey client software.

Given the log above, and assuming that the client is using windows supplicant, I would suggest running a test wlan that is only broadcasting on a single band, on the 2.4 or 5 GHz radio if the coverage is there and see if the client is still have a problem with excessive roaming.

If you don't like my "spoiled children" analogy, how about a "rebellious teenager"?

lol, more like "teenagers", there are lots of them and they tend to give me headache, which I am looking forward to in a few years as my kids hit the teen years.