I’ve been have a lot of issues and the Event log is loaded with the following:
What does a “Resetting due to fatal VC clear error” mean? A possible hardware failure?
System Startup
System Reset Exception – Reset by application
Software Version : CANOPY 24.0.1 AP
Board Type : P13
Device Setting : 5.7GHz MIMO OFDM - Access Point - 0a-00-3e-bd-13-d3 - 5760.0 MHz - 20.0 MHz - 1/16 - CC 14 - 2.5 ms - North America/United States
FPGA Version : 041624;
10/21/2024 : 01:09:11 CST : :Board Temperature: 21 C / 69 F
10/21/2024 : 03:45:05 CST : :Stuck Session: Data (LUID 2) (1)
10/21/2024 : 03:45:05 CST : :Resetting due to fatal VC clear error VC=18 W1=0x27e712a0 Cmd=0x27e712a0
10/21/2024 : 03:45:05 CST : :Forced reset;
10/21/2024 : 03:45:05 CST :
Did you get a good answer another way than this forum at least already? My inclination without more information would be a likely software problem. I don’t remember ever seeing that particular error but it seems likely a call to a software function related to “clearing” a VC produced an error that other logic interpreted that as requiring a reboot. That could be caused by a hardware problem or it could be being caused by other things. I don’t see anything obvious that 24.1 would be fixing a known problem assuming all the SM units and the AP are on 24.0.1. Cambium Networks in their release notes seems to bring forward known problems and issues for not yet solved things and that is helpful because you don’t have to dig through old release notes for a prior issue not listed still as a known problem in recent release notes. You probably already read the release notes, I skimmed them for 24.0.1 and 24.1 and didn’t notice anything obvious related to this error. If you are experiencing errors in your logs that may indicate unique hacking attempts on your network you do need to keep in mind at least from my experience that replacing a network device creates a situation where a hacker can lay dormant making it appear as if it was a hardware problem. The logic is simple from the hacker perspective I assume. I’m not a hacker allegedly ethical or not FYI. If the hacker or their group gains access and symptoms of access are noticed create more obvious symptoms that could be interpreted as hardware failures until equipment is replaced, then lay dormant before more serious investigations into the situation might occur. I hope that isn’t happening but it’s wise to consider it as possible.
Thanks for the response. I didn’t realize there was a firmware update from what I was running. I upgraded the link to 24.1. I noticed there was a fix for a Stuck Session issue. The radio then started rebooting due to “Recover Stalled Radio”. As a test, I downgraded the link to 22.1.2 and there has been no reboots for over 24 hours. With the 24 version firmware it would reboot every hour or so. It appears that the radio does not like a 24 version firmware. I wonder if anyone else is having the same issue?