There was a previous issue where MacOS X clients would be completely disconnected, but there have been no reports of the issue you are describing. Work was done with Apple and Broadcom (the main wireless chipset manufacturer for Apple) to resolve this issue so you will want to make sure you are running the latest version of firmware based on the controller platform you are running.
- vWLAN version 184.108.40.206 - BSAP firmware release 6.6.0-28
- vWLAN version 220.127.116.11 - BSAP firmware release 6.5.4-11
- BSC version 6.5.1.03 - BSAP firmware release 6.5.4-10
In the case of your issue, do you know what MacOS is using to facilitate this application?
If you could provide some information such as protocols (TCP/IP Multicast/etc) and port numbers, then it would help to better diagnose what the problem might be.
We are running 18.104.22.168 with the latest firmware. The client is using Lion. From what I know, Lync communication uses port 443, I am still trying to find some more info on it. We are also scheduling additional time with the user to duplicate the issue. I remember the MacOS X sporadic drop off issue, which we could only resolve by tinkering with the Network driver/firmware. What was the resolution to the apple issue?
David Alicea, MBA
Network Engineer, National Team
The resolution to the Apple issue involved 40MHz bonded channels and will need to be fixed in firmware. Essentially the wireless client would would think the AP was on a different primary channel. As a work around you can disable 40MHz channels. There are a couple items in the latest releases notes for AP firmware on both vWLAN 22.214.171.124 and 126.96.36.199.
- For the highest 802.11n performance, follow these steps:
- Use WPA2 (PSK or 802.1x) with AES when connecting 802.11n-based clients. A TKIP client will connect at a maximum transmit rate of 54 Mbps.
- Enable 802.11n Wireless Mode, 40 MHz Channel Bandwidth (for 802.11a radio), and Packet Aggregation mode. (Packet Aggregation should be enabled for only the BSAP 19xy series, so in a mixed hardware environment, use AP templates specific to the hardware of the AP.) These are configured under the 802.11 radios in the GUI in the AP template.
- Enable 802.11n on the wireless client devices (in the hardware/firmware options).
- For example, with the Linksys 802.11n card, use the Windows configuration interface (under Properties>Driver) and enable IBSS mode for 80211a/b/g/n/auto.
- It is highly recommended that all 802.11n client drivers are updated to the latest version before doing any system or performance testing.
- Running in a mixed mode environment (i.e. with legacy clients) will impact the 802.11n client’s performance.
I bring this up because it is important to note that disabling packet aggregation and 40MHz bonded channels will lower wireless-N performance for all users so it is a rather large trade off.
Good info. So at a location running 1840s, vWLAN 188.8.131.52 and have some Macs who need to connect to 802.1x, it would be best to make sure 802.11a/n channel bandwidth / Packet Aggregation is set to 40 Mhz and Disable, until a future firmware is released?
1 of 1 people found this helpful
Actually, you would need to disable the 40MHz channel as well. Effectively you are disabling wireless-N. We have fixed this issue in AP firmware 6.6.0-30, however this release is limited to vWLAN 2.2. I have included an excerpt from the release notes in order to provide more information, but currently the issue is still present in vWLAN 2.1
Version 6.6.0-30 BSAP Fixes
- After 16 or more clients have been associated on a radio, extended 802.11n fields for the secondary channel were reported improperly in the beacon in the 1800v1, 1800v2, and 1840 models . This would cause newer Broadcom clients, such as the Apple Macbook, etc to disassociate from the AP and not be able to reconnect.
This 16 client limit is the total client count since a reboot. This does not mean 16 active, concurrent users, but rather 16 unique associations since the last reboot. A unique association could be the same user coming back online after it was disconnected. In other words, you will likely reach this 16 client limit pretty fast. You will need to disable both 40MHz channel bonding and packet aggregation for the time being until the fix has been pushed into AP firmware compatible with vWLAN 2.1.
Message was edited by: site.down.charlie There was some confusion on the wording in the release notes. I originally thought this meant 16 concurrent connections, however that is not the case.
One quick clarification question. I know that the fix for the "Broadcom issue" is in the 6.6.0-30 firmware for the 1840/1800v2 APs connected to a 184.108.40.206 vWLAN. But what is the proper configuration for a mixed 1800 / 1800v2 environment (since the latest firmware for the 1800 is 6.6.0-28)?
I'm running vWLAN 2.1 right now and have the 40 MHz and Packet Aggregation off and my MacBooks are behaving ok (if a little slow). But, I'm upgrading to the 2.2.1 vWLAN in the next few days and upgrading the firmware on the APs to 6.6.0-28 on the 1800 and 6.6.0-30 on the 1800v2. Can I turn on the channel bonding for the 1800v2's, or do I need to leave it off until the 1800 firmware is updated also?
That is an excellent question, unfortunately it is a hard one for me to answer simply because I do not have the equipment to test with. My initial thoughts are you may run into issues with wireless roaming. However, thinking from a logical standpoint, if a device disassociates from one AP and moves to another (both APs support the location therefore it is layer 2 mobility - aka. wireless roaming), then the client should be forced to conform to the wireless modes supported on the new AP.
From a client perspective though, they would go from wireless-N speeds to something much less, and Chnt In light of this, I would recommend a homogeneous configuration across the APs. In reality though, must environments are mixed, and further an AP must support the slowest client thereby throttling all users. In other words, you probably won't run into connectivity issues if the 1800s do not support channel bonding and packet aggregation, but you may have clients reporting slow speeds. From an administrative stand point you will want to be aware of this so you can provide an answer for your clients.
My apologies if this answer seems contradictory and/or confusing. Feel free to ask for clarification.
Message was edited by: site.down.charlie:
Changed "the clients typically are not aware of roaming" to "the end users typically are not aware of roaming." It seemed necessary to make the distinction in this case.
That was actually not a confusing or contradictory answer! You point out
what I was concerned with -- the behavior of a client as it roams from an
1800v2 AP with channel bonding to an 1800v1 AP without channel bonding. It
sounds like what the user might experience would be akin to roaming from an
"n" AP to a "g" (or "a") access point.
We've been running on the old vWLAN (2.1) and channel bonding off
everywhere, so I will just continue with that homogenous environment for
now and when the latest firmware comes out for the 1800v1 that solves the
channel bonding issue, I'll upgrade the settings across the board.
Director of Information Services
St. John's Preparatory School
On Thu, Apr 11, 2013 at 12:39 PM, site.down.charlie <
I went ahead and flagged this post as “Assumed Answered.” If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons. This will make them visible and help other members of the community find solutions more easily as well as award points to the users that helped you. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
- For the highest 802.11n performance, follow these steps:
Does anyone know the fix for that Mac OSX disconnect?