Good afternoon, dear friends.
I have several dozen links to the F-300. And some of them reboot at any time, several times a day. Here I found similar problems, but they date back to 2018 and I have not seen a solution there. It’s 2023, but the problem remains. The problem was manifested both on 4.3.1 and on the last 4.7.0.1
Surprisingly, the link limit of 100 mbps helps. In this case, the line works more stably.
I ask for help from the respected community.
Physically, everything has already been changed several times.
P S Such a problem is not observed with devices of the F 300-25L family
Thank you, I already sewed one line for this firmware. I observe her behavior. And yet I am surprised at such a problem. It has been known since 2018 and so far the manufacturer has not decided it and so little information on it.
I stitched several links to RC22. The firmware behaves more stable, but on one link the old problem of reconnections in the EPMP master mode was noticed.
Tell me what it means
Dec 5 11:27:58 - creporterd: kernel process_crash… get_crash_data fail : -1
Dec 5 11:07:58 - creporterd: kernel process_crash… get_crash_data fail : -1
The message can be seen in the log when the remote crash reporting is disabled.
It will be fixed in the upcoming releases.
No impact on stability or performance.
The new firmware does not help, the devices still reboot randomly.
Spectrum analyzer is disabled.
Friends from Cambium, please comment on what to do next?
100% helps to set the link to 100 Mbit/s
Do not know why inactive affected it but it sure did. Also, you may have to disable QoS on a per affected device basis. We lost customers due to this issue. Took us a week to stabilze and these were the steps that stabilized it for us.
We were experiencing the issue on multiple APs including MP3000 and on multiple SMs including 300-325, 300-19, 300-19r & 300-16. We also had the issue on both PtP and PtMP links.
Some of the clients were even reporting out of memory and would not perform web interface firmware updates regardless of direction and reboots though they would through cnMaestro.
Wish I could answer all your questions but can only offer what worked for us. After the headache and subscriber loss pain we are just relieved to have found a working combination. Maybe these steps will work for you as well.
Thank you very much for your response. The only solution that definitely helps against reboots is limiting the link to 100 Mbit/s.
All additional functions on the radio are turned off, we don’t even use SnMaestro. The radio works like a transparent bridge. Even encryption is turned off.
We will continue to monitor and update information here.
So friends! Let me summarize my research on solving problems with rolling reboots of Cambium devices
Firstly, as colleagues advised above, you really need the RC22 firmware to be not only active, but also not active in the bank. At least for now, this seems to be an effective way to combat reboots.
2 It also helps to limit the link to 100 Mbit/s to Ethernet. This helps even on older firmwares
3 Unfortunately, I myself have never used additional functionality such as DPI or QOS, but they should also be disabled. Also, judging by the observations of colleagues, it is better to disconnect the Spectrum analyzer.
It seems to me that here I have collected all the recommendations that I have seen and tried.
What version is the hardware? Not the firmware on it but the actual hardware version? There is a known issue with the late first revision and early second revision f300-25 radios that causes random reboots/power loss. They are very susceptible to power flickers (fast brownouts).
Limiting the ethernet link speed to 10HD or 100HD and disabling smart speed does help a lot. This lowers the demand on the radio.
Our solution since we only had a few of the affected radios was to replace them. If your radio is still under warranty (2yrs from the date you bought it) then RMA it. Yes ypu have to go through the RMA test this BS, so replace the radio at the customer and place it on the test bench.
The serial number and the mac address will give you a strong clue as to which version you have.
There are several posts on the epmp forum that deal with this directly.
