Wireless Access

In the last couple of days I've seen at least 2 APs change channels when they had clients connected.  Client aware is enabled for these APs.  Is there any reason why an AP would change channels even with this feature enabled?

Please know that ARM client aware is enabled per band, so you would babe to enable it in the rf profiles for both bands.

cjoseph: both bands are using the same rf profile which has client aware enabled.

If this feature is enabled, the AP does not change channels if there is "active client traffic" on that AP.

so, If there is no client traffic, channel is change.

 

client traffic not equal client associate

Morisaki: While I'm sure that's true, it seems hard to believe that these clients on the AP were not talking at the time. There were several windows computers connected running fairly chatty programs - MS Lync and Outlook connected to Exchange.  Is there a timer that says if client traffic = 0 for X seconds/minutes then change channels?  If so, what is X and the measure of time?

Approximately 1 minute as far as I know.

 

Do you know for sure that there was always a client associated?

---

@cjoseph wrote:
Do you know for sure that there was always a client associated?

---

@The last time I saw an AP (w/ client associated) change channels was last Friday @ 4:30PM.  According to Airwave, this was the last AP the client associated to before he got disconnected from wifi.  I didn't see the client associate with any other AP until AFTER he got disconnected.  Provided that the information in Airwave is correct I am relatively confident that the client was active on this AP when the channel changed.

---

@thecompnerd wrote:

---

@cjoseph wrote:
Do you know for sure that there was always a client associated?

---

@The last time I saw an AP (w/ client associated) change channels was last Friday @ 4:30PM.  According to Airwave, this was the last AP the client associated to before he got disconnected from wifi.  I didn't see the client associate with any other AP until AFTER he got disconnected.  Provided that the information in Airwave is correct I am relatively confident that the client was active on this AP when the channel changed.

---

Compnerd,

 

Let's troubleshoot the issue, instead of client-aware.  As far as we know, client aware works and the majority of clients, when the access point changes channel, are scanning to look for other access points.  This is common.

 

You would have the problem when access points change channel, if your access points change to a channel that are not supported by your clients...

 

I know the channel is supported by the client because the client is now associated to the same AP on the same channel it switched to on Friday.  Friday before the client got disconnected, .11an was on channel 40, then switched to 149.  The AP is still on channel 149.

 

Looking at the syslog output, I see that the channel changed at 16:29:40 and at 16:29:41 the following message event was logged for the client's MAC "WPA2 Key message 2 from station .... .... did not match the replay counter 01 vs 02".  Any chance the two are related and explains why the client got disconnected?

There was another instance last Wednesday where I had 12 clients all get disconnected from this AP that we're discussing.  At 12:59:17 the AP changed channels, from 161 to 48, then a second later I saw 8 consecutive WPA2 Key messages logged.

What version of Aruba OS is this?

If you have not opened a support case, please do so.  We will then be able to collect detailed information about your issue.

 

6.1.3.4

 

I reported the issue to my SE last week and he opened the case with support.  Support wants the the logs.tar at around the time the error occurs.  I wasn't able to get it fast enough last Friday, so I sent them the syslog output in hopes that it would be helpful.  In the mean time, I thought I'd throw the question out to the community since there are a lot of sharp people on here.

---

@thecompnerd wrote:

6.1.3.4

 

I reported the issue to my SE last week and he opened the case with support.  Support wants the the logs.tar at around the time the error occurs.  I wasn't able to get it fast enough last Friday, so I sent them the syslog output in hopes that it would be helpful.  In the mean time, I thought I'd throw the question out to the community since there are a lot of sharp people on here.

---

The replay message normally occurs when there is interference, congestion, or if the drivers on a device need to be upgraded.  It could be a combination of all three, but support should determine what your issue is, because they have all of your info.