Configuration Response Loss. AP and Zone Director on different subnet.

[alejandro_mende]

I am installing a 7025 on a different subnet of Zone Director. The Layer 3 connectivity is Ok. No firewall. The AP discovers the Zone Director. When the Zone Director starts provisioning of AP, the log send this message: AP[xxx] joins with uptime [1399] s and last disconnected reason [Configuration Response Loss]. The AP Status keeps on Provisioning. Any idea?

[brent_sergent]

If anyone is has an issue that seems related to 'configuration response loss' here is an example of an AP log prior to issue resolution.
The AP connection issue was resolved by resizing MTU both at remote site and ZD.



Feb 26 02:15:59 RuckusAP local2.err syslog: (ap state) AP begin to join ac.Feb 26 02:15:59 RuckusAP local2.err syslog: Cannot notify kernel for Upd AP Param 10.208.14.80(0) event, -- No such file or directory(2)
Feb 26 02:15:59 RuckusAP local2.err syslog: WTP join cfm response, lwapp_notify_kernel_ip_addr [nat  ipv4].   nat_ipv4_addr: 10.208.14.80    port: 0    family: 2
Feb 26 02:15:59 RuckusAP local2.err syslog: WTP join cfm response, lwapp_notify_kernel_ip_addr [ipv6].   ipv6_addr: ::    port: 0
Feb 26 02:16:41 RuckusAP authpriv.info dropbear[7702]: Child connection from 10.208.14.88:8204
Feb 26 02:16:44 RuckusAP authpriv.notice dropbear[7702]: Deferring to RKS shell to authenticate password.
Feb 26 02:16:44 RuckusAP authpriv.err dropbear[7702]: chown(/dev/ttyp0, 0, 5) failed: Read-only file system
Feb 26 02:16:44 RuckusAP authpriv.err dropbear[7702]: chmod(/dev/ttyp0, 0620) failed: Read-only file system
Feb 26 02:17:04 RuckusAP local2.err syslog: Proceed to IDLE state from CONFIGURAION state, no resp after 15 re-transmits
Feb 26 02:17:04 RuckusAP local2.err syslog: Cannot notify kernel for Delete AP 10.208.14.80(0) event, -- No such file or directory(2)

[james_julier]

had this issue with a client who had site to site VPNS, lowering the MTU to 1100 got the APs onboarded and upgraded

[victor_cenac]

After struggling with this issue after upgrading ZD to 10.1.1.0.4, the solution turned out to be opening ftp access to ZD from the AP. In the past, I only needed to open FTP during software upgrades. After that it was safe to keep it closed for remotely deployed APs.