cambiumFullCfgRestore on ePMP v2.0

I try to restore a .bin config backup with :
snmpset -v2c -cprivate . s

and cambiumFullCfgRestoreError.0 indicates "Downloading file error"

But cambiumJSONCfgImport works as expected with :
snmpset -v2c -cprivate . s

And manual (via webUI) updating using the same .bin file works.

PC local ethernet to defaulted SM.


Joel - The full config restore should work. The only reason we can think of is that the PC connected to your radio lost connectivity during this procedure. Can you please open a support ticket with our support engineers so they can take a look?

Did you ever get a solution to this issue?  We are using 3.0.1 and have a nearly identical problem.  However, in our case if we watch the cambiumFullCfgRestoreStatus variable we will see the download take place, then unpacking and then get a "Unpacking files error".  However, as with you if we take that exact same bin file and simply apply it to the radio using the UI it works fine.

Hi Larry,

I would be really grateful if you could try it with last beta release 3.1-RC24.
I will check your case with 3.0.1 and will be back.

Thank you.

1 Like

This did indeed work properly in the 3.1-RC24 firmware.  Estimates on when 3.1 will be going live?

Thank you, Larry.

3.1 will be delivered in several weeks.

Thank you.

Any chance for a 3.0.2 that fixes this in the meantime.  Not a big fan of running beta/RC on producion systems.  Thanks!

Larry, we are doing our best to deliver release as soon as possible.

Sorry for inconveniences and thank you for you feedback.

Thank you. is the thread regarding this problem with 3.0.1 - For our purposes I wasn't too inconvenienced by this (yes, I started both threads) - the only time I typically push config file via SNMP is when defaulting newly-arrived units after updating them.  So I just altered my script to update them AFTER pushing the config, and we've survived the problem with little impact.  I realize that won't suffice for some, but a few weeks ago Cambium acknowledged the problem and have already fixed it, just awaiting final 3.1 release.


Missed that thread, but yes it works as expected in the 3.1-RCxx versions as you noted.  We could change the automated radio setup script to push that first as well pretty easily, appreciate the idea.