Wireless Access

Reply
Occasional Contributor II
Posts: 12
Registered: ‎01-27-2011

RAP5 not connecting

I have a RAP-5WN that refuses to be provisioned to any (tried 3 different) AOS 6.1.3.0 controllers. I successfully provisioned to AOS 5.0.4.2 and did the APflash, verified that the backup partition contained 5.0.4.2 (it shipped with 5.0.4.0 on backup partition). Tried with both 5.0.4.0 and 5.0.4.2 backup partition versions.

 

On the same controller we have other RAP-5WN's provisioned sucessfully with 5.0.4.0 on backup partition.

 

When originally provisioned to the 6.1.3.0 controller, the controller shows as "Upgrading" and then disappears. 128 AP and PEF licenses installed, with only 5 active RAPs (2x 5wn, 3x 2wg). Logs are shown below:

 

Oct  8 08:16:53  fpcli: USER:admin@10.112.2.100 COMMAND:<logging level debugging ap-debug "Tuck-AG0043532" > -- command executed successfully
Oct  8 10:53:35  stm[1591]: <305006> <INFO> |stm|  AP Tuck-AG0043532 rebooted
Oct  8 10:53:35  stm[1591]: <305009> <INFO> |stm|  AP Tuck-AG0043532 image version mismatch.
Oct  8 10:53:35  stm[1591]: <305010> <INFO> |stm|  AP Tuck-AG0043532 upgrading flash image.
Oct  8 10:53:35  stm[1591]: <305026> <DBUG> |stm|  sapm_ap_generic_req_proc: AP Tuck-AG0043532: req FLASHING setting last_activity to 1349711615
Oct  8 10:53:35  stm[1591]: <305026> <DBUG> |stm|  sapm_ap_init: AP Tuck-AG0043532: NOT setting auth timeout, auth = 1, by_user = ap_auth_not_required
Oct  8 10:53:35  stm[1591]: <305026> <DBUG> |stm|  sapm_ap_init: AP Tuck-AG0043532: is NOT a mesh node
Oct  8 10:53:35  stm[1591]: <305026> <DBUG> |stm|  sapm_proc_flash_reboot_req: AP Tuck-AG0043532: Sending response with result 0
Oct  8 10:53:35  stm[1591]: <305026> <DBUG> |stm|  sapm_proc_hello_req: AP Tuck-AG0043532: Sending response to (10.116.242.249) with result 1
Oct  8 11:04:50  stm[1591]: <305011> <INFO> |stm|  AP Tuck-AG0043532 rebooting.
Oct  8 11:04:50  stm[1591]: <305026> <DBUG> |stm|  sapm_ap_generic_req_proc: AP Tuck-AG0043532: req REBOOTING setting last_activity to 1349712290
Oct  8 11:04:50  stm[1591]: <305026> <DBUG> |stm|  sapm_proc_flash_reboot_req: AP Tuck-AG0043532: Sending response with result 0
Oct  8 11:05:36  stm[1591]: <305003> <INFO> |stm|  AP Tuck-AG0043532 is down
Oct  8 11:05:36  stm[1591]: <305026> <DBUG> |stm|  sapm_ap_ageout: AP name Tuck-AG0043532: ip 10.116.242.249: Aging out.

Any idea what could be causing this one RAP5 from connecting to any controller running 6.1.3.0 with a correct 5.0.4.x version on backup partition?

 

Occasional Contributor II
Posts: 12
Registered: ‎01-27-2011

Re: RAP5 not connecting

One thing I did notice...

 

 

(jpd91wc82) #show ap database

AP Database
-----------
Name               Group           AP Type  IP Address      Status           Flags  Switch IP
----               -----           -------  ----------      ------           -----  ---------
Tuck-AG0043532     rap-my-apgroup  RAP-5WN  10.116.242.249  Down             R-c2   10.116.236.2

 

 

 

Flag:  R- = Remote AP requires Auth

 

It is set to auth using Certificate and successfully auths on 5.0.4.2, but not 6.1.3.0 and the debug log states: <DBUG> |stm|  sapm_ap_init: AP Tuck-AG0043532: NOT setting auth timeout, auth = 1, by_user = ap_auth_not_required

Guru Elite
Posts: 20,992
Registered: ‎03-29-2007

Re: RAP5 not connecting

Make sure the ap-group that has your AP does not have anything in the Authorization profile:

 

auth.png



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Contributor II
Posts: 37
Registered: ‎07-05-2012

Re: RAP5 not connecting

If you use zero-touch configuration on RAP, did you enter rap white list on that controller about that RAP device?

kosuke
ACMP
Occasional Contributor II
Posts: 12
Registered: ‎01-27-2011

Re: RAP5 not connecting

It is in the whitelist and nothing in that profile. I believe it was due to the latency from the user's home network to any of our global controllers. The RAP-5WN AOS6.1.3.0 image must have been too large and timed out (he successfully provisioned a RAP-2WG from the connection). The user tried to provision from a faster connection (which was successful) and took it home. It now boots and connects to the controller from the slow connection.

Search Airheads
Showing results for 
Search instead for 
Did you mean: