Wireless Access

Hi, I've tried searching around for similar issues to what I'm experiencing. (I'm kind of unsure where to start troubleshooting)

So this is the story, yesterday i went out to install a few new AP's at a customers site. My Customer got a Powerconnect W651 controller (ArubaOS 6.1.2.4 ), and somehow we had bought Aruba AP105 AP's instead of dell W-AP105. 
But since I already had the AP's I wanted to see if I could deploy them. After some trial and error it seemed that it wasnt possible at all. I Decided to call Dell support, after discussing with them I got the reply that it is possible - But I needed an firmware upgrade on the controller to later then v6.1.3.  (See AP105PreFirmware.txt for consoloutput forwarded to dell support) 

I started the upgrade right away on the secondary partition after taking needed backups. 
No problems to upgrade at all, except the known bug that its not possible to upgrade from webgui using local file. 

Here is where the interesting part begin.. 
When the controller boots up with 6.2 or 6.3 the AP105 starts to register and downloads firmwares/configurations etc. 
But it seems that after it has downloaded the new version it get stucks in a reboot cycle, and just to make it worse - All AP's starts to act like this.  
AP105 - downloads configuration and firmware etc correctly. (Missing console output for this)
W-AP105 doesnt seem to download correctly (After investigating the W-AP105's I do see following error until first reboot, asap_gre_ipv4_err: Received ICMP (DEST_UNREACH, PROT_UNREACH) from Controller-IPADDRESS for heartbeat tunnel.) 

All AP's are reachable by ping and appears to be working, but after being online for 30-60 sec they reboot again. 
Its not possible to remotly demand any logs thru the webgui on the controller anymore either, SAPM Client Busy. 
(See W-AP105Afterfirmware for consoloutput on the older w-ap105 after firmware)

Some misc info, 
1 -The customer has 8 W-AP105 and a Powerconnect W651 controller. 
2 - When downgrading the controller back to 6.1 issue disapear. (But the original issue was that the newer AP's require newer firmware, back to step one. ) 
3 - Tested different provision methods. (The AP's can reach the controllers by using subnet(Same VLAN and subnet as controller), dns and dhcp)
4 - Tested disabling CPSec ( per default the AP's are whitelisted and using auto-generated certificates)
5 - A lot of gui functions break when upgrading to 6.2+, getting lots of SAPM Client Busy.  (Dell issue I assume) 

Removed and replaced some info in the .txt attachments
CustomID = customername 
MACADDRESS = correct mac address
IPADDRESS = correct IP ADDRESS

Regards
Mattias Ljungqvist

Attachment(s)

W-AP105Afterfirmware.txt   5 KB 1 version

AP105PreFirmware.txt   2 KB 1 version

Okay, so I don't have to tell you that this is unsupported and you should probably send the access points back.?

Getting beyond that, you should try to uncheck control plane security and see if they come up.  That message just looks like the access point cannot reach the controller.  Removing control plane security will remove the requirement that the access point use ipsec, so it could work.

We do not do testing with different access points and controllers, so there is the strong potential that there are compatibility issues that will never be dealt with. 

Hi, thanks for the reply! I do know that its unsupported, but i can't return the access points... "Not refundable" :) 

I will try that out later on today, I think I solved a similar issue by turning on the CSP in the pre-upgraded firmware. 

Thanks again
Regards
//M

It did not work :( 

They are all on the same subnet

Do you get the same error on the console of the access point?

What does "show log system 50" on the controller say?

Have no console access at the moment. 

But following from controller

Oct 3 12:17:16 KERNEL: 0:<6>hso: drivers/usb/serial/hso.c: 1.2 Option Wireless
Oct 3 12:17:16 KERNEL: 0:<6>hso: Registering procfs
Oct 3 12:17:17 KERNEL: 1:<4>process `trapd' is using obsolete setsockopt SO_BSDCOMPAT
Oct 3 12:17:19 :399803: <ERRS> |msghh| An internal system error has occurred at file msghh.c function msghh_papi_rcv_cb line 79 error Unexpected m
essage from 127.0.0.1:8405 code 0.
Oct 3 12:17:21 :399803: <ERRS> |msghh| An internal system error has occurred at file msghh.c function msghh_papi_rcv_cb line 79 error Unexpected m
essage from 127.0.0.1:8405 code 0.
Oct 3 12:17:21 :306510: <WARN> |publisher| Dropping message from 8214 for service '51 (service not found)'
Oct 3 12:17:21 :399803: <ERRS> |msghh| An internal system error has occurred at file msghh.c function msghh_papi_rcv_cb line 79 error Unexpected m
essage from 127.0.0.1:8405 code 0.
Oct 3 12:17:21 :306510: <WARN> |publisher| Dropping message from 8214 for service '51 (service not found)'
Oct 3 12:17:21 :399803: <ERRS> |msghh| An internal system error has occurred at file msghh.c function msghh_papi_rcv_cb line 79 error Unexpected m
essage from 127.0.0.1:8405 code 0.
Oct 3 12:17:21 :325022: <ERRS> |authmgr| Bogus VLAN ID:4095 received.
Oct 3 12:17:21 :399803: <ERRS> |msghh| An internal system error has occurred at file msghh.c function msghh_papi_rcv_cb line 79 error Unexpected m
essage from 127.0.0.1:8405 code 0.

And this for each AP
Oct 3 12:17:22 :311020: <ERRS> |AP MACADDRESS@AP-IPADDRESS sapd| An internal system error has occurred at file sapd_redun.c function redun_
retry_tunnel line 4441 error redun_retry_tunnel: Switching to clear. Error:RC_ERROR_IKE_XAUTH_AUTHORIZATION_FAILED. Ipsec not successful after reboo
t.