(Apparently, this posting is too long for the system so I will break it up into separate sections)
For what it's worth, after upgrading to WCS version 4.1.91, we noticed a number of really obvious bugs within the system. On the upside, we have not found any that seem to "break" the system in terms of functionality, but they do result in a number of issues within the user interface that clearly do not work.
If you want to have some ?fun?, read through the release notes for WCS 4.1.91
and you will find quite a number of known ?caveats? that are listed (and there are many more that we have discovered and turned in that did not make the list by the time it was published).
To hit some highlights of what we have encountered:
* QuickSearch does not work properly.
You do not always get taken to a list of hits when typing in a mac address in Quicksearch.
Ideally, if there are multiple hits in different categories (alarms, rogue AP, etc.) it is supposed to take you to a page showing what categories (and the total number of hits within the categories). However, you will get varying results depending upon where that mac address is found by the WCS. If searching for a rogue AP, you can end up getting dumped into a list of rogue APs. If you are taken to the categories page showing where a MAC appears within the system, and click the ?alarms? link, you will be told ?No alarms exist?.
CSCsj27469 Quick search alarm count sometimes does not match with the alarm list shown on clicking the alarm count. Specify an AP MAC address in the quick search box input box. Quick search will show the Alarm count if there are matching alarms for that AP. Click on the alarm count and it will not match the alarm list shown.
CSCsj01432 Quicksearch is using wrong search string for Rogue Aps. If Quicksearch function is used, to find Rogue AP alarms, the resulting page (QuickSearchAction.do) is passing the wrong search string to searchAlarmAction.do applet. The results is that instead of returning the Rogue AP alarms, matching the Rogue AP MAC address, all rogue alarms are displayed. Using Quicksearch to find rogue AP alarms filtered per MAC.
CSCsj34934 (CSCsj34934 has been superseded by CSCsj01432 - above)Quicksearch is using wrong search string for Rogue Aps. If Quicksearch function is used, to find Rogue AP alarms, the resulting page (QuickSearchAction.do) is passing the wrong search string to searchAlarmAction.do applet. The results is that instead of returning the Rogue AP alarms, matching the Rogue AP MAC address, all rogue alarms are displayed. Using Quicksearch to find rogue AP alarms filtered per MAC
Have you tried the 4.1.91 code for WCS and tried using the predictive planner mode for a floor plan.
What were your results?
I am seeing a HUGE increase in the number of APs needed for the deployment from the last code.
It more than doubles and can triple the number of APs needed for data coverage.
For example : a floor that 60,000 square foot drywall office type- for data only coverage, it predicts I will need in excess of 20 APs at -75 dBm. This was in the Aggressive Planning Mode. The count in Safe Planning mode went of course even higher.
I ended up over riding it and planning based on real time data I was getting from a manual survey and placing the APs on the floor plan.
I am running on 4.1.91 and it is an improvement over the previous version. It appears to be fairly stable as well, but still has a significant number of bugs. I am looking forward to the 4.2 release which is supposed to fix MANY of the bugs still out there.
Unfortunately, I have never used the predictive planning tool, so I cannot compare its old and new behavior.
I just noticed when you add a user through the lobby ambassador it creates it and you can see it if you telnet to the controller but it never shows up in WCS, so the help desk guys have no idea what's there. Long story short this thread may keep growing.
Yes - there is a bug (BUG ID CSCsi95289) that through WCS you can only see 20 Guest User accounts within the GUI. If you have 21, you won't see the 21st one. Delete one and then you'll see that most recent account you created. This is another example of having to log into the controller to see the netuser information. A way to try and get around the problem is to sort the username alphabetically. Then you may see the account you are hunting for. This particular bug is supposed to be resolved in the 4.2 WCS release.
I was just reading the 4.1.91 release notes myself- hoping for brighter days after all of the bugs in earlier code- and as usual, it's nothing but disappointment.
I find this endless proecession of bugs to be maddening. Where is Quality Control in any of this, and have any of Cisco's developers in this area actually ever worked on a real WLAN? This groups seems completely out of touch with what real-world WLAN admins expect from reliability and quality- especially when the Cisco logo is on it.