Is anyone else seeing issues with their 5508 WLC on code version 18.104.22.168? We did the upgrade in order to support the new 2802/3802 access points and have been seeing some strange issues ever since. The most problematic issue has been that 3702 and 2702 access points just seem to refuse to pass traffic when trying to access random websites. If we put a different model in place of the problematic one, the users are then able to go to those websites. Has anyone tried the 8.3.x.x releases, yet? Is it more stable? Thanks for any input.
Solved! Go to Solution.
Regarding CSCvd89994 - it's a dup of CSCvd79745. which is fixed in 8.2MR5esc and 8.2MR6. (Btw 8.2MR6 i.e. 8.2.16x.0 should release to CCO very soon.)
I will note that Cisco development does not support WPA2 + MAC filtering + WebAuth ... so if that's what you're doing ... then it's expected not to work.
Hope this helps,
You may want to read the bugs/issues from the release notes, and it is always prudent to go with the latest MD (mainstream distribution). Seeing that there is no MD for 8.2, you may want to try 22.214.171.124. There is a list of bugs relating to your 2800 and 3800 AP's. I pasted the release notes for 8.2.121 below
I also have strange problems running FlexConnect on a Cisco 2802 AP connected to a 5520 controller running 126.96.36.199
One of the bigger problems is that the clients sometimes doesn't get an IP address from the DHCP server
I have tried to connect an old Cisco 1142N AP and then the problem has gone
I really hope Cisco will fix the problem fast
Exact same issue here less the FlexConnect. Same code on the same controller
We've found that if you disable the 5GHz radio, the problem goes away.
TAC case is open. Will post results/resolution.
I have code 8.2.130 (most recent) on 5508 and new 2802. Seems to be very similar to what people describe here.
We noticed that when clients are on 2802 5ghz. We get issues simply passing traffic. Can´t ping default gateway e.t.c.
with older APs everything is just fine.
First we saw radar issues on indoor channels. It is being filed as a new bug. But I don´t think that is the root cause anymore.
Has anyone some news about this ? Doesn´t seem to be working well even though I am at 8.2.130
I have the same issue with 2802 on code 188.8.131.52 and WiSM2. Local mode AP's. Problem with 5GHz. No problem with 2.4GHz. Older AP's working fine.
Hey Joseph, what's your email address ? I can send across something which might help, there has been similar bugs, for instance CSCvb50962 is similar to your issue but effect different AP group.
We are also running 184.108.40.206 on both 5508's and 2504's with a mixture of 2802/1702/3502/1142's
The main problems I have seen are with the 2802's
They sometimes stop accepting client associations until the AP is rebooted whilst appearing to be functioning normally from the controllers perspective. This happens when the AP is registered to either the 5508 or 2504.
The other issue we get quite a lot is specific to just the 2802 on the 2504 WLC where the AP crashes with reason "AP crashed due to software failure"
guys the same exact thing here -- those AIR-AP2802I-B-K9 APs are terrible. exactly the same symptoms as described here. running code 220.127.116.11 and no change from 8.2.x
Some times clients won't associate; other times they will but no traffic is passing. If you reboot the 2802 then it starts accepting additional clients (those clients already connected continue to work fine while at the exact same time new clients can't associate or they do but can't pass any traffic/or can't get DHCP).
Obviously any other AP works just fine on the same code, same WLC and same switch port; same exact configuration. Just as all of you have observed this is a defect with the 2802 APs and has nothing to do with code version or "other mysterious" network problems.
lawsonadrian you were the latest post - any ideas?
This is just terrible! Anyone has any solution do post! The bug check reported earlier does match the symptom but the remedy isn't permanent (reboot AP): https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb50962
I am testing the channel bonding suggestion which so far could be the only credible permanent remedy to the defect: Issues AP 3802i -S with WLC 5520 client cannot transmit data (This will happen with channel bonding of 48,44,40,36. However if the AP uses the channel bonding of 36,40,44,48. The problem doesn't occur). I will post results on the AIR-AP2802I-B-K9 using that channel bonding combination.
I've received an update from TAC that a fix does exist in the form of another AirOS image: You could use either AireOS version 18.104.22.168 or escalation image 22.214.171.124 (TAC special publish)
Did 126.96.36.199 or another Aireos work ?
Looks like I also have such a problem.
I use 5520 with version 188.8.131.52 and AP 2802I, now I also tried 2602I same problem.
First connect works well, but reconnect does not work anymore until I deauth the client session.
We're in the testing phase following a downgrade to 184.108.40.206 -- I won't make assumptions whether this fixed the issue or not for at least a month with zero issues. The downgrade happened over the holiday weekend so we're about a week into the testing period. So far so good.
If you're having the same problem with 2602i then we're likely NOT experiencing the issue described here. The issue described here explicitly occurs with the Wave 2 APs: AIR-AP2802I-B-K9 and similar Wave 2 models. With 2602i we never had the issue and from reading in the forums neither did the other participants in the discussion.
So in summary I can't speak to your situation but it does appear different if you're having the issue across the board with any AP, not just AIR-AP2802I-B-K9
thank's for the answer.
looks like I do have https://quickview.cloudapps.cisco.com/quickview/bug/CSCvd89994
Unfortunately description changes essentially when I am logged in with CCO account. Because of duplication.
Without CCO Auth I have a full match to my problem.
Maybe our Partner Support will open a TAC-Call on the problem.