cancel
Showing results for 
Search instead for 
Did you mean: 

Troubleshooting a failed / disconnecting AP

Troubleshooting a failed / disconnecting AP

Steve_Ballantyn
Contributor
I have a site with an AP that has disconnected several times now, seemingly randomly (it's happened after hours, with zero client connections). Since it's offline I am not able to pull a trace log using the EWC console. I have had the folks at the site go and reboot the access point to get it back online. They have reported that when it's in this state, there is a single amber light (pretty much like when power is first applied).

Is there anything I can do in the way of troubleshooting a failed and rebooted AP? Is there any sort of memory dump that would survive a reboot? I noticed that there is a /tmp/log/ap.logLastReboot.gz file. But if I gzip -d the file, and cat the ap.logLastReboot file, all it says is "---WARNING: ap-log is not valid (size 2298819153, tail 2261266449)".

This may be indicative of a completely different problem or bug.

For the time being I have ssh'd into the AP and run:
cset sshtimeout 0
capply
csave
tail -f /tmp/log/ap.logAnd now I am just waiting for it to fail again and hoping that it dumps something to the ssh session before it bombs out. Although I suspect this is all over a flaky cable-modem connection that's occasionally dropping packets.

Anyone have other ideas? 🙂

Relevant details:
My AP is a 3825i, and I am running with version 10.11.02.0032.
6 REPLIES 6

Hrm ... I hadn't even thought about the PoE. I am powering the AP off of one of the two PoE ports on a Cisco ASA 5505. The other PoE port is powering a phone. I don't know that there is any good reporting on that device for power utilization, but perhaps it's just getting drained.

I will see about getting an inline PoE in place to see if it improves connectivity.

Thanks for the feedback!

Ronald_Dvorak
Honored Contributor
Looks like you've done all the right things...

I've not even once tried to tx a file from the AP via CLI  so no idea about that part.

To collect the ap.log is the right approach in my opinion but you haven't mentioned whether you'd reach the AP via IP in that state (if not the ssh session will disconnect).
In case you loose the link in that state make sure that the onsite guys do a cat ap.log via console before they restart the AP so you've more data.

Is the controller address set static on the AP or learned via DHCP option.
GTM-P2G8KFN