Hi there, got a problem with the radio interface on AP350s and 1200s (11b & g, running IOS), occasionally (and not on the same units) the RF interface will lock up and any clients associated to it will not be pingable and lose network connectivity. Doing a shut/no shut (and usually a reload) bumps the clients off to other APs where they're pingable once more. This happens to Cisco and non-Cisco radioed devices, the APs aren't running anything fancy like WDS, just default config. and WEP. The 350s never had this problem running VxWorks but started this behavior when upgraded to IOS. I'm real disappinted the 1200s are doing the same thing. When the lock ups happen it causes major problems at our locations and I need to find a cure...now! Any ideas anyone? Thanks.
The 350s use the IOS upgrade image, the 1200s use the latest IOS version. The only rogue APs I have problems with are the Ciscos running IOS! Symbol and first generation 802.11b Aironet (pre-Cisco) APs aren't afflicted with this problem even in a mixed AP environment. In locations that are all Cisco APs and devices we still get this problem. The APs are in locations countrywide and away from Joe Public, and no other WLANs nearby. I think, I HOPE it's just a config. problem but all the APs have (more or less) the same standard config. and the issue strikes APs randomly. As advised, as soon as you do a shut/no shut everything's OK...the devices that got bumped off by the s/ns usually 'roam' back to the AP that had the issue within a few seconds or minutes and are pingable once more from the AP's radio interface. I was paged while typing my question last evening and when I went to check, guess what, another 350 with 6 clients (all Cisco devices) all jammed up on it. Shut/No Shut and carry on like nothing happened. If you've got any suggestions I'll take them, I've not had much luck on the Cisco web site, I'll probably have to put in a TAC case at some point soon as I've got better things to do than go around resetting APs. I was even thinking about rebooting our Cisco AP complement once a week in case it was some sort of caching/ARP problem.
Are you seeing Authentication Failed messages in the AP logs? I have seen mis-configured clients create memory fragmentation, eventually leading to malloc errors -- an accidental DoS? Rebooting seems to clear it up but its like plaque -- you have to floss. There's a recent Security advisory about ARP attacks that suggests up-ing to 12.3.7(JA2?) and adding a filter command. Perhaps this would kill two birds...
All of the clients have a common configuration for their type. They're DR-DOS basic handheld scanners and MS-DOS basic POS terminals, so nothing fancy. The issue with the RF interface can happen to any of our complement of IOSed APs at any time. I would say we have at least two occurrences per week in geographically separate locations throughout CONUS causing disruption to retail and warehousing operations. I've opened up a TAC case and am waiting for Cisco's response. I'll advise on what they come back with. We never had this problem with VxWorks, just since IOS was introduced to our APs. As for the flossing(!) that's what my once a week reboot suggestion was going to achieve....hopefully! I thought flushing the cache or blowing out the cobwebs once a week might help, but I don't see why we should have to do that.
I have experienced a similar problem with 340/350 VxOS APs. The APs will disassociate all clients and not accept any new connections until the radio interface is put down and brought back up.
The solution I use is to SNMP poll the APs and take differential connection snapshots, if the number of clients goes to zero the radio interface is recycled. This has been a problem up through and including 12.05. I have not yet seen this problem.
Something to check, make sure you do not have unicast flooding control set on the FA interface, I have seen flakiness in the IOS based APs when this is enabled with VLANs.
A less than ideal solution would be create a monitoring script which extracts the dot11 associations from the AP, pings the device, and if the ping fails to all associated clients, recycle the radio. It is ugly and cludgy, but until the AP team at Cisco works out the bugs or someone comes up with a fix, not sure of the options.
The clients don't disassociate, the AP won't let them! They're just locked on to the AP and can't be moved off without a shut/no shut. I never had this problem with VxWorks, just since we upgraded the 350s to IOS and then since I've installed some new AP1200s.
I'll check the unicast thing and we had considered the ugly script method but right now Cisco have this on their plate as a Severity 2 TAC case.
I'll get back to you when we get some results or responses.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...