Wireless Access

I have a couple of AP-93's, that I am trying to connect to a 3400 on the other side of an vpn tunnel. The AP's will show up as status "upgrading" after a long while, and then dissappear again. This continues over and over, I tried setting the MTU to 1300 on the ap system-profile, but this doesn't seem to help.

The AP's hadn't been provisioned before, so they ended up with the default profile. My best bet right now is to do a purge and reset the AP's and try again.

Any suggestions?

How are you setting up the AP-93? Are you hard coding the controller IP / master IP on the AP?

(assuming this is a master/local scenario)

My guess would be that they cannot communicate with the controller IP address that they are being assigned to. You could even try creating a new ap group, setup the LMS as the master IP address, and provision them in there. If that works, you know it's a problem with them getting to the local.

If the AP-93 is new, it is very possible that it does not have an ArubaOS image. It will use its firmware to download the ArubaOS image via tftp by resolving aruba-master.yourdomain.com (where yourdomain.com is the domain it received via dhcp).

To override the server name resolution, you could hard-code the server-ip and master environment variables by dropping into the apboot prompt and entering the following:

setenv serverip xx.xx.xx.xx

setenv master xx.xx.xx.xx

save

reset

Once the AP-93 downloads its code via tftp, it will boot up and attempts to contact the master controller. Once it does, it will download the version running on the master via ftp. I suggest version 6.1.3.1 on the controller for best results. 

Hi,

I checked now, and can see traffic going to and from the controller and AP's. I am setting the controller through dhcp options 43 and 60. Will try to add aruba-master record in dns.

now the AP changes state to denied. in the whitelist, they have a state of "approved-ready-for-cert"

the log shows the following messages:

Unsecure AP "d8:c7:c8:c8:98:8d" (MAC d8:c7:c8:c8:98:8d, IP x.x.x.x) has been denied access because Control Plane Security is enabled and the AP is not approved.

<303086> <ERRS> |AP d8:c7:c8:c8:99:3e@x.x.x.x nanny| Process Manager (nanny) shutting down - AP will reboot!

<303022> <WARN> |AP d8:c7:c8:c8:98:8d@x.x.x.x nanny|  Reboot Reason: AP rebooted Tue Apr 24 07:10:58 GMT 2012; SAPD: Reboot after image upgrade failed: -1

this problem only occurs for AP's going through vpn tunnels

danish82,

Unfortunately, the MTU setting in the  ap system profile only takes effect once an ap has upgraded and gotten its instructions.  If the AP has not made it to the whitelist yet, it cannot receive the MTU 1300 command.  You can try to sidestep this by turning off control plane security temporarily if you do not need it, or upgrade the APs before sending them out to the site with VPN.

ok :(

There's no way to set this manually on the AP either?

no difference with control plane security disabled.

it seems like the ap downloads the boot image ok, but every time it logs the following:

Reboot Reason: AP rebooted Tue Apr 24 12:59:20 GMT 2012; SAPD: Reboot after image upgrade failed: -1

then it will try to download the boot image again, and the circle continues. is the only solution, to actually ship the AP back, provision it and send it out again?

please open a TAC case, so they can determine exactly what is happening.

case solved. The problem was an RTT of around 300ms. The download of AP image was too slow, which caused a process to timeout (10 mins) and the cycle repeated it self over and over.

TAC provided me with a patched image which works just fine now :)

This was only a problem because I hadn't provisioned the AP's before shipping them out.

I'm having a similar issue. I've got AP93s on the back on a route based VPN between 2 fortinet firewalls. The APs discover the master using DHCP options from the Fortinet and connect to the controller. They upgrade their image ok and are provisioned in the "default" ap group.

However, when I try and provision the AP into a different ap group, they just seem to hang. They still show as up on the controller but I can't re-provision them (I'm assuming this is because the controller knows it's tried to push down a new config). Ultimately I have to power-cycle the the remote campus APs and then try the re-provisioning process all over again, unfortunately with the same result.

I have changed the MTU value in the default ap group to 1400 but this was after the APs initially connected to the controller.

Does that different AP-Group have an LMS-IP in the AP system profile?

Please type "show log system 50" to determine what is going on.

Hi Colin,

Yes the ap-group does have an lms-ip address, outputs from a system log and ap-debug are as follows

system-log

May 15 10:26:09 :303022: <WARN> |AP d8:c7:c8:c8:92:4d@192.168.4.112 nanny| Reboot Reason: AP rebooted Tue May 15 10:15:20 gmt 2012; SAPD: Reboot after image upgrade failed: -1
May 15 10:38:33 :303022: <WARN> |AP d8:c7:c8:c8:92:4d@192.168.4.112 nanny| Reboot Reason: Reboot caused by kernel panic: assert

ap-debug

May 15 10:38:52 :305006: <INFO> |stm| AP d8:c7:c8:c8:92:4d rebooted
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_init: AP d8:c7:c8:c8:92:4d: NOT setting auth timeout, auth = 1, by_user = ap_auth_not_required
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_init: AP d8:c7:c8:c8:92:4d: is NOT a mesh node
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
May 15 10:38:52 :305026: <DBUG> |stm| sapm_override_ap_radio_prof: AP d8:c7:c8:c8:92:4d radio 0: enabled 1 mode 1 chan 6 pwr 30
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_get_vap_config: AP d8:c7:c8:c8:92:4d radio 0
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_assign_vaps: AP d8:c7:c8:c8:92:4d radio 0 enabled 1 mode 1 (16 VAPs) VAPs to assign 1
May 15 10:38:52 :305026: <DBUG> |stm| sapm_proc_hello_req: AP d8:c7:c8:c8:92:4d: Sending response to (192.168.4.112) with result 0
May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_generic_req_proc: AP d8:c7:c8:c8:92:4d: req FLASHING setting last_activity to 1337078332
May 15 10:38:52 :305026: <DBUG> |stm| sapm_proc_flash_reboot_req: AP d8:c7:c8:c8:92:4d: Sending response with result 0
May 15 10:38:52 :305010: <INFO> |stm| AP d8:c7:c8:c8:92:4d upgrading flash image.
May 15 10:39:05 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
May 15 10:39:49 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
May 15 10:41:03 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
May 15 10:42:16 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
May 15 10:43:29 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
May 15 10:44:43 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0

We are having various levels of success by interupting the ap boot sequence and adding the serverip manually. The ap database on the controller looks like this

AP Database
-----------
Name Group AP Type IP Address Status Flags Switch IP
---- ----- ------- ---------- ------ ----- ---------
00:1a:1e:cc:a7:21 Glangwili_ap_group 61 192.168.1.117 Up 11d:23h:49m:45s 192.168.1.2
00:1a:1e:cc:a7:24 Glangwili_ap_group 61 192.168.1.126 Up 11d:23h:49m:50s 192.168.1.2
00:1a:1e:cc:a7:28 Glangwili_ap_group 61 192.168.1.119 Up 11d:23h:49m:49s 192.168.1.2
00:1a:1e:cc:a7:2e Glangwili_ap_group 61 192.168.1.116 Up 11d:23h:49m:53s 192.168.1.2
00:1a:1e:cc:a7:36 Glangwili_ap_group 61 192.168.1.118 Up 11d:23h:49m:49s 192.168.1.2
00:1a:1e:cc:a7:39 Glangwili_ap_group 61 192.168.1.121 Up 11d:23h:49m:46s 192.168.1.2
00:1a:1e:cc:a7:3c Glangwili_ap_group 61 192.168.1.123 Up 11d:23h:49m:52s 192.168.1.2
00:1a:1e:cc:a7:3d Glangwili_ap_group 61 192.168.1.114 Up 11d:13h:43m:49s 192.168.1.2
00:1a:1e:cc:a7:3f Glangwili_ap_group 61 192.168.1.115 Up 11d:23h:49m:44s 192.168.1.2
00:1a:1e:cc:a7:40 Glangwili_ap_group 61 192.168.1.124 Up 11d:23h:49m:36s 192.168.1.2
00:1a:1e:cc:a7:96 Glangwili_ap_group 61 192.168.1.120 Up 11d:23h:49m:7s 192.168.1.2
00:1a:1e:cc:a7:c0 Glangwili_ap_group 61 192.168.1.122 Up 11d:23h:49m:51s 192.168.1.2
d8:c7:c8:c8:8f:ca default 93 192.168.4.110 Down 192.168.1.2
d8:c7:c8:c8:91:88 default 93 192.168.2.111 Up 2h:57m:5s D 192.168.1.2
d8:c7:c8:c8:92:1d default 93 192.168.2.110 Up 2h:57m:6s D 192.168.1.2
d8:c7:c8:c8:92:4d default 93 192.168.4.112 Upgrading ID 192.168.1.2
d8:c7:c8:c8:92:e2 default 93 192.168.4.111 Down 192.168.1.2
d8:c7:c8:c8:92:eb Glangwili_ap_group 93 192.168.0.31 Up 1h:37m:34s 192.168.1.2
d8:c7:c8:c8:92:f0 default 93 192.168.3.112 Down 192.168.1.2
d8:c7:c8:c8:93:04 default 93 192.168.2.114 Up 2h:57m:5s D 192.168.1.2
d8:c7:c8:c8:93:9a Bronglais_ap_group 93 192.168.1.110 Down 192.168.1.2
d8:c7:c8:c8:93:a5 Glangwili_ap_group 93 192.168.0.27 Up 1h:1m:36s 192.168.1.2
d8:c7:c8:c8:96:f5 default 93 192.168.3.110 Up 18h:35m:20s D 192.168.1.2