New 802.11ac book from Matthew Gast
FYI. Matthew Gast has just published a 152 page book on 802.11ac, called 802.11ac: A Survival Guide. Published by O'Reilly: http://shop.oreilly.com/product/0636920027768.do I purchased the ebook version (DRM free!) and found it to be quite informative. Recommended. -Charles Charles E. Spurgeon University of Texas at Austin / ITS Networking c.spurg...@its.utexas.edu / 512.475.9265 Here's an interesting bit on 802.11ac adoption in smartphones: Although 802.11ac is often dismissed as too power-hungry for mobile devices, singlestream 802.11 MIMO devices do not require significantly more power than their SISO predecessors. The main consumer of power in a MIMO device is the power-hungry digital signal processor that performs spatial mapping. By using only a single spatial stream, a portable device can reap significant benefits from 802.11ac's increased speed and wider channels without paying a significant power-consumption penalty. Although there will be an increase in power requirements to use wider channels, the trade-off is that transmissions go so much faster that the analog section is on for much less time. With a net battery life benefit, 802.11ac will be adopted widely in portable devices. In fact, 2013 saw the first introduction of an 802.11ac-capable smartphone. p 92, Chapter 5, 802.11ac Planning ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Signal variability after upgrade to 7.0.116
On Fri, Sep 02, 2011 at 02:53:18PM +, Lay, Daniel wrote: We have experienced a similar issue. I had 1131's in several buildings and coverage was decent. At the time that was acceptable because wireless was treated as an convenience. Now perceptions have changed to wireless is mandatory; so in light of that we upgraded several buildings to the 3500s and even increased the number of AP,s in some buildings. As kids have returned we have seen a very large number of complaints coming from areas we thought we had the jump on. These are also areas that were not perfect with the 1131's (or we would not have upgraded) but they were not as high a volume of complaints as before. I opened a TAC with Cisco and we discovered that the AP's were at only a 7 power setting with RRM and when we moved to manual on the periphery AP's the coverage really improved. It makes me wonder if RRM is experiencing issues though because there was one AP in new construction area that could see other APs far away and I expected the power to be a 1 or 2 but it was at 7. The power management system will only adjust power on APs that can be heard by three other APs (neighbors). Increasing the density of APs could increase the number of APs heard by three neighbors, and therefore the number of APs that will have their power levels adjusted. APs without three neighbors run at power level 1. As soon as there are three neighbors then TPC is likely to adjust the AP radio to much lower power levels. The TPC defaults appear to be designed to optimally support open cube spaces with few walls and not spaces with lots of walls like residential buildings, traditional faculty office buildings, etc: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml#bev http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml#tpca Cisco has an unsupported WLC config checker tool that also shows the AP neighbor counts. I've found the tool to be useful for config sanity checking and for looking at some of the system-wide RF issues: https://supportforums.cisco.com/docs/DOC-1373 -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Cisco Wireless Controller Software Advisory
Our test of 6.0.199.0 on a single WiSM WLC with 15 production APs resulted in about 150-175K OSAPI-4-MUTEX_LOCK_FAILED error messages logged every 24 hours. The WLC otherwise was operating normally and there did not appear to be any client impact, but there are only a couple of dozen clients on this WLC at busy hours. We opened a TAC case and were informed that this is bugID CSCth92458, with no workaround. We are now testing 7.0.98.0 and haven't seen that error msg. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 On Tue, Aug 03, 2010 at 07:40:33AM -0400, Mike King wrote: For all those playing at home, http://www.cisco.com/web/software/Wireless/Deferral/Software_Advisory_6_0_196_0-4.html was updated last night. I'm guessing 6.0.199.0 came out, because it says to move to it immediatly to resolve these bugs. For myself, we moved to the 7.0.98.0 code, and we haven't had any issues. In fact, besides resolving those two catastrophic bugs, it's solved another minor bug that's been plaguing me with the Cisco 7925g Phones. Mike On Mon, Jun 21, 2010 at 6:31 PM, Mike King m...@mpking.com wrote: - Original Message - From: Mike King m...@mpking.com To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Sunday, June 20, 2010 8:29 PM Subject: [WIRELESS-LAN] Cisco Wireless Controller Software Advisory Got this in my email last night. ?I think I've been personally hitting CSCtf34858, and not realizing it. (Well, realizing it but not being able to catch/diagnose it, I've known something was wrong since I went to 6.0.196.0) ?Looks like I'll be upgrading to 7.0.98.0 within the next few days. https://supportforums.cisco.com/docs/DOC-11722 This Software Advisory Notice is issued against all the above Wireless LAN Controller software versions due to the following bugs: ?(as a side note, the are marked Severity 1 - catastrophic ) CSCtf34858 Client can't transmit traffic if it reassociates to an AP within 20 sec CSCte89891 Radio may stop transmitting beacons periodically Base Code: 6.0.182.0, 6.0.188.0, 6.0.196.0 Special Build: Following options are available: ?1. ? ? Move to ?7.0.98.0 Release posted on CCO. Please note, 7.0 is a new feature release. ?2. ? ? Contact TAC to get a 6.0 Special or Beta release with fixes for the bugs below. ?3. ? ? Wait for the CCO release of 6.0 MR3 (Maintenance Release), which is planned ?for July/August 2010 ** 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/. ** 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/.
Re: [WIRELESS-LAN] Client DHCP issues after WLC upgrade
Although the AssureWave doc lists the CSCtd84852 bugID as a caveat in 6.0.196.0 code, that bugID it is superseded by CSCte08161. The new bugID says the issue is fixed in AP code 12.4(21a)JHA. We just upgraded our system to 6.0.196.0 and the APs are now running 12.4(21a)JHA code. The latest v6.0 release notes also state that bugID CSCte08161 is resolved in v6.0.196.0. We've asked our Cisco support channel to confirm, but going by the evidence of the new bugID and the release notes, it looks like this issue is resolved in the latest 6.0 MR2 code. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 On Thu, Mar 18, 2010 at 01:17:11PM -0500, Schomer, Michael J. wrote: I know 6.0.196 is AssurWave, but it also lists the issue we might be having as a caveat. We did test 6.0.188 on one of our WLCs for a few months and decided to go with the known quantity. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Lee H Badman Sent: Thursday, March 18, 2010 12:15 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Client DHCP issues after WLC upgrade If I'm not mistaken- and I'm not trying to be snarky- 5.2.178 was also AssureWave. Am pretty sure of that. __ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Mike King Sent: Thursday, March 18, 2010 1:00 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Client DHCP issues after WLC upgrade Hey Mike, I didn't know 6.0.196 was released. I just checked it out, and 6.0.196 is AssureWave. This is one of the point releases that Cisco releases that has had extensive testing with multiple devices / vendors / software products. It's similar to the old Safe Harbor release. Here's the doc to it: [1]http://www.cisco.com/en/US/netsol/ns779/networking_solutions_progra m_category_home.html The test results actually show the test methodolgy, and it's pretty extensive. [2]http://www.cisco.com/en/US/solutions/collateral/n s340/ns414/ns779/AssureWave-WLC-Release-6.0.196.0-Results.pdf It also gives a list of Bugs (at the end) that the testers felt should be considered before upgrading On Thu, Mar 18, 2010 at 11:40 AM, Schomer, Michael J. [3]mjscho...@stcloudstate.edu wrote: Hello, We are noticing a problem on our WPA/802.1x SSID with some of our clients after a recent Cisco WLC upgrade from 5.2.178 to 6.0.188. The clients are able to connect and authenticate to the SSID; however, they aren't receiving an IP address. We have ruled out the DHCP server as the problem. This doesn't affect all clients, and the problem seems to come and go. We haven't seen a common OS or chipset among the clients that are having problems. We currently are running four WLCs in production, and all of them received the upgrade at the same time. The only thing that most of these clients have in common is that they are associated to APs on two particular controllers. The only thing unique about those two controllers is that they have mostly 1131 APs. When the clients roam to a different WLC, they can usually connect just fine. I'm at a loss right now. We did test the 6.0.188 code in one building (with 1250 APs) for several months before deploying it, without any notable issues. We are now potentially looking at downgrading back to 5.2 code, but aren't thrilled about it. Another option would be to upgrade to 6.0.196, but we haven't done any testing of that code revision. Has anyone seen a similar issue? Does anyone know of any issues with 6.0.188 code and 1131 APs? Any thoughts or advice would be appreciated. Thanks for your help. -Mike Schomer -St. Cloud State University ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at [4]http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at [5]http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at [6]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/. References 1. http://www.cisco.com/en/US/netsol/ns779/networking_solutions_program_category_home.html 2.
Re: [WIRELESS-LAN] WiSM 5.2.193
On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: Has anybody upgraded to 5.2.193? Can you provide any feedback? We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no operational issues seen and no problems reported for clients so far. We have approx 3,500 APs, and the client count is at its lowest level due to summer session with around 3,000 peak simultaneous clients. We are installing a number of 1142s, so we needed the new code to support them. We *did* encounter a weird AP join issue on some of the WLCs in one of our mobility groups when there were mixed versions of WLC code while upgrading WLCs in the same mobility group (some controllers on 4.2 and others on 5.2). The issue was a delayed join to the primary WLC for APs during the process of upgrading the controller and then waiting for APs to re-join the upgraded (primary) controller (we configure the primary/secondary/tertiary WLCs on the APs). We escalated the issue and Cisco has developed a fix that will presumably ship in newer code. Meanwhile, we noticed that if we upgraded the first controller in the mobililty group (the one with the lowest MAC address as seen in show mobility summary) to the new controller code first then that seemed to avoid the issue of having large numbers of delayed AP joins. Given that, we resumed our upgrades and have almost completed the entire set of WLCs. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
FYI: Wireless performance report from England finds 802.11 protocol overhead and other issues
FYI - A recent Slashdot posting mentioned an analysis of WiFi performance in England that was commissioned by Ofcom (communications regulatory office in England). A Register article on the Ofcom report notes that baby monitors and other devices were causing signal degradation issues and that wireless beacons were also consuming significant amounts of WiFi channel bandwidth: http://www.theregister.co.uk/2009/05/10/ofcom_mass_wi_fi/ The Register article has a link to the full report, which includes a number of items of interest to wireless system managers and engineers: http://www.ofcom.org.uk/research/technology/research/exempt/wifi/wfiutilisation.pdf Page 71 of the full report documents a finding that laptops that were advertising an ad hoc SSID for Free Public WiFi were sending beacons at 100 per second instead of the usual 10/sec rate! -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] WiSM Code- Revisited
We're not using 4.2.176, but we've had 30 WLCs on 4.2.130 code since July 08 with a current load of 3,000 APs and a client peak load of over 9,000 concurrent users. WLC operations have been stable, but we don't run any Web services on the WLCs and our WLC configs are non-standard WRT RF Groups due to RRM issues that pre-date the 4.2 code. Based on the bugs I've seen documented in the Cisco bug tool for v5.2 CAPWAP code, I wouldn't deploy it in a production system. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 On Tue, Jan 20, 2009 at 12:46:16PM -0500, Lee H Badman wrote: After a weekend full of problems on 4.2.112... We are being instructed to move from 4.2.112 to 4.2.176, and to avoid 5 code. Could use some input from anyone running 4.2.176. How big is your environment, and are you either experiencing or aware of any major bugs? For us on 4.2.112, we are having random spates of controllers losing both management and service IP addresses. Thanks much- Lee Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 ** 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/.
Re: [WIRELESS-LAN] FYI: Cisco controllers may put radios on UNII-2e channels
Don, I did some testing of four client interfaces in the spring when we had identified this issue (I've been meaning to post about this for a while, but spare time has been hard to come by), and collected the test results in a spreadsheet. The two bga interfaces were not able to associate with UNII-2e channels. Of the two bgan interfaces, one worked with UNII-2e channels and the other did not. To make the test info available I have created a Google spreadsheet which can be found at: http://spreadsheets.google.com/pub?key=pvI5m65uYyGaZlGrZV7fxFA One of my goals is to make it possible for others to add their test data to the Google spreadsheet, so that everyone can benefit from the info collected on the channel support levels for 5 GHz clients It looks like Google has an automatic form creator to help automate the process of collecting data in a spreadsheet, so I will try sending that form to the wireless-lan list and see what happens. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Wed, Sep 10, 2008 at 09:05:43PM -0400, Don Wright wrote: Charles, I'd be interested to know which client/drivers you've already tested this with. Maybe others have some as well to add to a list of either working or not. Thanks, -- Don Wright Brown University CIS - NTG On 9/10/08 10:41 AM, Charles Spurgeon [EMAIL PROTECTED] wrote: FYI. This documents something that we have stumbled over with UNII-2e channels and is a heads up for anyone running Cisco LWAPP gear and using the auto channel selection component of RRM (Dynamic Channel Assignment (DCA) in Cisco-speak). The Cisco WLC release notes for v4.1.185.0 have an important caveat (CSCsi86794) that describes the behavior of DCA and the UNII-2 Extended channels (UNII-2e).(1) For some reason this caveat is missing in 4.2.130.0 release notes, while the DCA issue still appears to be present in that code. (Based on the text in the 4.1.185.0 release notes the UNII-2e support appears to have first shown up in 4.1.171.0.) Briefly, Cisco has added support for the UNII-2e channels to the wireless lan controller and LWAPP APs, and these channels are automatically enabled for use by DCA. As a result of the new support, AP radios may be automatically assigned by DCA to one of the UNII-2e channels. We found several radios in our system where that had happened. Unfortunately, none of the 802.11a clients that we have tested know about the UNII-2e channels, and therefore most (all?) 802.11a clients cannot associate with AP radios that have been assigned to the UNII-2e channels. An AP radio on one of those channels is no longer available to dot11a clients and your wireless coverage will have holes in it even though the AP is up and system monitors are happy. If the client NIC has an 802.11an radio then it may have support for the UNII-2e channels. You would need to test against an AP radio set to one of the UNII-2e channels to find out, since the vendor docs that we have looked at don't tend to have any documentation about the presence or absence of UNII-2e support. To avoid this issue, Cisco's release notes tell you to disable the UNII-2e channels in DCA. However, the release notes incorrectly tell you to also disable channel 149, which is NOT one of the UNII-2e channels. Instead, it is one of the older channels that is supported by all 802.11a NICs that we've tested. If you want to avoid issues with AP radios being set to UNII-2e channels that are invisible to clients then you can do that by disabling all DCA channels in the UNII-2e range of 100-140. Note that when you disable these channels using either the CLI or the Web GUI the AP radios must be disabled and then re-enabled to make that change. We would be interested in hearing about the experience at other sites with UNII-2e channels, especially the results of any tests of UNII-2e support in clients. Thanks, -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 (1) The UNII-2e channels appear to be relatively recent additions. This Cisco doc mentions them in the context of DFS support requirements: http://tinyurl.com/yq7y9r ** 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/.
WiFi Client Interface 5 GHz Channel Test Spreadsheet
If you have trouble viewing or submitting this form, you can fill it out online: http://spreadsheets.google.com/viewform?key=pvI5m65uYyGaZlGrZV7fxFA WiFi Client Interface 5 GHz Channel Test Spreadsheet This form is provided to help automate the process of collecting test information on channel support in 5GHz 802.11a and 802.11an client interfaces. The channel support spreadsheet can be seen at: http://spreadsheets.google.com/pub?key=pvI5m65uYyGaZlGrZV7fxFA The testbed that I have used to test channel support on client interfaces is based on creating an SSID (example: 5ghztest) and assigning it to the 5GHz radio on an AP in my office. That way the client interface can be made to associate with the correct AP as the channels are changed on the AP to test interface channel support. Next, at least one channel in each UNII channel group is tested by setting the AP to that channel and checking to see of the client can associate with the test AP. Finally, an iperf test is run from the client machine to an iperf server to make sure that the client interface can exchange traffic over the channel being tested and that performance on that channel is acceptable. Testing at least one channel from each UNII channel group results in four AP reconfigurations and four tests per client interface. Name: (insert name and email address) Test Report Date: (insert date) Interface under test: model name and number, interface type (cardbus, USB, integrated) Operating System and Version? Example: Windows XP SP2 Interface Driver Version and Regulatory Domain Example: Driver Version n US Domain Access point used to test against: AP model and software version UNII-1 Channels -Yes: Works on one or more UNII-1 Channels. No: Fails on one or more channels. (36,40,44,48) UNII-2 Channels -Yes: Works on one or more UNII-2 Channels. No: Fails on one or more channels. ( 52,56,60,64) UNIII-2e Channels - Yes: Works on one or more UNII-2e DFS Channels. No: Fails on one or more channels. (100,104,108,112,116,120,124,128,132,136,140) UNII-3 Channels -Yes: Works on one or more UNII-3 Channels. No: Fails on one or more channels. (149,153,157,161,165) Powered by Google Docs Terms of Service - Additional Terms ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
FYI: Cisco controllers may put radios on UNII-2e channels
FYI. This documents something that we have stumbled over with UNII-2e channels and is a heads up for anyone running Cisco LWAPP gear and using the auto channel selection component of RRM (Dynamic Channel Assignment (DCA) in Cisco-speak). The Cisco WLC release notes for v4.1.185.0 have an important caveat (CSCsi86794) that describes the behavior of DCA and the UNII-2 Extended channels (UNII-2e).(1) For some reason this caveat is missing in 4.2.130.0 release notes, while the DCA issue still appears to be present in that code. (Based on the text in the 4.1.185.0 release notes the UNII-2e support appears to have first shown up in 4.1.171.0.) Briefly, Cisco has added support for the UNII-2e channels to the wireless lan controller and LWAPP APs, and these channels are automatically enabled for use by DCA. As a result of the new support, AP radios may be automatically assigned by DCA to one of the UNII-2e channels. We found several radios in our system where that had happened. Unfortunately, none of the 802.11a clients that we have tested know about the UNII-2e channels, and therefore most (all?) 802.11a clients cannot associate with AP radios that have been assigned to the UNII-2e channels. An AP radio on one of those channels is no longer available to dot11a clients and your wireless coverage will have holes in it even though the AP is up and system monitors are happy. If the client NIC has an 802.11an radio then it may have support for the UNII-2e channels. You would need to test against an AP radio set to one of the UNII-2e channels to find out, since the vendor docs that we have looked at don't tend to have any documentation about the presence or absence of UNII-2e support. To avoid this issue, Cisco's release notes tell you to disable the UNII-2e channels in DCA. However, the release notes incorrectly tell you to also disable channel 149, which is NOT one of the UNII-2e channels. Instead, it is one of the older channels that is supported by all 802.11a NICs that we've tested. If you want to avoid issues with AP radios being set to UNII-2e channels that are invisible to clients then you can do that by disabling all DCA channels in the UNII-2e range of 100-140. Note that when you disable these channels using either the CLI or the Web GUI the AP radios must be disabled and then re-enabled to make that change. We would be interested in hearing about the experience at other sites with UNII-2e channels, especially the results of any tests of UNII-2e support in clients. Thanks, -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 (1) The UNII-2e channels appear to be relatively recent additions. This Cisco doc mentions them in the context of DFS support requirements: http://tinyurl.com/yq7y9r ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Disabling 1, 2 Mbps- revisit
We tried this out on a couple of LWAPP controllers with several busy buildings in April and it appeared to significantly improve the channel performance. Our rough measurements of AP co-channel interference showed a reduction in CCI (less channel time being occupied by beacons), and iperf throughput tests also showed improvement. One iperf test we use is to run a 60 second TCP test with 1 second reporting intervals to see how stable the throughput is, and we saw a significant improvement in speed and stability at the heavily loaded test sites. The channel performance improvement was so impressive that after a couple of weeks of testing we decided to disable 1 and 2 Mbps across 20 LWAPP controllers (4.1.185.0 code) supporting 2,300 APs towards the end of April. We made it through the busiest time of the semester with no significant issues and iperf tests showed improved performance at heavily loaded sites. We have not made this change at the two sites where we know there are wireless handhelds in use (used for things like ticket purchases and concessions). We need to do more testing at those sites, since we wouldn't want to change their operations without verifying that their handhelds would work OK first. We don't have any formal VoWLAN system in use, so we don't have any data on those devices. The other mobile devices that we have tested (iPaq, iPhone) haven't had any problems. The rest of the campus sees approx 50,000 unique users of the wireless system in a semester. In that swamp we have found one issue so far. We have identified what looks like a driver problem with a version of MacOS (older PowerBooks running OSX 10.4 Tiger that cannot upgrade) in which the laptop will not associate with the WPA2 SSID but it *will* associate with the open SSID (guest access through a Web portal for authentication). Weird. Since they still work on the open SSID it isn't a major problem for them. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Thu, May 29, 2008 at 07:56:48AM -0400, Lee H Badman wrote: I recall someone floating this not too long ago, but can't recall the responses. Being an LWAPP environment (currently) and growing fast in AP numbers and overall density, I'm considering disabling 1 and 2 Mbps data rates globally. I did this in an under the radar test for a couple of months on some of our busiest APs with no ill effects noted and what I see as fewer weak clients trying to get on board busy cells. Has anyone else taken this step? Curious in general, and in LWAPP., and if there have been any ill effects noted. One concern/peeve I have is that in LWAPP its controller wide- if there is some compelling reason to change the data rate on just a few APs in one area, you have no choice but to do the same for all APs on the controller. Thanks- Lee Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 ** 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/.
Re: [WIRELESS-LAN] Latest Stable WiSM Code?
The 4.2.112.0 version may well fix the bug that you are working with TAC, but be advised that 4.2.112.0 is crashing for us every few days on a production controller. It has never crashed in the lab, but started crashing once it had been installed in our first real world test of it. This WiSM controller has an identical config to our other production controllers, and there are all of 11 APs on it which serve the building that houses our offices. So it's not like it's under severe stress or anything. Crashinfo and other information was sent to Cisco, and their response was that our bug had been identified and that a new maintenance release of 4.2 code would be released real soon to address this issue and at least one other (apparently related) crashing issue that was only seen at one other customer site (yeah, right). We are still running 4.1.185.0 on the rest of our controllers. That's also the only version that has passed AssureWave testing. We plan to test 4.2 again as soon as Cisco ships the new maintenance release, since we want to move to 4.2 during the summer for all the usual reasons. -Charles On Thu, May 01, 2008 at 08:46:54AM -0500, John Watters wrote: Please reply on list. We are also facing the same problem and would like to see suggestions. -jcw To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU From: Lee H Badman [EMAIL PROTECTED] Date: Thu, 1 May 2008 09:36:27 -0400 Subject: [WIRELESS-LAN] Latest Stable WiSM Code? Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU This is aimed at the WiSM crowd on the list: We are currently running 4.2.61.0 on our WiSMs, and are newly enjoying the afterglow of random controller reboots from a bug. TAC guidance is that 4.2.112.0 fixes our bug. But given the intrusiveness of upgrading almost 2000 APs and 24 controllers, I'd rather look at whatever the latest truly stable code is for a summer upgrade, then not touch again for six months. Is anyone hearing any info of real value on what code versions should be avoided? Off list is fine, if you'd like. -Lee Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. - John WattersUA: OIT 205-348-3992 ** 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/.
Re: [WIRELESS-LAN] Open Wireless in Higher Ed
Peter, I very much appreciated your contribution, and found the paper to be a useful overview of the territory. While your affiliation with Aruba was clear, I thought you did a good job of describing the basics of the architectures without leaving an impression of excessive bias. Obviously there are differences of opinion about which approach may be better. But I, for one, always appreciate it when someone tries to explain the issues rather than simply assert their own superiority and/or throw marketing mud and FUD. As you note, I am a major proponent of testing wireless systems, and I hope that the results that were reported in the Novarum paper will result in more testing of enterprise wireless systems under real-world loads to investigate the issues that were revealed. No single technology or single approach to wireless networking is going to be perfect. Instead, we need to learn more about how wireless technologies and these different approaches behave in enterprise wireless networks and under real-world loads, so that everyone, network managers and vendors alike, can be successful when it comes to deploying this technology to deliver networking to users. Thanks, -Charles (not Chuck -- don't know where Dave Molta got that :-) Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Fri, Apr 04, 2008 at 12:07:36PM -0700, Peter Thornycroft wrote: I'd like to quickly address some of the comments that were posted in response to my paper on WLAN RF Architectures, which was an attempt to enumerate the technical differences between a single channel WLAN model and adaptive model. The post below has sparked some healthy debate on the topic. The paper was created to fill a gap in available material on the subject, especially as it relates to a fair assessment of the two architectures. While some level of bias is inevitable given my affiliation with Aruba, I made every effort to stay neutral on evaluating the two solutions and separate the abundance of marketing claims, driven by the fierce but healthy competitive environment, from the actual technical capabilities of the two architectures. The intent of the paper was to provide a technical comparison of adaptive vs. single-channel architectures and should not be viewed as a substitute for an independent (read: not vendor sponsored) test of the competing solutions. I would echo Chuck and Dave's comments about the need for better information about WLAN scalability and encourage more 802.11n tests that expose these differences between vendors. This is critical evaluation criteria for the Higher Education space. I appreciate everyone's comments on the subject and the feedback from my paper. Peter Thornycroft Aruba Networks [EMAIL PROTECTED] __ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent: Wednesday, March 26, 2008 8:06 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Open Wireless in Higher Ed Brian, I'm curious about your Meru experiences. Aruba recently released a white paper on the downsides of a single-channel architecture. Its a pretty cogent argument, and I haven't seen any response yet from Meru. You can take a look at it here: [1]http://www.arubanetworks.com/pdf/technology/whitepapers/wp_RFARCH.p df __ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Fruits, Brian Sent: Wednesday, March 26, 2008 10:33 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Open Wireless in Higher Ed We use the captive portal with Bluesocket as well but, we authenticate against external AD/LDAP and allow limited guest access. In our case we can't do client policy enforcement (require AV, patches, etc.) like Cisco Clean Access, but we can require that certain user groups use different levels of security such as L2TP or IPSEC which can be handled by the Bluesocket. The Bluesocket also assigns users into roles that allow us to customize traffic limits and firewall restrictions. Our primary access points are Meru Networks AP208s. The APs will handle our WPA when we start heading in that direction. Both Meru and Bluesocket can operate in multi-vlan configurations allowing for good flexibility for different client classes (i.e. voice) in a single box. Brian Fruits ITS - Network Services UNC Charlotte __ From: The EDUCAUSE Wireless Issues Constituent Group
Re: [WIRELESS-LAN] Aruba's SCA vs. MCA whitepaper [was: Open Wireless in Higher Ed]
On Tue, Apr 01, 2008 at 08:25:06AM -0400, Dave Molta wrote: I agree with Chuck about the need for better information about WLAN scalability. It's an issue I've struggled with for many years but I'm not optimistic about a resolution. I've discussed this issue extensively with Phil Belanger, the author of the Novarum report, and I just can't see any way to get all the vendors to agree to a single test plan and commit the resources necessary for such ambitious tests. Although it's clear that Meru designed these tests to best reflect their competitive advantage, I also believe Phil played the role of objective analyst, which is not always the case with pay for test projects. Phil pressured Meru to include test runs that were not part of their original plan and he was very transparent in disclosing his role in these tests. Still, it's highly likely that the results would have been different if Cisco and Aruba had been directly involved. Personally, I still think Meru would have performed better, but I don't think the differences would have been as great. Although the issue of co-channel interference is an important one, I think it may be reasonable to assert that its importance will be reduced with the adoption of 5 GHz 802.11n. With over 20 non-overlapping channels, I believe it will be possible to design high-density, micro-cellular WLANs that do not suffer from performance degradation as a resulting of co-channel interference. Over time, I believe 2.4 GHz will be thought of as a best-effort legacy technology for most enterprises. I'd be curious how others are viewing this. Dave, I agree with you in principle about the need to move to 5 GHz -- but we have an installed base of thousands of APs (and tens of thousands of clients) on our campus that are running 802.11b/g, and I find the vendor refusal to test scale and load issues on 802.11b/g systems to be indefensible. The wireless system on our campus has become critically important to the organization. When do the wireless vendors plan to step up to the task and provide real-world large scale testing and useful guidance on these important issues? As the author of a book on the orginal cabled Ethernet system, I can remember the days when Ethernet was being tested for scale and load. In the early days of Ethernet the scale tests were difficult to arrange, since large groups of high performance computers sharing a network were not as common. These tests resulted in a better understanding of Ethernet behavior and limits, and provided network managers with useful information on how best to configure and deploy Ethernet systems. If the wireless vendors persist in refusing to provide scale testing and persist in refusing to provide the testing results and technical information needed to better understand and operate complex 2.4 GHz wireless systems, then what can we expect when we move to 5 GHz? There is some level of co-channel interference even in non-overlapping 5 GHz channels. Given the levels of performance collapse that were reported in the Novarum paper, and given the insight documented in that paper that the interference range is greater than the communication range of 802.11 products isn't it reasonable to ask that these issues be further investigated? To your point on moving to 5 GHz: we've been working on wireless upgrade plans, including an emphasis on new 5 GHz designs for the usual reasons: increased channel capacity and less interference from non-802.11 sources. Also, we're very interested in seeing what 802.11n can deliver. Like everyone else, we need the new capacity to deal with the massive increases in wireless usage. Some issues that we're encountering include client behavior when it comes to choosing which channel to connect to on an AP that is providing both 802.11b/g and 802.11a/n channels, and client support for the set of 5 GHz channels. While there are 20 (or more) channels defined in the 5 GHz spectrum, the client support for those channels is not what you might expect. I've been digging into the client channel support issue, including some client testing, and will be posting more info as soon as I can get it into shape. Thanks, -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Aruba's SCA vs. MCA whitepaper [was: Open Wireless in Higher Ed]
On Wed, Mar 26, 2008 at 10:31:50PM -0500, Frank Bulk - iNAME wrote: I wish it was easier to evaluate the performance (not only aggregrate throughput, but also QoS) of the MCA and SCA products in various scenarios and density and usage, but unfortunately examining the impact of co-channel interference on a large scale in variety of building types and architectures with lots of APs and clients with realistic traffic patterns (in terms of type and longitudinally over time) is not currently possible with the tools available. I think we would learn that there certain scenarios where one performs generally better over another. I, for one, would like to see more vendors step up and do the kind of testing of co-channel interference issues that was described in the recent Novarum whitepaper: http://www.novarum.com/documents/WLANScaleTesting.pdf As a user of typical multi-channel equipment, I'm not focussed on the SCA versus MCA debate. Instead, I would very much like to see more real-world test results on how the typical multiple APs on multiple channels (MCA) approach works at scale and under traffic loads. I think it's very interesting that the author of the Novarum whitepaper is also one of the developers of the 802.11 MAC, and that he states that he was surprised at how easily we could drive these systems to unstable behavior. I've heard complaints from the vendors whose gear was used in the Novarum test. But I haven't seen any third-party tests commissioned by those vendors to replicate the tests and show where the problems were in the Novarum tests. I would be much more impressed by actual third-party test results based on a significant scale layout like the one used in the Novarum tests, rather than hearing complaints about the how the test was unfair since it was done under the auspices of Meru. The problems of co-channel interference and wireless channel meltdown under load are too important to be left to the marketing departments of the wireless vendors. On our campus the community has been adopting wireless networking at extremely high rates, and this technology has become much too important to allow it to be supported this poorly. Isn't it long past time for more real-world scale testing like the Novarum tests to be done to investigate the issues with CCI and channel meltdown under load in 802.11b/g systems and to develop some approaches for identifying and dealing with those issues? -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Leopard/802.1x question
Sounds familiar. Here's the help doc we've created at UT Austin for Leopard dot1x config: http://www.utexas.edu/its/support/topics/leopard/restricted.php -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Thu, Nov 01, 2007 at 10:53:45AM -0400, Lee H Badman wrote: Pretty sure we have it figured out- after we document it, will share it. The key is to select the user profile, versus machine, in the 8902.1x settings. Pretty Goofy changes they made in this regard. Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: Lee H Badman [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 10:03 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Leopard/802.1x question Yes- user credentials. The machine aspect is not even in the realm of possibility... -Lee Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: Michael Griego [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 10:02 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Leopard/802.1x question Just out of curiosity, which domain are you having your users use? System or User? (I assume you're not having them use login window since their credentials on the laptop would have to match their university credentials). I assume User, but I thought I'd ask. --Mike On Nov 1, 2007, at 8:41 AM, Stelfox, Samuel G @ VTC wrote: We have been seeing the same problem on our network. Unfortunately we haven't found a solution yet either. We would also be very interested in a solution to this problem. - Sam Stelfox From: Lee H Badman [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 9:31 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Leopard/802.1x question With a growing number of Leopard users on our 802.1x wireless network, we're finding that Leopard does not store user name and passwords the same way OS X 10.4 did- hence a lot of questions from users. I am seeing this on my own Mac- and can't find an answer on the web yet, nor can our desktop folks. Anyone know how to make Leopard store user name and password for 802.1x... Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 ** 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/ . ** 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/. ** 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/.
Re: [WIRELESS-LAN] WCS 4.2
Doug, Thanks for the posting. I thought that each WLC on a WiSM can download 10 APs at a time. In 4.1.185.0 code we typically see 9 APs being download at a time when doing a bulk AP upgrade to LWAPP. On our 1230 APs the download seems to take approx 1.5 to 2 minutes. It sounds like you are seeing very different results in 4.2? We haven't deployed v4.2 into any production sites yet. Would you care to share any gotcha's with v4.2 in production that you have seen? Thanks, -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Fri, Nov 02, 2007 at 08:59:54AM -0400, Bentley, Douglas wrote: We had quite a few issues moving forward with 4.2.62. If you have configuration issues after upgrading to 4.2.62 - DON'T - try to load a backup config file from 4.xxx code to the new 4.2.62 WLCs. I made this error and put 5 - WLCs (2.5 WiSMs) back to the install wizard. We had to manually console into the WiSMs and start from new. Also the 4.2.62 has new code for the access points, so each will need to download the new code. Remember this takes about 4 minutes per access point and each WLC can only upgrade 4 at a time, so 8 per WiSM. If you have a large installed wireless network plan on this downtime. Versions Software Version 4.2.61.0 Boot Version 12.3.7.1 Model AIR-AP1131AG-A-K9 IOS Version 12.4(10b)JA Just a couple points from many issues that had to be resolved. If anyone wants more information please feel free to contact me directly. Until I have the source of our issues figured out I do not want it to seem like I am pointing fingers at anyone. -Doug Douglas R. Bentley University Information Technology Systems Engineering Group University of Rochester 727 Elmwood Avenue, Suite 132 Rochester, NY 14620 Office: (585) 275-6550 Fax:(585) 273-1013 Mailto:[EMAIL PROTECTED] www.rochester.edu/its/ -Original Message- From: Joyce, Todd N [mailto:[EMAIL PROTECTED] Sent: Friday, November 02, 2007 8:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WCS 4.2 From what we were told by Cisco - you will no longer have to remove the old and then install the new. All version from 4.2 on will be a single install and will remove the old for you. todd Todd Joyce Network Services Radford University - The Smart Choice [EMAIL PROTECTED] (540) 831- ? Keep your boots and ChapStick and ice hotels. Give me shorts and sandals and a thirty-blocker. Temperance Brennan - Monday Mourning -Original Message- From: Greene, Chip [mailto:[EMAIL PROTECTED] Sent: Friday, November 02, 2007 8:24 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WCS 4.2 I would be interested in any feedback on the upgrades to WCS 4.2 as well. Any gotchas or heads up would be appreciated. Lee - Could you please describe for me the One Touch Process you mention? I am not sure of what you are refering to. Thanks Chip Greene Senior Network Specialist University of Richmond From: Lee H Badman [mailto:[EMAIL PROTECTED] Sent: Thu 11/1/2007 3:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] WCS 4.2 Anyone upgraded yet- and any issues with the new one touch process? -Lee Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 ** 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/. ** 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/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] WiSM/6500 and LWAPP
I agree, the WiSM/WLC docs are unimpressive. This FAQ has some useful bit and pieces: http://cisco.com/en/US/customer/products/ps6366/products_qanda_item09186a008064a991.shtml Note that Cisco has recently re-engineered the radio resource management (RRM) system to make it more stable. You need recent code to get the latest fixes (we're running 4.1.185.0). This doc explains how RRM works in detail: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml If you have the Wireless Control Server then you can run reports on channel and power changes for all APs known to the controllers and that can show you how things are working WRT to RF channel assignments and power levels in RRM. Be aware that even with the new RRM system the channels can repeatedly change due to anything that RRM regards as excessive external interference. After I lost my connection on my Dell laptop at every Friday morning staff meeting I found that it was due to the microwave oven down the hall being used to heat breakfast. (My laptop has a pretty common setup: WinXP with Intel PRO/Wireless 2200BG NIC with current OS and NIC patch levels.) Other staffers at the meeting didn't notice the change from chan 1 to 11. Presumably their NICs and drivers were better at maintaining a connection and following the channel. However, rather than risk other users on campus losing their connections due to the microwave burrito effect we decided to tell RRM to chill out on the channel changes and modified the RRM channel change behavior on all WLCs to occur only once per 24 hours at 3 am. The new code makes this easy to configure, but the commands to do so are in the release notes and haven't made it into the main docs as yet. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Tue, Sep 25, 2007 at 11:56:05AM -0700, Pham, Loc wrote: Guys, I am assume the deployment of few 6500/WiSM and about 800 AP. So far just read up on the Doc ( which is very primitive ! ). Deployment will be mix of LEAP/PEAP environment. Any word of wisdom? gotcha? TIA, Regards, Loc Pham, CCIE # 17030 - Sr. Network Staff, IT Network Architecture Security,UCSF Medical Center Office 415-353-4492 ** 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/.
Re: [WIRELESS-LAN] Cisco LWAPP
Todd, Many thanks for your replies to the issue list from Lee Badman. I wanted to ask for more info on your response to point 10, in which you said that you had to disable cdp in order to get lwapp radios to come up. Am I reading that correctly? We're working on a WiSM deployment beginning later this year and we will be converting Cisco 1230 APs to lwapp. Will we have to disable cdp to get the radios to work? Thanks, -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 On Wed, Sep 20, 2006 at 08:02:42AM -0500, Todd M. Hall wrote: I will take a stab at some of these... I hope some of this will help. A little background on our network. We upgraded about 300 older APs to LWAPP. We upgraded the following AP models: 1121, 1131, 1231 (a couple of variations of this one). We are using WiSM (Wireless Services Module) based 4404 controllers. This provides two controllers on a blade in our 6509 switches and each controller can handle 150 APs. We currently have three of these blades and another one on order. We have about 450 APs online now with hundreds more planned. Answers below... On Tue, 19 Sep 2006, Lee Badman wrote: Date: Tue, 19 Sep 2006 19:53:09 -0400 From: Lee Badman [EMAIL PROTECTED] Reply-To: 802.11 wireless issues listserv WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco LWAPP Now that we are into a Cisco LWAPP conversion/rollout, wondering if anyone else has found these issues to be obstacles to deployment/support, or if in the grand scheme you've found them to be non-issues: 1. Can't schedule configuration jobs- is no scheduling provision from WCS We have reported this to Cisco as a feature request. 2. No master view from WCS of all controllers configurations to compare for uniformity of config We are addressing this internally. We have written scripts to query various configurations via snmp and insert the data into a mysql database. We can then generate reports of potential problems. 3. No wild card searches for clients or APs when searching in WCS You can use % as a wildcard for your searches. It is still not great, but it helps. We have written our own code to help with this too. 4. AP radios come up in transmit, before proper vlan is assigned to them- meaning that clients might associate to a non-functional cell (meaning there might be confusion and help-desk calls) We never noticed this one. 5. No view of the Ethernet port on the AP from the WCS or controller, which means you can't tell if it negotiated speed or duplex correctly We have never needed this. We can always look at the switch port to get this data. 6. ACLs in the WCS have to be built line by line, no copy and edit or text file input 7. MAC address searches have to be colon delimited Correct, AND they are also case sensitive which we found thanks to a cut and paste search for a rogue AP. 8. Mispellings in the WCS GUI, usually on error popups 9. Difficult debugging, like from an AP you have no knowledge of what controller it associated to or tried to associate to If an AP is currently associated with a controller, the controller IP address is shown in WCS if you search pull up a list of APs. I suspect you are talking about APs that don't connect successfully. Early in our migration, we just brought those back to the office and got on the console and watched to see what was happening. This was very helpful. 10. No view from the AP or WCS on what switch and port the AP is on (CDP type view) That would be a useful thing except for one thing. We turned off cdp on all our ports with lwapp APs on them. This was the simplest way to enable the radios on some of our APs. Our switches are 802.3af aware, but they don't provide POE (we use the injectors). By default the radios would turn off and unless you went in and configured them individually. 11. Inconsistant AP association behavior, certificate issues on converted APs (mostly 1200s) not registeriing with controllers and having to be manually added We upgraded our older APs with the upgrade tool provided by Cisco. This tool would put the self signed certificates on one controller. This worked farily well. We would then have to go into WCS and refresh the WCS config from the controller that had the certificates. Then, in WCS go to controller templates - Security - AP Authorization and the certificates would all be there. These are templates and can then be pushed to all other controllers easily. 12. Converted APs drop their pre-conversion system names and go to mac address for name I don't know any way around this one. 13. No ability for AP groups VLAN templates for multiple controllers 14. Cannot use static WEP and AirFortress clients together on an SSID/VLAN as you can in the autonomous
