Disassociating [10.0.1.15] 00072570a26e, reason "Sender is Leaving (has lef

[jreimer]

I get the following message, and all of my clients get kicked off. They then re-associate. What is this?!?!

Disassociating [10.0.1.15]00072570a26e, reason "Sender is Leaving (has left) BSS"

[amitubale]

Is it just one AP ?

Does it send messages to a Syslog server ?

Check the Up time on the AP, to see its constally rebooting.

If you are using a Cisco wireless card, try increasing the No. of Retries.( the deafult is 32, increase it. The client tires 32 times before desiding to assocaite to another AP)

[jreimer]

I have a couple of 1200's and three 350's non of the 350's do it, but both 1200's do. it kicks all clients off at once. Then they all come back on in a couple of minutes.

I updated the firmware from 12.01 to 12.02T1. This did not help.

The AP is not rebooting constantly nor at all from the logs. I don't have a syslog server server set up.

The clients are Lucent Ethernet converters with Orinoco cards in them. But since they all die at once, it doesn't seem to be a client issue.

What does the "Sender is leaving (has left) BSS" mean?

Thanks. - Jay

[jreimer]

I have a Hyperlink amp on this unit. Could the AMP be causeing the BSS kicks?

[derwin]

The error message you are seeing is a warning message saying that the client has moved out of range of the AP and has NOT roamed to another AP that the AP knows off and therefore is outside of the BSS

The use of a amplifer is NOT recommended or supported by Cisco and will mean that it is up to the installer to seek FCC certification or any other local legal requirements.

What sort of range or the clients that you are seeing this error message for ??

Do you see a lot of CRC errors ? Do you see a lot of discards or holdoffs ?

[jreimer]

The amp is not it. I took it off and it did the same thing. I replaced it with another AP350 I had and everything is perfect. Both AP1200's do it constantly all day.

I'm not sure what my next step should be.

[ajbersbach]

I have this problem, too, and I've just entered some details as a reply to the originall poster of this thread. Let me reply to your questions as they relate to my case:

In my case, there is no amplifier on any of our AP's.

In my case most (at least) of the clients are not moving when the problem occurs.

Consider the AP I'm most familar with, one of two in the Computer Center where I have my office and where I almost always use a wireless connection from my Dell laptop with Lucent card (nearly all our clients use these cards are Dell Truemobile, which is the same, I think). My laptop is less than 20 feet from the AP. The signal has to travel through two or three sheetrock walls with steel studs. The signal-to-noise ratio shown by the Orinoco site monitor is about 50dB.

The site monitor shows two other AP's, one on the floor below with SNR about 14dB. One in a nearby building with SNR about 6dB.

There are usually three or four other clients (besides me) associated with this AP. They all drop at the same time when this problem occurs. Other AP's, even the other one in the same building, do not drop clients at the time this closest AP does. But they do drop clients at times of their own choosing.

I do not see any CRC errors in the AP logs

I should mention that I see a few clients that repeatedly associate and disassociate, sometimes hundreds of times an hour. An analysis of the AP logs (I'm sending all AP logs to a single syslog machine) shows that the worst offenders tend to be non-Orinoco clients. The top 15 included only two orinoco clients, even though about 70% of our clients are Orinoco. But I have no sign that this repeated association has cause problems for users.

Again, any help will be very much appreciated, and I will be happy to supply any informtion you think would be helpful.

[ajbersbach]

I have precisely the same problem.

We have almost 100 Aironet 350 access points, (nearly?) all updated to firmware 12.02T. All or nearly all of them drop all clients several times a day. The clients are disassociated within a second of one another with the same message you found. Within a very few seconds the "Disassociating.." message is followed (for each client) by "roamed", "authenticated", and "associated."

All AP's are on the same subnet, and there are lots of areas where many AP's are accessible. That seemed necessary to be sure to cover nearly all important areas--namely areas with lots of small dorm rooms that have concrete block walls.

This doesn't depend on the client--or at least we have plenty of Win98, WinXP, and Mac clients and it happens to all (or a wide variety) of them.

Since the disconnection is momentary, it doesn't affect most web browsing, but it completely disrupts AOL Instant Messenger, putty, and probably other things.

I thought it might be the AP's trying to rearrange connections between clients for load balancing, so I tried turning off "aironet extensions" which include load balancing. It didn't help.

Any help will be much appreciated.

[coxendine]

We were having the same problem on our WLAN. The following Field Notice resolved our problems:

http://www.cisco.com/en/US/customer/products/hw/wireless/ps441/products_field_notice09186a0080125b92.shtml

To disable fallback mode from the browser (also known as "Loss of Backbone Connectivity Action"), browse into the access point and choose change from Switch to Repeater Mode to No Action.

Enjoy....

-Cal

[psmith]

I also had this problem with several AP's generating the "Sender is leaving BSS" message and the clients being bumped for a few seconds. After looking into it a bit I found that although they were each set to search for a less-congested radio channel, all of the AP's with these symptoms were using channel 6.

As a quick test-fix I hard-coded the default radio channels to 1, 6 and 11 (in a pattern that would keep devices on the same channel at a distance) and set the AP's to not search for less congestion. My problem appears to have resolved.

Although I can't tell what other outside devices might have been causing the interference that originally made all the AP's think channel 6 was the least congested, hard-coding the channel assignments does seem to have eliminated my issue with the AP's bumping clients.

HTH,

Paul

[ajbersbach]

Thanks very much to Cal and Paul for their suggestions.

I've reset all my 80 AP's to "no action" on loss of Ethernet, but I still get the "leaving BSS" connectivity dropouts that temporarily disconnect all clients on the AP and that terminate AIM, putty, telnet and other sessions.

I've always had my AP's radio channels set to 1, 6, or 11, arranged as best I can arrange it, so AP's on the same channel are less likely to have overlapping areas where clients can connect. Still, with up to 10 AP's in a building (to cover dorm rooms with concrete block walls) there are a lot of areas where overlap exists.

I'd very much appreciate further suggestions.