In a large portion of the cambium network we have the symptoms of constant restarts, about 500 units in constant failure. In all cases we make a correct earthing, respecting the electrical regulations, so we can dismiss this as the source of the problem. We have updated a large portion to 3.4.1v, including subscriber modules and access points, to avoid that the origin of the reboots is some fault in the allocation of timeslots / gps, etc.
EDITED: all units are force 180(95%) and force 200 (5%) - All AP are epmp 1000 line (25%) and 2000 +SMA(75%)
I noticed that the neighbor discovery from our Mikrotiks now shows version 3.4.1 and device types like "5G Force 200 (FCC)" instead of 'linux' and the kernel version. Thanks! Much more useful that way.
I rolled out the update to four SMs on our network, two 180s and two 200s that had all exhibited reboot madness on V3.3. (we rolled out 3.3 network-wide back when, then reverted to 3.2.2 network-wide when the reboot problems' ties to 3.3 became apparent)
So far looks like two of them have made it 24 hrs with no reboots, but two have rebooted 5+ times in that same 24 hrs. No judgement, no complaint, just a preliminary observation. Right now looks like one of each radio type (testing on two of each) is back to frequent reboots.
j
PS - I also noticed that the IPv6 support still seems unable to utilize a gateway to reach anything outside the local subnet. But given that the release notes don't say that's fixed (though they don't even indicate it as a known problem either!) I wasn't too surprised by that.
Hi Joel,
Could you please investigate issue with SMs reboot in depth on your side?
Please check whether crashlog has been saved on affected devices with 3.4.1 Release.
Issue with IPv6 Gateway still persists in 3.4.1 Release and will be fixed in 3.5.
Sorry, we missed to add it to Known Issues, will do this asap.
I confirm, tried to upgrade to 3.4.1 my Force180 for testing new fw and I've got bad login... then clenaed Mozilla Firefox cache and everything worked perfectly!
Now I'm testing how it works in the next few days.
I updated four SMs on our network from 3.2.2 to 3.4.1 last week, specifically picking four that exhibited high reboot activity on 3.3 and 3.4 firmware. Two Force180 and two Force200.
The two Force180s have since rebooted four and eight times.
The two Force200s have rebooted once for one, and 32 times for the other...
Attaching crashlog from the one that rebooted 32 times. (the other three had none)
Note that we've been under assault by lightning storms the past couple weeks, so power brownout/blackout could explain several reboots. (but not 32 times)
I updated four SMs on our network from 3.2.2 to 3.4.1 last week, specifically picking four that exhibited high reboot activity on 3.3 and 3.4 firmware. Two Force180 and two Force200.
The two Force180s have since rebooted four and eight times.
The two Force200s have rebooted once for one, and 32 times for the other...
Attaching crashlog from the one that rebooted 32 times. (the other three had none)
Note that we've been under assault by lightning storms the past couple weeks, so power brownout/blackout could explain several reboots. (but not 32 times)
j
Hi Joel,
I've raised internal ticket for your reboot issue with crashlog.
I will update you as soon as we finish with investigation.
Please note that distinguishing mark for initial reboot issue in 3.3 and 3.4 Releases is reboot without crashlog. So it seems that your issue is not the same.
I updated four SMs on our network from 3.2.2 to 3.4.1 last week, specifically picking four that exhibited high reboot activity on 3.3 and 3.4 firmware. Two Force180 and two Force200.
The two Force180s have since rebooted four and eight times.
The two Force200s have rebooted once for one, and 32 times for the other...
Attaching crashlog from the one that rebooted 32 times. (the other three had none)
Note that we've been under assault by lightning storms the past couple weeks, so power brownout/blackout could explain several reboots. (but not 32 times)
j
Hi Joel,
After Call-Trace investigation we can confirm it is HW issue with your Force 200.
Please open ticket with Cambium Support to RMA this particular unit.
I have upgraded to 3.4.1 on an epmp 1000 gps sync. I have set it to specturm anyalyzer and rebooted. This is all fine. I have then set it to AP mode and rebooted. It stays in spectrum anyalyzer mode. This is not fine. Has anyone else experienced this?
The notification window says the settings were saved successfully and it now requires a reboot. The save button still says applying and will stay that way. I have tried in google chrome and firefox.
Could you please tell a bit more regarding issue you had with GPS sync?
Thank you.
I am sorry it took so long to reply. We have been having random AP's lose GPS sync. They are all on 3.3 and all using the same type of puck, the one's that come with the AP itself.
I haven't been able to find newer information but right now we have about half our AP's on internal (which is essentially useless) and we would like to get this resolved.
Before I rollout the firmware to one of the AP's for testing, I was just curious if this issue was addressed at all or if there is something else going on.
Thank you for update on this issue. For now we are not aware of any issues with GPS firmware. We had issue with GPS FW in the past with old GPS chip and first GPS FW version. But it was fixed by GPS firmware upgrade. But in case you see issue on ePMP2000 it should be something different. Do you have device we can investigate this issue on? You can contact me at fedor.trutsko(at)cambiumnetworks.com
