Wireless Access

So I have a controller on 6.1.2.5 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 5.0.4.5, 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

Uplink Status

IP Information

Gateway Ping

TPM Certificates

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.

Jeff

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.

Any suggestions?

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 6.3.1.3 and RAP OS 5.0.4.0.

Hi, 

i have excatly the same pb with controller ArubaOS 6.3.1.3 and RAP5-WN OS 5.0.4.0....

We opened a TAC case about this and we were informed of two things.  One, this is a bug in code 6.3.1.3.  It's supposedly resolved in 6.3.1.4.  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.  

Hi, 

thanks for your answer.

I try with 6.3.1.4 in couples of hours..

Aurélien.

Did v6.3.1.4 work?  Did you ahve the same issue with RAP-3's?

We did "upgrade" the controllers to 6.3.1.4 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 v6.3.1.3 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 6.4.0.2 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 6.3.1.3 this morning, the teleworker with the RAP-3 was actually on site so her RAP wasn't online.  We upgraded the controllers to 6.3.1.4 and all of our RAP-2s came online after the clients did a reset.

Hi, 

I confirm, it's work perfectly with 6.3.1.4

Thx, 

Aurélien.

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.

http://asia.cnet.com/expect-slow-internet-this-week-in-china-62219398.htm