- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
RAP5 not connecting
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Alert a Moderator
10-08-2012 01:07 PM
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?
Solved! Go to Solution.
Re: RAP5 not connecting
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Alert a Moderator
10-08-2012 01:12 PM
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
Re: RAP5 not connecting
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Alert a Moderator
10-08-2012 07:03 PM
Make sure the ap-group that has your AP does not have anything in the Authorization profile:
Re: RAP5 not connecting
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Alert a Moderator
10-09-2012 12:19 AM
If you use zero-touch configuration on RAP, did you enter rap white list on that controller about that RAP device?
Re: RAP5 not connecting
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Alert a Moderator
10-10-2012 05:38 AM
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.





