cambiumFullCfgRestore on ePMP v2.0

I try to restore a .bin config backup with :
snmpset -v2c -cprivate 10.1.1.254 .1.3.6.1.4.1.17713.21.6.4.20.0 s http://10.1.1.3/ePMP-backup.bin

and cambiumFullCfgRestoreError.0 indicates "Downloading file error"

But cambiumJSONCfgImport works as expected with :
snmpset -v2c -cprivate 10.1.1.254 .1.3.6.1.4.1.17713.21.6.4.1.0 s http://10.1.1.3/ePMP-backup.json

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

PC local ethernet to defaulted SM.

j

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.

http://community.cambiumnetworks.com/t5/ePMP-2000-and-1000/SNMP-triggered-binary-config-load-fails-3-0-1/td-p/60050 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.

j

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.  

Thanks!