I have an ap350 v11.07 with mac os 10.x powerbooks and ibooks, also with 350 and 340 clients. We enjoyed several months of trouble free operations. Recently someone on another floor in our building is using a linksys on channel 6. We found this by shutting off our ap350. Since then the 350 drops clients randomly. We have tried to change channels to 1 and 11, use the 'least congestive channel' option, upgraded to 12.01T. No change, all client types can not stay on. Sometimes it works for an hour, sometimes 30 seconds.
The problem as I understand it is that his clients are roaming to a AP that is NOT controled by his company and as such filtering will not help however it would be a good idea to ensure that the other companies clients do not roam onto his AP
If I have misundertood the problem please let me know
No, you it right. I tried a few things before I got your post and we seem ok for now. I spent about 4 hours on this so I know alot more now. I was not running the default ssid, it was a 16 character name with caps and lowercase letters. I changed it to an all lowercase 7 character name and all the client reassociated the second I hit apply. Ran like this for an hour and then I decided to do the radio diag and found that channel 11 was the least busy.
So I set the channel to 11 and set the ap350 to not use channel 6. We are using mac filtering and have been right along. Broadcast ssid is set, I will also try turning that off. I need to get my home users to deal with this. Remember I have non-aironet clients so making client changes isn't really an option.
The thing I learned from this and maybe you can confirm, is that the ap350 seems to give up if there is congestion on a channel. If some other wireless device is using the same channel, the ap350 wouid go into blocking or even 'broken' message on the radio status. It doesn't really find another channel and all the clients just fall off the wire(less)
Bottom line, I have had 36 hours troublefree, we will see how long this lasts..
"The thing I learned from this and maybe you can confirm, is that the ap350 seems to give up if there is congestion on a channel. If some other wireless device is using the same channel, the ap350 wouid go into blocking or even 'broken' message on the radio status. It doesn't really find another channel and all the clients just fall off the wire(less) "
If the AP does not see a client for an number of beacons (can not remember the exact number right now) then the client will be disassociated due to inactivity If the AP has NO clients associated to it you may observe that the radio port is in blocking mode.
If a client misses a number of beacon frames from the AP then it will disassociate and try to roam to a new AP
In a congested radio network or in a poor RF environment the beacon frames can be received with packet CRC errors which means they will be dropped at a hardware level and as such they are lost, if you expand this out you could be unlucky enough to have several beacon frames in a row be received as CRC errors and as such the client tries to roam.
You can configure the AP to scan for a less congested channel but the problem is it only scans at start up or if a radio setting is changed (causing the radio to restart) so if the other companies AP wasnt there and transmitting at start up then it would not be seen in this scan.
Ok, that sounds like what was happening to us. I noticed on the ap clients, there is a counter, PLCP Format Errors, that would increment very quickly when a client could not connect. Maybe this is why.
Any thoughts on why changing the ssid allowed clients re-connect so quickly? That seem a little strange. We are still working fine on channel 11 with ssid broadcast still on.
"Any thoughts on why changing the ssid allowed clients re-connect so quickly? That seem a little strange. We are still working fine on channel 11 with ssid broadcast still on. "
You need to do further investigation with a sniffer or something like netstumbler but I susspect that both you and this other company had the same ssid or they were allowing any SSID to associate the point of turning broadcast ssid off was to stop them seeing your ssid and then trying to associate
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...