Users have to re-authenticate

  • 1
  • Question
  • Updated 3 years ago
  • Answered
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?
Photo of IT Support

IT Support

  • 3 Posts
  • 0 Reply Likes
  • confused

Posted 4 years ago

  • 1
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
It sounds like the grace period is not checked. Without a grace period every disconnection will result in the client going into an Unauthorized state. Check the "Advanced Options" section of the wlan with WebAuth and set the "Grace period". By default it's 30 minutes. The 30 minute is from the time the client was last seen, not from when it first connects.

Users should should not have to re-login if they disconnect and reconnect within the grace period.
Photo of IT Support

IT Support

  • 3 Posts
  • 0 Reply Likes
Correct, we had it checked on the guest wlan but not on our internal.
It's enabled now. Thank you!
Photo of IT Support

IT Support

  • 3 Posts
  • 0 Reply Likes
Well it seems like the grace period setting solved part of the problem. As you can see below, user re-connecting within the period is connected without the need to re-authenticate. But we still see a lot of disconnects like this one, and it always seems to happen when roaming between radios on the same AP.
Is there any way to disable this?

2014/02/25 12:55:21 Low User2 User[User2] fails to join WLAN[WLAN_INTERNAL] from AP[AP2]
2014/02/25 12:55:21 Low User2 AP[AP2] radio [11a/n] detects User[User2] in WLAN[WLAN_INTERNAL] roams from AP[AP2]
2014/02/25 12:55:21 Low User2 AP[AP2] radio [11g/n] detects User[User2] in WLAN[WLAN_INTERNAL] roams out to AP[AP2]
2014/02/25 12:51:07 Low User2 User[User2] joins WLAN[WLAN_INTERNAL] from AP[AP2]
2014/02/25 12:51:07 Low User2 User[User2] reconnects to AP[AP2] within grace period. No additional authentication is required.
2014/02/25 12:07:08 Low User2 User[User2] leave WLAN[WLAN_INTERNAL] at AP[AP2] with Session Time[449.01 sec] RX Bytes[1878883] TX Bytes[3346951]
2014/02/25 12:07:08 Low User2 User[User2] disconnects from WLAN[WLAN_INTERNAL] at AP[AP2]
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
This is normal. Client stations are like spoiled children. They do what they want and the AP obeys. 802.11 doesn't define a super nanny that could straighten them out.
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
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.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
If you don't like my "spoiled children" analogy, how about a "rebellious teenager"?
Photo of Sid Sok

Sid Sok, Official Rep

  • 102 Posts
  • 48 Reply Likes
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.