I've loaded the firmware since yesterday. So far all looks OK and I haven't broken anything yet.
Wireless VoIP is still working fine.
Running 6.0 at 4 smaller hospitals with data only since Monday with no issues. Our 2 larger 400 bed hospitals have 7921 and Vocera, so we'll likely wait for a MR or 2.
Anyway here are some lab benchmarks you guys might find interesting. Measurements were taken from IXIA Chariot running 4 simultaneous high performance streams to and from the client. The client is running an Intel 4965 with 126.96.36.199 drivers. The 1142 is POE and the 1252 is full power via injector, both connections at GigE and 20Mhz channels. WISM running 188.8.131.52, 184.108.40.206 and 220.127.116.11 on the controller. Looks like 6.0 shows some downstream speed improvements.
Chris,according to 6.0.182's release notes, it says the 128-bit key size option for static WEP has been removed from the controller
GUI and CLI. That may be your root cause.
Here's a few "cosmetic" things I've found:
1. The Rogue Summary is showing I have 23 Active Rogue APs, but if go into more detail, I can only count about 17-18. The numbers will remain that way until I reboot the controller.
2. The time on the WLC and the time on the LAP are approximately 10 hours off. If you do a "sh time" on the WLC and do a "sh ap eventlog", you'll notice a significant time difference. I've already noticed this since the 5.2.X firmware and I can't tell whether this happened in earlier releases. I've created a TAC Case regarding this and initial response is saying that I'm dreaming. He he he ...
i am running 18.104.22.168. bought had a stroke this morning when i rebooted a wlc. the lag was diabled when the wlc came back online. other than that all appears to be runing very smooth.
Have tested roaming with some Rim devices and works fine.
have not tested with critical stuff like voice or video yet.
what do you mean with signal bouncing?
own ap's detected as rogues?
Hi there, I am just reading, that you experienced somtehing like signal bouncing ... I am afraid I have similar problems ... clients reports signal strength fluctuating.
Is that what you mean by signal bouncing? And any solution for this ?!
Thanks a lot
When you said "own ap's as rogue", do you get a "potential honeypot" eventlogs?
If so, this is a well-known (and well-reported) bug. Each AP reports another as a "potential honeypot". One way of addressing this is to relocate the offending AP's somewhere else or playing around with the Radio Resources Management. Frankly, I'd relocate the AP.
Hope this helps.
Im havin a problem where all my remote access points are showing up as offline. They dont even show up in the controller as connected. However the access points on the same subnet as the controller connected just fine.
So right now I have about 70 access points showing up as offline and only 5 connecting lol!
apparently this seems to be a gateway issue on the controller? I can ping the management address on the local network just fine, however I cant not ping it from the remote networks (and yes routing is working fine) However something very interesting, if I go into the management interface and just press apply the I get a few ping request from the ip but then it times out again. If i go into the access points section I see a few of the remote access points have joined and started to download the new IOS. However they disassociate again. Anyone else having this problem with 22.214.171.124?
I think I get what you are saying. Just yesterday, I was preparing for impending conversion of a significant amount of APs to LAP. So I was playing with a number of AP 1240. All the AP's booted on the RCV image, joined the WLC (almost immediately) to download the LWAP image. After the reboot, the LAPs take about 5-10 minutes before it would join the WLC. After I configured static IP Address (using the GUI) the LAPs would un-join the WLC and take another 5-10 minutes looking for the WLC. During this stage, the LAPs now with static IP Address, couldn't find the WLC. The LAP would suddenly get DHCP IP Address, join the WLC and revert back the static IP Address assigned.
The best way to describe is thinking about pc with a static ip address without a gateway address. Locally everything works fine, however try to go outside the network and it has no idea how too. That is what im experiencing. I rebooted the WLC again this morning while pinging the address from a remote site. I got one ping reply then it timed again. I forward this onto cisco with a picture of the pings, I haven't gotten a response all day. Talking to those on site, the wireless is working fine. But I still have many wireless access points that cant connect to the controller at all unless I go into the management interface, press apply and wait. Some will join then leave the controller. Its very odd
Ive open a TAC case with Cisco, the more I look at this, the more I think its a software issue! The lady at Cisco was telling me I needed the Option43 on my remote DHCP servers. This has been working fine without it since 4.x, plus none of the remote sites can ping the controller so even if their was an option43 in the DHCP the controller would never respond! Its difficult to explain that when both parties have a hard time understanding each other on the phone.
Sounds like TAC is wasting your time. If you can't ping the management address from a routed subnet, then opt43 is irrelevant. Could be some type of GW issue or LAG hash issue. Why don't you try pointing the manage GW to a physical address on one of your cores. Also try disabling each gig port independently and see what happens. There are HSRP bugs from time to time and LAG requires src-dst-ip load-balance. Also you might try "debug ip icmp" on your cores and see if that shows anything.
Anyone else having trouble with MAC Filtering on some WLANs since upgrading to 126.96.36.199?
I've found that our WLANs that had MAC Filtering applied to WLANs running WPA2/AES/PSK can no longer associate.
This is also true for another WLAN running WPA1/AES/PSK.
The common thread I see here is AES.. is this a known problem with the new release?
I should make it very clear that these WLANs have been running in this state without issue prior to upgrading the WLC to v6.
Im sorry I didnt update, I got it working. Two issues occurred
1. with this update, they remove the lwapp name and changed it to capwap. I had to change my DNS entry for the controller, TAC was asking me to run the old lwapp debug commands.
2. We had two of the 4 gigabit in a etherchannel, i randomly just added a third port into the etherchannel and i started getting ping responses from the controller at the remote sites. I havent taken the time to unplug to the first two ports to see if it still works. What all my remote sites are now back online!
I just upgraded to 188.8.131.52 last weekend. I had a little trouble with the static service IP not showing up. I eventually rebooted a couple more times and they came back up. I've enabled Clientlink on all the 1142 APs and they seem to be working fine with our a/g/n radios. We are getting better SNR values on clients and seeing better throughput as well.