we have been running a Proof Of Concept pilot at a large retailer at which we are the incumbent and cisco is the competition. the architecture is APs at remote locations and cloud controllers at the data-center. cisco is using their AP3502 APs and the 5508 controllers. they seem to have come across an issue where if they disconnect the WAN link and loose connectivity to their controller, our PPT8846 units will no longer roam and since other devices such as MC55 or smart phones still work under this condition, they are blaming it on the device. BTW, our gear (AP6532 + RFS6000) has no such problem and I believe CISCO APs may not be handling the TKIP-PSK credentials correctly after they loose connection to their controller. before doing any investigation at customer premises i would like to be prepared with as much information that is available to us, so If anyone has come across this before and have more insight that they could share, it would be greatly appreciated. thanks, afshin
competitive pilot with CISCO// Expert user has replied. |
3 Replies
I wanted to post a resolution to this case ofr anyone who might be interested. testing at customer's LAB: I set up our gear at the customer site to duplicate the scenario and showed them that when our APs lose connectivity to the controller, there is no impact on roaming. we also ran through the test on CISCO gear. on cisco APs, the LED-color on the AP indicates that it has something associated to it. we noticed that when the controller is present, the 8836 device roams from one AP to the next and as it does, the APs change LED color. but when the controller is NOT present, as the 8846 roams to new APs and it leaves an association trail. all the previous APs still think that they have the unit associated to it. we could tell this by the LED indicator. At this point the device is registered with two or more APs and of course the traffic will not flow through to the wired side correctly. In a recent conversation with the customer I was told that CISCO took some 8846 devices to their lab, did some testing and they came up with a new firmware that fixed their issue. please note that this issue was only reported on 8846 devices. the customer also has MC5590s and they did not exhibit any similar behavior during the test (both using same ESS_ID and PSK). thanks, afshin
Afshin Some time ago we had a very similar situation with central Cisco controllers using HREAP to connect to the remote APs (not sure which ones exactly) in the stores. Rapid roaming with 4-way handshake synchronization failures caused our mobile devices to 'lock-up'. It seems you situation may be very similar. The mobility of the devices relied on the controllers, and if the controllers were absent/unavailable the roam would fail. Let me know if you need more details. Z
Afshin, not sure how PSK credentials show up in a trace, but with WPA2 and PMKI keys, I was able to show that our device was properly including the PMKI key as part of the re-association request. Then they turned on controller logging and you could also see the PMKI key was being sent. So, I wireless trace of that device, combine with the controller logging should show whats going on.