WLC 5520 8.2.130 and cleanair on 3802e/i APs 2.4 GHZ

[Clem58]

Hello,

We have a WLC, central, with flexconnect and capwap, we have 12 3802E/I APs and 30 Zebra Scanners MC92N0.

Since 6 months we have been facing some weird issues with the scanners, they kept de-associate and re-associate in random AP, let them disconect a lot.

After some advices from a wireless expert, we chose to use custom channels (1,6,11) and custom tx power (1) for our APs, and 2.4 ghz (802.11bgn).

After 2 months of working well, we decided to tune a little more, choosing to use only 802.11bg in WLAN/SSID.

Since this change, and maybe due to the fact now all the scanners are on the same SSID/WLAN and running, the MC92N0 started again to swap between APs in static position.

After doing again many researches, I found that cleanair could be the source of the problem, as I disabled cleanair and no more APs swapping is occuring.

When I disabled cleanair, the APs did not restart, but the MC92N0 were really lagguy and timed out, then I reboot all the APs and now connexion is good. Do you think it's normal that we need to reboot AP ?

By the way, do you think it's proper to set also custom channels, custom power and Cleanair disabled on the 5 GHZ band ? Maybe it could cause some conflicts or other ? Are these parameters completely independant ?

Concerning the MC92N0 bug/issue with cleanair, I don't understand really what's happening, do you have an idea ? A bug, a problem with flexconnect/capwap tunnel and cleanair packets, or CCX ? Maybe disabling Aironet IE could be improve something ?

Thanks by advance,

[Rasika Nayanajith]

If you have other AP models that require you to be in 8.2.x, then I would go to 8.2.170.0 first. Then see if this continues.

If no limitation on existing AP models, I would go with 8.5.135.0 with your 5520 & then see.

Here is WLC compatibiity matrix for your reference

https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html#56735

HTH

Rasika

*** Pls rate all useful responses ***

[Clem58]

Ok, thank you for your help, as our WLC is a global one, we will have to schedule ASAP an upgrade then.

Another question, I've just noticed that the 5GHZ RF profile is set for DCA in 20 Mhz channel width:

As the 2.4Ghz are in 20Mhz channel width, I assume, could it cause some troubles or issues ?

[pieterh]

check if cleanair initiates change of channel on the APs? (because of detected interference)

changing channel will disassociate the device from the AP

as the scanner supports IEEE 802.11 a/b/g/n,

my suggestion is not to disable "n" and switch to b/g,  but to disable "b"

Because b uses a different radio-technique  than g/n,

using mixed b/g causes a lot of airtime to be waisted 

also if the scanner persists association to the current access point and the signal drops it will fall back from g to b

maybe the scanner also supports switching of 802.11b?

[Clem58]

Yes it's supported, we need the B radio because we have some RFID Zebra MC9190 scanners that need this radio to be able to associate. If we disable all data rates below 12 mbps with 12 mbps mandatory, or use 802.11g only then the MC9190 times out when it try to associate to an AP.

[pieterh]

that is odd?

the integrators manual report this device is 802.11a/b/g capable?

 does also this happen with an "out-of-box" device? or only with a scanner application installed?

in last situation the app may configure some wlan settings that interferes with 802.11g only.

it looks like this scanner only searches for beacons on 802.11b (on 1Mbit) but it should also be able to connect connect to 802.11g and even 802.11a!

have you contact the manufacturer about this? the device may need some wlan driver update

the release notes (i only checked one version) mentions some issues reolved

• SPR 31247 - Fixed an issue in which the WLAN radio fails to roam sometimes when Fast Transition (802.11r) is enabled on the infrastructure.
• SPR 30135 - Resolved an issue in which WLAN radio does not roam to DFS channels that resulted in stickiness or disconnect.

[Clem58]

Yes I know I've already searched about that, and it seems strange behaviour. MC9190 have the last fusion drivers and MC9090 also (old scanners I used for test), and they cannot connect if we don't enable one B data rates.

I'm wondering if maybe some packets are dropped or corrupted in the capwap tunnel, I see that DTLS encryption is configured on the capwap tunnel, but not on APs, should it be set ?

[pieterh]

in the section Restrictions on Data Encryption in the configuration guide, cisco advices negative.

• DTLS data encryption is enabled automatically for OfficeExtend access points but disabled by default for all other access points. Most access points are deployed in a secure network within a company building, so data encryption is not necessary. In contrast, the traffic between an OfficeExtend access point and the controller travels through an unsecure public network, so data encryption is more important for these access points. When data encryption is enabled, traffic is encrypted at the access point before it is sent to the controller and at the controller before it is sent to the client.

• Encryption limits throughput at both the controller and the access point, and maximum throughput is desired for most enterprise networks

[Clem58]

Ok, capwap tunnel data channel is automatically encrypted ?

I mean, our configuration seems to be like that (I have sniffed a APs port with wireshark) :

WLC -> CAPWAP tunnel 5247 UDP port data encrypted packets -> APs (3802I or E)

APs (3802I or E) -> CAPWAP tunnel 5248 UDP port NO data encrypted packets -> WLC

As our APs have not Data Encryption enable.

Is this a normal configuration ?

[Clem58]

I have found this setting on our WLC:

And we can read this warning, at the bottom of the page

We are doing Flexconnect with Local switching. Could this multicast setting cause some troubles ? I don't understand why this setting is enabled if it's not supported in Flexconnect mode ?

[Clem58]

In fact Multicast on WLC is disabled globally, so I assume this setting is not taken in account.

But in the Wireshark analyze log, I can see sometimes the AP is trying to do multicast and join the same multicast group IP there is in the General tab of Controller in WLC: