Wireless Access

We have a couple of AP-135 with statically configured IP addresses.  These used to work quite well with a 3600 controller.
Following a network interruption to the controller, the these APs now report as "Dirty or no config" and the controller logs "No response from AP for CONFIG request for 3614 sec; deleting AP" messages for each AP every 70 minutes. 
The controller can successfully ping each of these APs and does correctly report their uptime, and yet cannot re-provision these APs.  I've extended the heartbeat interval and the bootstrap threshold to allow for slow links but to no success.
What diagnostics should I perform next?

HI,

 

What Image version you are using ? which Master discovery method you are using ? try again by purging the AP. what is the BSS and AP up time you are seeing ?

 

We're using version 6.3.1.5.  I know it's not new, but it is very reliable.
There is no master discovery method, the master-ip and the server-ip are hard-coded to point to the controller.  This is successful as the controller correctly sees the AP and the correct uptime.
The command "show ap bss-table ap-name <AP-135>" reports all six of our BSS (3 SSIDs over g-HT and a-HT) in exactly the same form as a known good AP.  
The (current) uptime  of 11 minutes is correct for this AP. 

Try to give them a reboot by bouncing the switch port.

If you can physically get to them, a purge and then putting the master ip in again might fix.

 

Last resort would be a clearos.  You have to put the master and serverip in.  The AP will then download it image and be brand new.

@Michael_Clarke: I've tried rebooting these APs. They seem to keep their dirty config. Your next suggestion (resetting these APs back to factory defaults) is the next on my list. I think I'll combine that with a "clear gap-db ap-name [AP-NAME]" and totally rebuild the site. @ColinJoseph: If the above rebuild doesn't work, I will certainly log a TAC call. My firewall people tell me that there are definitely no ports blocked at that site. If I have to go to site nmap can confirm. Are there specific ports I need to know about? @ascott: The RAP solution may be effective - and I may need to do this. But I'm still interested in debugging the reason the change occurred.

SteveDowling,

 

Are all of these access points at the same site?

Is it separated from the controller by a WAN?

Is this an MPLS or site to site VPN connection?

 

@Colin: Yes, both of these "Dirty" APs are at the same site. It is connected to the controller by a slower-than-I'd-like link - but has a history of working fine for a couple of years. We have several (too many) other sites on the ends of 'slow' links that work connect correctly to their controller.

What kind of connection is it?  Some things that work for a few months just get bad enough so that they dont work.

@Colin: This site is connected by a leased line. It certainly _was_ working when we left site in 2013, and demonstrably worked in 2014... New information. I aatended site this morning and found good IP connectivity. The AP can ping the controller with no loss, and the controller can ping the AP and show a good circuit. The AP, however, does NOT load the 'armv5te.ari' file - and hence does not act as a well-behaved AP. This behaviour is common to all APs at this site. Hmmm...site specific or controller specific??

If it is MPLS, you should make the MTU 1100 in the ap system profile.

---

@SteveDowling wrote:

We're using version 6.3.1.5.  I know it's not new, but it is very reliable.
There is no master discovery method, the master-ip and the server-ip are hard-coded to point to the controller.  This is successful as the controller correctly sees the AP and the correct uptime.
The command "show ap bss-table ap-name <AP-135>" reports all six of our BSS (3 SSIDs over g-HT and a-HT) in exactly the same form as a known good AP.  
The (current) uptime  of 11 minutes is correct for this AP. 

---

I would open a TAC case in parallel, because your problem could take a significant effort to track down.  You could type "show log system 50" to see if there are any clues as to why your access points are not coming up.  Hopefully you do not have a firewall between your access points and your controller that is blocking port.

 

I've had a few APs go into dirty config after upgrading to AOS 6.4.x from 6.3.x.  OPened a TAC case and never could get them out of dirty config when pointed them to a the upgraded 6.4 controller.  These were remote APs in standard campus mode.  Funning thing was the APs worked fine if I pointed them to another 6.3 controller or a different 6.4 controller.  Was very strang.

 

In the end TAC recommended I convert them to RAP mode.  Was very simple controller config but had to have someone console into the APs.  TAC recommends and remote APs to a controller be in RAP mode so they use IPSEC instead of GRE as the MTU is handled differently.  In any event I still use CAP in most remote sites but when I see dirty config converting to RAPs has been doing the trick.

 

May not apply in your case just thought I would mention in case it helps.