Wireless Access

We are currently experiencing an issue with some of our AP-125's where, after about 10-15 minutes of uptime, they reboot.  I've read several other posts that appear to be related and when i try to issue the "show ap debug system-status ap-name <ap name>" on the APs that are rebooting i get the following error message:

 

     Device did not respond, please make sure the AM or AP IP is valid by issuing 'show ap bss-table'

 

I check the bss-table and it shows up there as a valid AP.  I get the same error message when i search by ap-name, ip-addr or bssid.  When i run the same command against APs that are functioning 'normally' and have been up for weeks, i recieve the expected output.  Has anyone else experienced this issue?

 

-Eric

 

 PS. As info, i am running 6.1.3.8

eric.miller,

 

When access points reboot, when they come up, they send a syslog to the controller they connect to, as to why they rebooted.  On the commandline of that controller try:

 

show log system all | include <name of access point>

 

That will give you a starting point.

Thanks for the quick response.  This is the output i get when I run that command (truncated of course because the log is flooded with these messages)  (See attached)

 

Mar 28 10:07:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 93 type 3096
Mar 28 10:07:55 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 93 type 3096
Mar 28 10:09:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 93 type 3096
Mar 28 10:10:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 171 type 3096
Mar 28 10:10:55 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 171 type 3096
Mar 28 10:12:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 171 type 3096
Mar 28 10:14:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 171 type 3096
Mar 28 10:16:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 249 type 3096
Mar 28 10:17:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 249 type 3096
Mar 28 10:19:03 :304035:  <ERRS> |AP <ap-name> stm|  PAPI_Send failed: 145; from 8451 to 10.204.236.4:8214 len 249 type 3096
Mar 28 10:19:18 :311002:  <WARN> |AP <ap-name> sapd|  Rebooting: SAPD: Unable to contact switch. Called by sapd_keepalive_cb:5743.  HBT miss seq_gen=19 seq_snt=10 seq_rcv=10 851 sec before: Last Ctrl message: KEEPALIVE len=25 dest=10.204.236.4 tries=10 seq=3

Okay.  It seems like it comes up, finds A controller, but might be getting redirected to a controller that does not exist.  If you go to Configuration> AP Configuration> Edit the AP Group that the AP is in and look at AP> System Profile and Look at the LMS IP, what ip address should the access point be trying to reach and is that a valid controller....

Eric,
It may be a pain, but do you have the ability to connect to the console port of the AP in question. If you can pull logs from it during the reboot cycle this might assist in determining the root cause. I know that this information has been key when airwave wasn't able to assist me in the past.

When I've had that issue, the problem was related to DHCP. There were two fixes that worked for me.

 

1) configure an option 43 on the dhcp scope/server to point to the IP address of the controller

 

2) set up a DNS A-record that points to "aruba-master" in your DNS server

 

I hope that helps.

---

@NashvilleJames wrote:

When I've had that issue, the problem was related to DHCP. There were two fixes that worked for me.

 

1) configure an option 43 on the dhcp scope/server to point to the IP address of the controller

 

2) set up a DNS A-record that points to "aruba-master" in your DNS server

 

I hope that helps.

---

NashvilleJames,

 

When you had your problem was your access point unable to find any controller?  According to eric.miller's logs, the access point is finding the first controller so he must have either 1 or 2 configured already.  His problem looks like what happens after it is found...

 

That's right... the AP successfully finds it's controller, and even accepts client connections for about 10-15 minutes, then it just reboots.

When I had the problem, the APs found the controller and I had enough time to provision them. Then they would reboot every 10-15 minutes. For my situation, the Option 43 or the DNS record fixed the problem.

is it possible that you have a duplicate IP address (either static or duplicate DHCP Server) on your network?

 

try running a continuous ping to the IP of the access points and if it continues to respond when its rebooting then maybe there is another device on the network that is causing a conflict.

 

Scott

trying to ping the AP know, but it's not responding, even though it shows on the controller it's been up for 5+ mins

We had a weird issue with DHCP on the 6.1 code stream.  Just for the sake of elimination, check the IP the AP should have then check your DHCP server to make sure DHCP has that same AP listed as having that IP.  Our APs were not renewing the leases and it caused all kinds of problems for us.

 

6.3.1.3 seems to have corrected that issue for us.

We are currently using 135's, 175's, 105's and 125's.  This issue seems to only be present on the 125's.  

Is this happening to all access points in an area or on a particular switch? Any way to see the pie being provided by that switch?