I'm trying to get an AP to join my controller at work from my house. I've got standard DSL from Frontier, so no QoS for the LWAPP traffic. The controller sees the DISCOVERY request from the AP, and the AP indicates that it receives the DISCOVERY REPLY by going to the JOIN state, followed my 'no more AP manager IP addresses remain'. I'm suspecting that this is happening due to the face that my RTT is over 100ms. Anyone care to comment? I'm fairly confident I've got all the necessary firewall rules setup correctly. Here's the error output from the AP:
%LWAPP-3-CLIENTEVENTLOG: Controller address 66.xx.xx.xx obtained through DHCP
%LWAPP-3-CLIENTEVENTLOG: Did not get log server settings from DHCP.
%LWAPP-3-CLIENTEVENTLOG: Performing DNS resolution for CISCO-LWAPP-CONTROLLER.pickles.pic
%LWAPP-3-CLIENTERRORLOG: DNS Name Lookup: could not resolve CISCO-LWAPP-CONTROLLER.pickles.pic
%LWAPP-5-CHANGED: LWAPP changed state to JOIN
%LWAPP-3-CLIENTERRORLOG: Join Timer: did not recieve join response (controller - VPN-4402-01)
%LWAPP-3-CLIENTERRORLOG: Set Transport Address: no more AP manager IP addresses remain
%SYS-5-RELOAD: Reload requested by LWAPP CLIENT. Reload Reason: DID NOT GET JOIN RESPONSE.
%LWAPP-5-CHANGED: LWAPP changed state to DOWN
1. How many AP's can your controller handle and how many AP's are currently attached to the controller?
2. Sounds like you are trying to implement the new OfficeExtend feature.
I've been working with this stuff since it was AireSpace, so I'm familiar with all kinds of issue(s) one could have joining a controller. In this case, it isn't the literal meaning of the error as you suggest (i.e. reached the max number of APs for the ap-manager interface or for the controller in total). This is a 4402-50 running 18.104.22.168, with only 4 APs. I'm not attempting the OfficeExtend feature since this isn't a 5508 controller - just trying to see if I can prove whether or not an AP can be remoted to a SOHO. I will probably put the AP in H-REAP mode and see if it works since the deployment guide for H-REAP indicates you can do this. However, I just have this gut feeling that the JOIN REPLY just isn't getting here within the 100ms RTT limit to make it valid and it's as though the AP just never 'hears' it.
Yes, I did in fact. As you point out, the 22.214.171.124 code on my controller is going to 'speak' capwap, but can fall back to LWAPP for APs that are still running pre-5.2 code locally. This is the case with my AP, so it's performing all of this via LWAPP until it joins and updates its code. I could force the code update, but I'd rather not just yet. I think what I'll do is expose the AP using a public IP address and test that.
It depends on what controller you are using. If you have a 5508 you just need to go under the management interface on the controller, enable NAT, and enter the public address translation for the management interface.
What's going on is when the controller responds with the discovery request it gives the address for the AP to join. If you don't have this NAT statement on the controller configured the AP will be given the controller's internal address (192.168.x.x for example) and tries to send its join request there.
If you are using a 2100/4400/wism this NAT functionality for the ap-manager interface isn't available as it is on the 5508.
Hmmm, sounds interesting. Lemme check to see if providing a static NAT for the controller to the ap-manager interface does the trick...
Setting up static NAT won't do the trick. The ap-manager's address is embedded into the discovery reply. The issue is that the AP will receive the address that is actually configured for the ap-manager and the AP will send its join request to that address.
Forgot to also ask where you are using NAT? On the home router, work router(s), all the above?
Since you've got the whole CAPWAP/LWAPP thing going on, it might make sense to try a local join, and then take the AP back out on the road.