FYI
2025.06.30 14:24:10 -05:00 5GAXRSNW creporter: Crash has occurred on device. Information about the crash is transferred to a server of bugsplat.com and stored there for evaluation.
Hi @Riverrat,
could you drop me a techsupport file from this radio?
Thank you!
we are seeing the same on 5.10.1-rc16 on two of the three 4500 APs we just put up. Already opened a ticket. One of the APs reboots every hour or so, the other one only did it once over a few days. No cable issues for either one. Hopefully this can be resolved in the software.
About to try rolling the AP back to 5.10 just to see if it stops the behavior.
We’re experiencing crashes on 5.10.1 beta’s & 4500L’s as well… we rolled back to 5.10 and have not had any issues. We’ve worked extensively with the ePMP dev’s on tracking the issue, but no fix yet.
Yeah, just had a crash on a 4600C PTP crash. We have found 5.9.1 to be the most stable on PTP, so rolling back to that on our PTP. Have a 4600C PTP link been running 110 days without a blip on 5.9.;1
2025.07.03 13:45:29 -05:00 AW6GRSHTSL creporter: Crash has occurred on device. Information about the crash is transferred to a server of bugsplat.com and stored there for evaluation.
I’m curious about today’s release of 5.10.1 STABLE when yesterday there were unresolved and unknown crashes? I’m currently on 5.10.1-RC16 on our 4500’s and no major crash issues, but I’m also not graphing the modulations yet, so it may be worse than RC14 was, and I just don’t notice it.
Anyway, I’m just curious on everyone’s take on STABLE when there seems to be well reported and unknown crashes and worse performance?
I brought this up with them, but was told that they need a lot more data in order to figure out what was causing the crashes and that they didn’t want that to hold up 5.10.1 release.
2 Likes
Interesting. We put up 3 new 4500s replacing 3000 sectors, and all 3 of them experienced crashes at varying frequencies. Cambium gave us a patch for 5.10.1-rc14, so we downgraded to that from rc16. That seemed to fix the crashes on 2 of the APs, but the third one continued to crash. Our customers were getting pissed off at that point, so we put up the original 3000 AP to replace the 4500 that was crashing a ton still.
They are reviewing the latest TSF we sent them after it crashed on the new patch of rc14
Dang, we tried rolling back to 5.10 as well and there was no change.
Are you using any of the following settings on the 4500L that’s rebooting:
- BC or Migration mode
- a 65/35 TDD duty cycle
- Long guard interval
Migration mode, with tons of f200s/300s. The AP that was rebooting constantly had 28 I believe.
Notably the other two that were rebooting far less frequently had 40ish f200s/f300s, so it doesnt look like its a factor of how many are connected. But I was leaning towards Migration mode being the issue all along as soon as we confirmed the AP itself was crashing.
Unfortunately our only resolution was to put the old AP back up. Way too many SMs to forklift to 4525.
1 Like
Negative to long guard interval or 65/35
Also! I didnt specify this before, but our units are all 4500 integrated, not the Lite units.
We have an issue on RC 14 where the f300/f200 stays connected to the 4500, but the f4525L keeps on disconnecting. They then do not connect at all until we reboot the AP 4500 then they connect again.
Had the same issue on 5.10.0, hoping that 5.10.1 solves the issue
We are trying 5.10.1 on a single 4500L with all 4525 SMs and on a 4600C PTP Link. We have a full 4600 that has been running 35 days on RC14 with no issues. We are getting ready to deploy a 4600L and will try 5.10.1 on it as well.
1 Like