Wireless Access

RAP reboots and then pulls a new address from pool, but never comes up entirely. Here is the latest log:

 

Jun  6 14:54:00  nanny[562]: <303086> <ERRS> |AP RAP4@192.168.20.30 nanny| Process Manager (nanny) shutting down - AP will reboot!
Jun  6 14:54:00  nanny[562]: <303086> <ERRS> |AP RAP4@192.168.20.30 nanny| Process Manager (nanny) shutting down - AP will reboot!
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  AP-GROUP:7  Group Name: default released
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  Adding user: 1090b384 (00:00:00:00:00:00:70.160.109.90:) to ap group:default ap group id: 7 role:logon
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  Free ipuser 0x0x108e9b6c (192.168.20.30) for user 0x0x10906e0c
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  IP DN int: 192.168.20.30, ext:70.160.109.90
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  MM: mac=00:00:00:00:00:00, state=2, name=A90247096, role=ap-role, dev_type=, ip=192.168.20.30
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  RX (sock) message of type 19, len 28
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  Tx message to Sibyte. Opcode = 17, msglen = 188
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  Tx message to Sibyte. Opcode = 17, msglen = 188
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  Tx message to Sibyte. Opcode = 17, msglen = 188
Jun  6 14:54:04  authmgr[1605]: <124004> <DBUG> |authmgr|  free user 0x0x10906e0c
Jun  6 14:54:04  isakmpd[1594]: <103056> <INFO> |ike|  IKE XAuth client down IP:192.168.20.30 External 70.160.109.90
Jun  6 14:54:04  isakmpd[1594]: <103060> <DBUG> |ike|  70.160.109.90:4500-> ipc.c:ipc_modify_sb_data&colon;2017 IPSEC  dst_ip=192.168.20.30, dst_mask 0.0.0.0 inner_ip 192.168.20.30 client:yestrusted:no, Master-Local:no
Jun  6 14:54:04  isakmpd[1594]: <103060> <DBUG> |ike|  70.160.109.90:4500-> ipc.c:ipc_print_dp_packet:2611 DP: :TUNNEL::SA_DEL::L2TP: OFF::incoming::ESP::AES256::Auth = SHA1:, SPI 13929500, esrc 46A06DCC, edst_ip C661EA09, dst_ip C661ECA2, natt 1, natt_dport 40964, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello
Jun  6 14:54:04  isakmpd[1594]: <103060> <DBUG> |ike|  70.160.109.90:4500-> ipc.c:ipc_print_dp_packet:2611 DP: :TUNNEL::SA_DEL::L2TP: OFF::outgoing::ESP::AES256::Auth = SHA1:, SPI BC724D00, esrc C661EA09, edst_ip 46A06DCC, dst_ip C661ECA2, natt 1, natt_dport 40964, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello
Jun  6 14:54:04  isakmpd[1594]: <103060> <DBUG> |ike|  70.160.109.90:4500-> sa.c:sa_check_peer:380 sa_check_peer: Found SA for 70.160.109.90
Jun  6 14:54:04  isakmpd[1594]: <103060> <DBUG> |ike|  70.160.109.90:4500-> sa.c:sa_check_peer:380 sa_check_peer: Found SA for 70.160.109.90
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500->  Setup the incoming IPSEC SA --- DONE  !!
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500->  Setup the outgoing IPSEC SA --- DONE  !!
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ->Delete INFO Exchange ic df0ccac8f2a15056 rc 569ab3476e15a4b6
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> freeL2TPIP freeing IP 192.168.20.30 from pool
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipc_setup_ipsec_dp_sa add=0, out=0, sa=0x101d117c, proto=0x101d1a34
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipc_setup_ipsec_dp_sa add=0, out=1, sa=0x101d117c, proto=0x101d1a34
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipc_setup_ipsec_dp_sa sa src=0xc661ea09, dst=0x46a06dcc
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipc_setup_ipsec_dp_sa sa src=0xc661ea09, dst=0x46a06dcc
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipsec_handle_leftover_payload: INITIAL-CONTACT made us delete phase 2 SA 0x101d117c
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipsec_handle_leftover_payload: received INITIAL-CONTACT
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> ipsec_sa 0x101d1734, proto 0x101d1a34
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> sa_release phase:2 calling client_auth_ip_down with ip=0xc661eca2, extip=0x46a06dcc
Jun  6 14:54:04  isakmpd[1594]: <103063> <DBUG> |ike|  70.160.109.90:4500-> sa_release: RAP decrement sessions 1

Is that RAP new?  What version of ArubaOS and when did this start happening?  Does it only happen with that RAP?

 

Upgraded the controller to Version 6.1.4.3-FIPS and had a major power outage shortly after causing it to lose all configuration. RAPs were all working prior to both events. All RAPs are doing the same thing. Our internal controller has same code and APs and WIDS work fine.

So, if it lost its whole configuration, how did you get it back onto the controller?

I had a saved running config in notepad and pasted it back in CLI. Tweaked some of it like the certs, shared key passwords, enable passwords and such.

Let me prepare you:

 

To troubleshoot considering the issues you have might require you to contact support.  That is because between a power outage and cutting and pasting back the configuration, it might be easier to start from scratch.  The configuration would need to be cut and pasted back in a particular order and some parts of it decrypted to be useful.

 

With that being said, just make sure that the ap-group for this particular access point exists on the controller, has valid information, and does not redirect the access point to another controller via lms-ip.

 

 

Ok thanks, any known issues with this code and RAPs?

No sir.

Is there any configuration errors after restoring the config run the command "show profile-errors" just to be certain