Funny you mentioned the 2915. That's one of the clients I was having issues with. I upgraded the drivers to 9.0.4.39 and also ended up changing the roaming aggressiveness setting to the med/low value. It made a huge difference. The issue was with the client roaming too much. The AP that the client connects to primarily provides good signal strength,Ch11 -71dBm, and the other two APs that I pick up in the same location measure Ch1 -85dBm and Ch6 -80dBm. The particular user that was having this issues was not mobile at all, so it made sense to change the roaming settings to a lower value.
Hector From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent: Sunday, October 19, 2008 12:20 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Client behavior on secured wlans... Hector, This is the dark matter of wireless. Not everyone appreciates the fact that the client is an integral part of the wireless network. I have also gotten to tweaking the Intel 2915 driver settings and was wondering what your experience of this was. I've been looking at packet captures of an XP bootup and seeing some interesting behavior in terms of the client "successfully connecting and staying connected." I was surprised to see the sheer number of times the client probes/receives probe responses/waits/probes again/receives responses, before it finally gets to the authentication and association states (in this case for PEAP). And once connected, the number of times it repeats this process, in areas of dense deployment coverage. I'm starting to wonder if there's deeper issues there. I know there were such suggestions made regarding interoperability on the Cisco NetPro forum with WLC 4.0 code. I've had the defaults in place up to now, but am inclined to make roaming more aggressive, reduce the transmit power to match the APs, and have the NICs in constantly awake mode (CAM). Intel sent me a doc about a year ago with general indications of what their hardware uses to determine roaming behavior (attached). ********************************************************** FYI - looks like the 2915 hardware goes out of support end of next year. http://support.intel.com/support/wireless/wlan/pro2915abg/sb/CS-028973.h tm <http://support.intel.com/support/wireless/wlan/pro2915abg/sb/CS-028973. htm> ********************************************************** Here's something else I got from HP a while back, For default aggressiveness, we will attempt to search for a new AP if we meet one of the following criteria: - RSSI is less then -70dBm - Tx rate falls below 18mbps (associated to .11a AP), 2mbps (.11b AP),11mbps (11.g AP). - 8 or more continuous missed beacons - 50% of packets received have CRC errors. --Bruce Johnson ________________________________ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Hector J Rios Sent: Saturday, October 18, 2008 10:28 AM To: [email protected] Subject: [WIRELESS-LAN] Client behavior on secured wlans... Here is a question that I hope can create good discussion. The success of a secure wireless implementation, specifically an implementation that uses some type of EAP method, depends in part on the ability of the wireless client to support it "effectively and efficiently". I mention these last two words because we all know that there are a variety of Operating Systems, supplicants and wireless adapters that support "secured wlans". But in environments like ours, the education community, and with the vast array of systems and devices that are part of our networks, support of a secured wlan can be very challenging. For a wireless client to successfully connect (and stay connected) to a secured wlan, drivers must be up-to-date and in some instances settings on the adapters themselves must be tweaked. Roaming aggressiveness, power management, mixed mode, CCX, etc. All these settings in a way affect the performance of the wireless clients and in some situations defaults work fine, but in others modifications must be made. I mention this because in our campus we have the usual complaints from users that view wireless as very unreliable and complicated, when in fact the problems usually originate on the client side, either because the drivers need to be updated or the wireless adapter is "sticky" or not "sticky" enough, etc. What I'm getting at is this, I'd like to know if you guys are experiencing the same challenges and if so I'd like to know how you approach them. Do you rely solely on information you provide to your users via a website or some other type or do you take more of a proactive approach by implementing some type of NAC solution. We have good documentation on our website with quite a good number of tips on how to solve common problems, but I feel most users don't like to bother with that. We use Autoconnect to make the configuration easier, but this doesn't take care of drivers or other settings in the adapters. Thanks, Hector Rios Louisiana State University ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
