CBW150AX rebooting itself - Page 2

classerased · ‎02-06-2023

I have a single CBW150 access point powered via PoE from an SG250-08HP that keeps restarting itself about once a day, sometimes every other day.

I have only had this device installed since Christmas and it was fine for a while, the logs don't really provide me any insight into what is causing it to fall-over, other than some messages that I can't work out how to act on, nor does google find results. My biggest suspect is power of some kind, but the switch doesn't have any logs to suggest there's an issue with the PoE. Nor is it overloaded with just a VoIP phone and the aforementioned AP. Or maybe I've misconfigured something?

*spamApTask0: Feb 06 16:25:03.118: %APF-4-MOBILESTATION_NOT_FOUND: apf_api.c:57860 Could not find the mobile 5c:60:ba:94:58:ae in internal database
*apfReceiveTask: Feb 06 16:25:00.963: %APF-5-CLIENT_RUN_STATE: apf_foreignap.c:2253 Client Associated: Assigning Ip Address: (192.168.1.19) to Client MAC: a8:51:ab:92:d0:60.
*apfMsConnTask_0: Feb 06 16:25:00.810: %APF-5-CLIENT_ASSOCIATE: apf_80211.c:13601 Client Association: Client MAC: a8:51:ab:92:d0:60, AP Name: AP34B8.8347.98A8, Radio: 5 GHz , WLAN Id: 1.
*Dot1x_NW_MsgTask_0: Feb 06 16:24:43.080: %APF-5-CLIENT_DEAUTHENTICATE: apf_80211.c:4071 Client Deauthenticated: Client MAC: 5c:60:ba:94:58:ae, Ip Address: (0.0.0.0), AP Name: AP34B8.8347.98A8, Radio: 5 GHz , WLAN Id: 1, Reason: 15.
*Dot1x_NW_MsgTask_0: Feb 06 16:24:43.080: %DOT1X-4-MAX_EAPOL_KEY_RETRANS: 1x_ptsm.c:558 Max EAPOL-key M1 retransmissions exceeded for client 5c:60:ba:94:58:ae
*apfReceiveTask: Feb 06 16:24:40.489: %APF-5-CLIENT_RUN_STATE: apf_foreignap.c:2253 Client Associated: Assigning Ip Address: (192.168.1.25) to Client MAC: 7a:0f:6b:28:85:b6.
*apfReceiveTask: Feb 06 16:24:40.368: %APF-5-CLIENT_RUN_STATE: apf_foreignap.c:2253 Client Associated: Assigning Ip Address: (192.168.1.7) to Client MAC: 1c:fe:2b:48:51:4f.
*apfMsConnTask_0: Feb 06 16:24:39.984: %APF-5-CLIENT_ASSOCIATE: apf_80211.c:13601 Client Association: Client MAC: 1c:fe:2b:48:51:4f, AP Name: AP34B8.8347.98A8, Radio: 5 GHz , WLAN Id: 1.
*apfMsConnTask_0: Feb 06 16:24:38.541: %APF-5-CLIENT_ASSOCIATE: apf_80211.c:13601 Client Association: Client MAC: 7a:0f:6b:28:85:b6, AP Name: AP34B8.8347.98A8, Radio: 5 GHz , WLAN Id: 1.
*apfMsConnTask_0: Feb 06 16:24:37.759: %APF-5-CLIENT_ASSOCIATE: apf_80211.c:13601 Client Association: Client MAC: 5c:60:ba:94:58:ae, AP Name: AP34B8.8347.98A8, Radio: 5 GHz , WLAN Id: 1.
*spamApTask0: Feb 06 16:24:24.585: %HREAP-3-HREAP_XML_FILE_SIZE: hreap_cfg.c:509 Hreap XML file size is: 30144 bytes.
*spamApTask0: Feb 06 16:24:21.164: %CAPWAP-5-AP_JOINED_SAVECONFIG: capwap_ac_sm.c:4654  Saving the entire configuration after an AP joins. 
*spamApTask0: Feb 06 16:24:21.162: %LWAPP-3-AP_LOCK_ERR: spam_api.c:1346 The system could not obtain exclusive access to AP 34:b8:83:44:53:40 in the database
*fp_main_task: Feb 05 21:04:30.495: %CBW-3-CBD_PROVISIONING: cnfgr.c:3403 Trustpoint file is not found in CBW
*fp_main_task: Feb 05 21:04:24.397: %SSHPM-2-BAD_DEVICE_ID_CERT: sshpmcert.c:8260 Failed to retrieve MAC address from bsnOldDefaultIdCert certificate
*fp_main_task: Feb 05 21:04:24.380: %APF-4-WLANEXPIRY_TIMERSET_FAILED: apf_vap.c:3264 Unable to set timer for WLAN PSK password. unable to lock account

Edit: I changed the setting of the access point to preffered primary, will see how that does.

Georg Pauwen · ‎05-27-2024

Bonjour Gregory, trois jours semblent effectivement prometteurs. Je n'ai encore entamé aucune procédure RMA, je me suis seulement renseigné sur le processus...

dropshadow · ‎09-26-2024

did you ever figure out what this issue was? i have the exact same error logs with random rebooting.

gregory-no · ‎09-30-2024

Hi @dropshadow !

My APs ar now fixed. They are stable for weeks now and not rebooting for any reason anymore.
Not sure about the error logs you are talking about, but here's the two things i did:

- Remove the antic Cisco SG300 and replace by a Netgear Prosafe POE+

- Noticed that one of the AP switch from 1Gbs to 100Mbs. It was a wire issue. As soon as I fixed (on of the wire of a pair was not in contact), the things goes well!

I think that the AP plugged on bad wire was the primary of the cluster. As soons as it switch to 100Mb/s a reelection occured.

From what I understood, reelection implied rebooting (but I could not find doc mentionning that behavior).

Now as long the the primary stable, so is the cluster 🥳