Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
We have a Cisco Unified wireless network on our college campus. There's an area of one of our dormitories where people are having an issue where they keep disassociating and reassociating to our wireless network. We have pretty dense coverage in that area (generally get about 5 bars,) and I haven't seen the issue in other areas on our campus. Anything in the area I should look for that could be causing that problem, or could it be a problem with out setup.
A few things an cause clients to bounce on and off a wireless network.
- Interference is a likely cause of a client to get bounced. Do you have a spectrum card that you can take readings?
- Malfunctioning Clients - I am assuming your client base is a wide mix based on you mentioning that you are a college campus. Is there anything in common with the clients that are getting bounced.
- Is the controller that is handling the access points for this building in the other controller domains?
- Is there a pattern to the disconnects. Does it happen around the same time each day?
I'd like to find out what the controllers' error logs.
What are the error messages reported from the clients' side?
Do the clients get Authenticated at all?
Every client I've tried over there will do it. Even my own laptop. I did notice this error in that area: Decrypt error occurred for client '00:22:5f:0a:a8:0c' using 'Unknown' key on '802.11b/g' interface of AP 'newdorm-b2-3-4'. This error comes up constantly. We're using an open network in that area so I don't know why I'd getting decrypt errors. All the APs in that whole building are on the same controller, with the same SSID, same mobility group, etc. There IS an AP on the outside of the building in a different mobility group but it has different ssids broadcasting. We do have a "secret" WPA2 802.1x ssid that doesn't broadcast, but no one knows about that but us IT folks.
What about the possibility there are too many APs to choose from, causing association thrashing? Try turning down the power and/or upping the minimum (Basic) data rate. Are the clients a/b/g? They could also be flapping between radios. Try fixing them to a single spectrum to see if they stabilize at all. I'd also disable all active (deauth-causing) Security Policy features.
I'm going to try disabling the A band and upping hte basic data rate. This is of course the one building I don't have heat maps in my WCS (due to lack of floor plans, going to try to aggressively push for our facilities department to give us some) for so it makes it much more difficult to troubleshoot.
I did the following which seems to have fixed the association bouncing:
- Disabled the A band on all APs
- Set minimum data rate to 11 MBPs.
- Checked off "Avoid Cisco AP Load"
I want to try to figure out which of these acutally fixed my problem. Any thoughts?
Still having major issues with this. Clients are essentially bouncing between various access points and its literally happening every few seconds to 5 minutes. While the earlier steps I took improved the situation for some people, it's still occuring in other places. I never had this problem last year. Over the summer we upgraded to version 6.0 of software on all our controllers. So I don't know why this is occuring now. Is there any other settings I could try?
I would like to apologize for not reading your issue properly.
So you are saying the clients in a specific building is experiencing bouncing from one AP to another?
I was once doing a site survey and when I turn around a particular corner of the floor (where the AP is), my Airmagnet would crash and send the OS into the ubiquitous BSoD. After trying on another laptop with the same result, we decided to check the machinery room upstairs (directly above the AP) and we concluded that some kind of electrical interference is causing some kind of "jam" effect.
This dorminotry in question, do they have some kind of legacy-type machineries (mechanical and/or electrical)? Is this affecting the entire dormitory or just a few of the floors?
What do the RF measurements look like? They must be thrashing for a reason. I take it this code is in use elsewhere where there's no such phenomena?
Co-channel? Can you turn off the BG and see how only A clients behave?
Multipath? Try putting an 1142 in there.
Do you have Cognio (Cisco Spectrum Expert)? Probably a good idea to have anyway.
Get somebody out there with a wireless packet sniffer and a spectrum analyzer... you'll know in 10 minutes what's going on... smells like interference or a bad AP to me.
TAC lended us a cognio specturm card. We also did some wireless sniffer capture and they did not see any deauth packets or anything like that. As far as the cognio spectrum card, they said they are seeing some type of interference across all the channels and some strange devices showing up. We're going to try to look into that. The one thing that's weirdest about this, is that when I reboot all the access points, it stablizes all the clients for about a week or so, then the problems start slowly creeping back again.
This is pretty much the same issue we are having as a result of CSCta29484. The APs are down long enough to force the client to roam, and up long enough to let them roam back. I didn't see what APs you were using, but ours are 1231s. To confirm, enable telnet/ssh on the AP and issue "show controller dot11 0 | i Beacons" every couple of seconds for about a minute and you'll see "Beacons are disabled" in the output for a period of about 10 seconds at a stretch. Reboot the AP and it's fine for a while. TAC says it will be fixed in the next maint release. -JC
Yes tac is starting to point us in that direction too. In areas where this was happening I found a client with that particular power saving mode. I turned WMM off campus wide and rebooted all APs. I'm keeping an eye on a few clients now.
Is it normal for beacons on an AP to EVER be shut off? I noticed once while doing that that they shut off for a split second (certainly not 10 seconds)
Hey - We at Hamilton College are having EXACTLY the same issue. We run only b/g in the dorms. This just started this semester (upgraded WISms to 22.214.171.124 code in August) - We had been running for 2 years without any issues.
We are working with TAC also and are trying a few different things on these radios. I'll keep you posted.
I asked the same question of TAC and they indicated that it is normal to see beacons disabled while the AP was off channel scanning. When the beacons are off due to the bug, multiple iterations of the command show it disabled for a total of 10 seconds or so (at least on our network).
I would like to look into the issue of interrupted beacons. Can you tell me how it is possible to enable telnet/ssh on a lwapp access point? TIA
I believe the beaconing issue has been addressed with a new firmware release for the wireless controllers that came out 2 days ago. We experienced similar problems as described in this posting and have noticed an improvement since we applied the new release.
The new version is: 6-0-188-0.
The problem was most noticeable to our voice users. We also had to update the 7925 phones to code 126.96.36.199.3 that can be requested via a TAC case. Talk about perfect storm in a wireless environment when everything has problems and it gets hard to identify a single source when in reality everything has issues....
Just curious, but what was the issue that was corrected in the phone firmware? Have you had any other issues with the new code? -John
This is the phone bug list:
Build 188.8.131.52.3 (11/02/09 - rel_1_3_3)
CSCtc36980 7921 running 184.108.40.206.2 stuck in "Configuring IP" after deauth
CSCtc43993 Should not make WLAN go active with ClearPrompt SCCP msg
CSCtc44631 CUCM: JPN: 7925 cannot select menu/help more than 36 bytes
CSCtc54410 7925 with voice gaps with inbound/outbound PSTN calls
CSCtc73949 7921 hangs due to DSP CPU Time starvation/DSP MMU abort
CSCtc88591 add Wistron LCM phone to supported HW_REV list
Build 220.127.116.11.2 (09/09/09 - rel_1_3_3)
CSCta47991 Missing beacon improvements in firmware
CSCtb45669 792x is not reprovisioning after receiving Wavelink package
CSCtb49823 support for virtual host web server on 7921 and 7925
CSCtb55584 7925G phones MWI light not properly displayed in deviceinformationx
Build 18.104.22.168.1 (08/13/09 - rel_1_3_3)
CSCta21688 Certificate download report MAC error and unhandled page fault
CSCta24387 Support Restriction Bit in CallInfo
CSCta28990 792xG can intermittently get stuck with empty prompt message after power
CSCta35313 7921 misinterpretes Idle URL with & (ampersand) character
CSCta38016 REFRESH header being triggered out of context
CSCta46131 CP-7921G NOT handle multiple entries in the DNS response
CSCta85098 Date/Time can get reset if the 7925 battery is drained
CSCtb12622 Auto logon on Personal Address Book is not working.
CSCtb24430 792X:call transfer using directory search failed
CSCtb37829 TSpec failure leads to chronic no_scan_complete failures
We had this issue with 7925G om CME 7.1
New firmware got rid of our problem...
BTW , we have seen the 7925G phone resets a couple of time during the day.. i dont know if any of you guys have had the same problem ?... anyways.. 22.214.171.124.3 seem to have solved that too.. i hope :-P
We had a big eye opener with Cisco on Wednesday. We had the whole time problems with the 7925 even after the firmware upgrade of the wireless controller/APs and the phones. The problems ranged from very poor voice quality, to dropped calls, to a nerving clicking in the voice,... The wired thing was that this had nothing to do with roaming since even users that were sitting in the same room as an AP had these issues. They might have had a great day, but then again all the sudden had static background noise, voice distortion, interrupted voice streams, ... We tested 7921's and softphones and did not run into these problems while being at the same location as the 7925s. We tested this with an internal conf call from a 7961 that involved the WiFI phone types (7921, 7925, IP Soft phone) and walked the same path. Only the 7925 showed really bad quality while the other ones had very good results. We asked Cisco a couple of times for the differences between the phones and constantly were told that the main difference is that the 7925 has bluetooth built in and is more ruggadized. Other than that it is pretty much the same as the 7921.
I don't know why, but Cisco TAC still wanted me to troubleshoot the 7925s. Since this did not come to a conclusion after another 3 weeks management gave an ultimatum. This resulted in a new Cisco TAC support person who went through the same tests again. When we asked him again for differences in the phones we had a revalation - the 7921 has two antennas and supports diverse path but the 7925 has only one antenna and can't handle multipath well. This finally answered a lot of our questions and we are now no longer looking into wireless issues but device issues. Cisco is going to replace all our 7925's with 7921's.
I wish this information would have been disclosed earlier to us since it would have helped us tremendously with the project . I also don't understand why Cisco takes such an important feature away from its "next generation" phones....
Our APs were 1250s running 12.4(21a)JA1. APs that were configured as WDS refuse to take any clients, including the phones (CP-7921/7925). The phones will associate to any APs even (except the WDS) if the WDS is the nearest and/or has the strongest signal. It is as if the WDS is refusing any associating/authenticating request.
Everything started normalizing when I downgraded all the AP's to 12.4(10b)JDA3.
I've created a TAC Case and after 2 weeks or so, the agent was unable to replicate my issue. I didn't care. This problem was affecting a number of sites and only an IOS downgrade fixes it.
Im sorry to hear you're still having problems
We are "out of trouble" now and it seems to work fine (fingers crossed)
Thank you for info on antennas..Still , Cisco must have had a reason for taking away the second antenna ?
Our users are so happy with the new bluetooth feature in 7925G and it will be a pain to replace them with 7921.
Lets hope for a new well improved 7926G in near future
I have recently migrated from 7920 phones 7925 (1.3.3) phones and i' m having problems in outdoor area. Voice gaps,no association,no audio etc.
7920 phones and 7921 (1.3.2) are working fine in these same Area. My outdoor AP's are 1231 and 1300 with one 5dB omni-directional antennas each.
My WLC is on 126.96.36.199 version.
It seems to me thats could be a firmware issue did you have to open a case to requeste firmware version 188.8.131.52.3?
In you case upgrading only phone firmware didn't help right?