So I have a controller on 188.8.131.52 with several RAP-2s and RAP-5s already up and working happily.
I got a new RAP5. The firmware on both the boot and backup paritions is 184.108.40.206, so I should be able to get it to attach to my 6.x controller and upgrade it.
But when I try to get it to attach, everything seems ok at first. The web browser on the attached client gets successfully though
When it hits Master Connectivity I get the message
IP X.X.X.X using Ethernet Aborted : sapd_check_hbt id doing tunnel down
It then proceeds to successfully pass "LMS Connectivity"
and then spins forever on "Continuing"
Any ideas how to start debugging this? I would suspect a controller config error, but I have working good RAPs off the controller.
Haven't seen that message before. I'd probably start with factory resetting the RAP (pin the reset button) and starting over.
I've already done a factory reset sever times to no avail.
Is this RAP connected at the same location as other working RAPs?
I hope it is added to the whitelist on the master controller.
When AP is trying to come-up, do you see ISAKMP SA and IPSEC SA being formed? (chow crypto isakmp sa // show crypto ipsec sa)
If so, check "show user-table verbose" and make sure RAP falls into the AP-Role.
I am getting same error with a RAP-2.
I've even taken the RAP-2 and defaulted and connected directly to my local LAN with the controller and I'm still getting same error. I also tried removing them from whitelist and try to let them come up as a normal AP but that isn't working either.
IPSEC SA shows them trying to connect and show user-table verbose shows them in the AP-Role.
This is output with RAP connected directly to LAN with controller. RAP is on whitelist and is pointed towards the internal LAN address of the controller.
(ADK-620) (config) #show crypto isakmp sa
ISAKMP SA Active Session Information ------------------------------------ Initiator IP Responder IP Flags Start Time Private IP ------------ ------------ ----- --------------- ---------- 10.0.0.133 10.0.0.11 r-m-c-y-R Feb 5 09:49:00 192.168.4.181
Flags: i = Initiator; r = Responder m = Main Mode; a = Agressive Mode v2 = IKEv2 p = Pre-shared key; c = Certificate/RSA Signature; e = ECDSA Signature x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled 3 = 3rd party AP; C = Campus AP; R = RAP V = VIA; S = VIA over TCP
Total ISAKMP SAs: 1
(ADK-620) (config) #show user-table verbose | include 2f:7b 192.168.4.182 00:00:00:00:00:00 00:0b:86:c3:2f:7b ap-role 00:00:02 VPN 10.0.0.133 N/A tunnel Internal 1
(ADK-620) (config) #show crypto ipsec sa
IPSEC SA Active Session Information ----------------------------------- Initiator IP Responder IP InitiatorID ResponderID Flags Start Time Inner IP ------------ ------------ ----------- ----------- ----- --------------- -------- 10.0.0.133 10.0.0.11 192.168.4.182/32 0.0.0.0/0 T Feb 5 09:53:11 192.168.4.182
Flags: T = Tunnel Mode; E = Transport Mode; U = UDP Encap L = L2TP Tunnel; N = Nortel Client; C = Client; 2 = IKEv2
Total IPSEC SAs: 1
(ADK-620) (config) #
When I connect pc to RAP-2 E1 is shows the following on the browser.
Successful eth0 interface up
Successful IP 10.0.0.133 mask 255.255.255.255.0 Gateway 10.0.0.7
Gateway Ping successfull
TPM Certificates successfull
Master Connectivity IP 10.0.0.11 ((Controller LAN address)) using Eternet Aborthed sapd_check_hbt is doing funnel down
LMS Connectivity Successful LMS IP 10.0.0.11 using Ethernet
I am also experincing same issue. Could you let me know what is the current code version on the controller and RAP's backup partition?
We're seeing this error with controller ArubaOS 220.127.116.11 and RAP OS 18.104.22.168.
i have excatly the same pb with controller ArubaOS 22.214.171.124 and RAP5-WN OS 126.96.36.199....
We opened a TAC case about this and we were informed of two things. One, this is a bug in code 188.8.131.52. It's supposedly resolved in 184.108.40.206. I guess we're going to have to test the waters with that. We also found out that the RAP2s and RAP5s were EOL in October and will not be supported beyond 6.3.x. So if you are planning on upgrading to Aruba OS 6.4 at any point keep in mind that you will have to replace all of your RAP2s and RAP5s. This bit us because we bought a few of the new outdoor AP-270 series and they only come as IAPs. If you want them to be a part of your controller network (which, of course you would, why on earth would you want to manage an IAP network and a contoller network in one a single campus.... but I digress) they require the controllers to be on ArubaOS 6.4.x which is in ED.
thanks for your answer.
I try with 220.127.116.11 in couples of hours..
Did v18.104.22.168 work? Did you ahve the same issue with RAP-3's?
We did "upgrade" the controllers to 22.214.171.124 and that fixed it the sapd_check error. We didn't have any issues with RAP-3s on 6.4. The legacy RAPs/CAPs aren't supported in 6.4.
Thank you. I was wondering if you had any issues with the RAP-3s while you were on v126.96.36.199 similar to what you saw with the RAP-2s.
To be honest, I don't know if the RAP-3s were experiencing the issue. We upgraded our masters to 188.8.131.52 and couldn't get our RAP-2s to work. I had a RAP-3 on hand that came online without issue on 6.4. When we rolled our controllers back to 184.108.40.206 this morning, the teleworker with the RAP-3 was actually on site so her RAP wasn't online. We upgraded the controllers to 220.127.116.11 and all of our RAP-2s came online after the clients did a reset.
I confirm, it's work perfectly with 18.104.22.168
One of our customers has an office in China and when they try to connect a RAP to a MS in the UK they get the same error.
This is because the Government is doing a reform and they have completely locked down the internet.
Please see below link for the article.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.