Thanks, but 8.5.135.0 has several bugs that affected us and are fixed in 8.5.140.0.  It's an option but it exposes us in other ways. Right now I would just like to get anyone who is running 8.5.140.0 and 5520's to check their show memory pools output and see if the 16 byte buffer is growing like we see in our controller.   ... View more

I know this is an old post, but I wanted to share what I recently found while troubleshooting management from wireless issues.  The behavior I was seeing was this.  I have several controllers with management interfaces all on the same vlan, say vlan100. I have wireless user vlans configured on several controllers, say vlan200,201,202, etc. All controllers are configured to allow management from wireless.  There is a firewall between the wlan controllers and the rest of the LAN, and the firewall is the default gateway for all controller vlan interfaces. The WLAN controllers are running 8.5.135.0 code.   When associated to an AP on Controller 1, on vlan201, I can access controller 1 management interface via HTTPS and ssh, no problem.  However, I could not access Controller 2 management interface via HTTPS or ssh, but I could ping it. I don't believe the reason is that Cisco "locked down" the ability to manage a different controller from wireless other than the one the wireless client is associated to.   What I found is that when my client machine sent packets to controller 2 mgmt interface, the path was from wifi adapter thru AP thru Controller 1 to FW on vlan201, then out FW on vlan100 to controller 2 mgmt.  The return path from controller 2 to client was from controller vlan201 dynamic interface directly to controller vlan201 dynamic interface to the AP and to the client.   For ping (ICMP) echo and echo reply traffic, this will work just fine even though the forward path was thru the firewall and the reverse was not.  For TCP traffic however, the behavior of the firewall caused the communication to fail.  In this case, the firewall used TCP randomization to change the sequence numbers on the client and server sides as the packets passed thru it. This is a security feature that protects against attackers trying to predict future sequence and acknowledgement numbers and intercept/hijack communications. The FW was a Cisco ASA running 9.3 code.   The result was a TCP connection attempt where the client sent SYN with seq "abc", the FW changed it to seq "jki", and forwarded on to controller. The controller sent ACK with seq"pqr" and ack "jki" (acknowledging the SYN packet) directly to client via the common vlan201 path between the controllers, bypassing the firewall. The client received the ACK with ack "jki", when it was expecting and acknowlegement for "abc", and immediately sent a RST back to the controller.   The same behavior was seen with both ssh and HTTPS management traffic as they both use TCP.  The reason the asymmetric path was taken, is for the return path, controller 2 broadcast an ARP request for the mac address for my client machine, on vlan201. The arp request is directed to my client by the wireless infrastructure (the controller or the AP, I have not confimed which yet) and my client replies with it's mac back to controller 2. So before controller 2 sent the SYN ACK, it inserted the client MAC into the frame and forwarded it out the vlan201 dynamic interface, directly through controller 1 and up to the AP, instead of inserting the FW mac address for the mgmt vlan100 gateway and sending the packet out vlan100.   I believe this issue would still exist even if the firewall did not use TCP randomization, as long as the firewall tracked state in the flows. Without TCP randomization, my client would have accepted the SYN ACK instead of sending a RST, and sent the final ACK in the handshake, thru the firewall, but the firewall would have blocked the ACK since it never saw the SYN ACK, and the RST would likely have come from the firewall as it killed the invalid connection.  If there were no firewall, or if the "firewall" was really just ACL=based and not stateful, then I do not think this asymmetry would prevent the management the same way.   I am still trying to think of a scenario where this behavior might break communication other than Administration of the controllers from wireless vlans, which is more of a nuisance than an issue for us, as we can either connect via ethernet or remote into another machine when trying to manage a different controller than the one you are associated to.  It seems this might cause issues if one roams from an AP on one controller to an AP on another controller if the controllers share the same dynamic vlans, and if there is TCP traffic traversing a firewall between clients on either controller.  However, in well-designed wireless networks, I don't think this would commonly occur. In our case, we are preparing to migrate from three 5508 controllers to an HA pair of 5520's, so that is why we have shared dynamic vlans between the controllers. Once migrated, we will not have the old 5508's to manage and this will not be an issue any more. ... View more

DId you doublecheck the controller name you configured for the Primary or secondary controller for the AP? Not sure about your older version 4.2, but newer versions require the primary controller name configured for the AP to match exactly the name configured for the controller, including upper/lower case characters. If they don't match, I have seen a problem similar to yours where the AP does not like the response from the controller. ... View more