Re: SPA112 can not restore konfiguration on firmware 1.4.1 SR3 - Page 2

Ralf_H · ‎06-22-2019

My englisch ist not so good. So i keep it simpel.
Problemw with SPA112: Only with firmware 1.4.1 SR3 i can't restore a backuped configuration.
With 1.4.1 or 1.4.1 SR1 it work perfektly.
With 1.4.1 SR3 it schowen everytime "Restore has failed".

Hier my teststeps:
[Version in SPA112] [Teststep]
1.4.1 SR1
1.4.1 SR1 Backup OK (SR1-Backup File: SPA112_1.4.1SR1.cfg)

1.4.1 SR1 Update 1.4.1 SR3 OK "Upgrade is successful"
1.4.1 SR3 Reboot
1.4.1 SR3 Backup OK (SR3-Backup File: SPA112_1.4.1.cfg)
1.4.1 SR3 Restore the SR3-Backup "Restore has failed"

1.4.1 SR3 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR3 Restore the SR3-Backup "Restore has failed" (Only all configurations under "Voice" not restored)

1.4.1 SR3 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR3 Restore the SR1-Backup "Restore has failed" (Only all configurations under "Voice" not restored)

1.4.1 SR3 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR3 Backup OK (File: SPA112_1.4.1.cfg)
1.4.1 SR3 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR3 Restore the Backup "Restore has failed" (Restore from the Backup of the Factorydefault failed!)

1.4.1 SR3 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR3 Downdate 1.4.1 SR1 OK "Upgrade is successful"
1.4.1 SR1 Reboot
1.4.1 SR1 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR1 Restore the SR1-Backup OK "Restore is successful" (All configurations restored)

1.4.1 SR1 RESET with ResetButton (more the 20Sek / Full factorydefault)
1.4.1 SR1 Restore the SR3-Backup OK "Restore is successful" (All configurations restored)

In Firmwar 1.4.1 SR3 the restore of a configuration always showen "has failed" and restore not the configuration under "Voice".
All backuped confikurations in 1.4.1 SR3 can in 1.4.1 SR1 (or 1.4.1) sucsesfully restored.
So there ist only way to restore in 1.4.1 SR3 the configuration. Downgrade to 1.4.1 SR1, Factorydefault, Restore configuration, Upgrade to 1.4.1 SR3.
But i think it's a not good solution.

I hope somwer can help me.

Dan Lukes · ‎08-16-2019

Sorry, spacfg.xml is name for SPA3xx/SPA5xx devices. For SPA1xx/SPA2xx the config.xml needs to be used instead.

See SPA ATA: Saving Configuration for Analysis Using admin/config.xml for details.

I prefer XML form of configuration because

1. configuration saved by Save function is in proprietary binary format. You can do nothing with it but load - and even this may not work.

2. XML can be generated by a custom tool or edited in plain text editor

I will not claim it "good practice" - I just consider it better.

why do you advise not using SPC to convert an existing .cfg file to xml

Note that cfg produced by "Save" is not the same as text cfg suitable to be used by SPC. Those are completely different beasts. The first one is proprietary binary blob, the second is text file (but different format than XML). It's why you can't compile saved CFG by SPC.

I'm unsure the SPC can convert CFG (text CFG created for SPC, not the [Save]d one) to XML. I'm not using SPC at all, so I don't know what features has been added into it in the mean time.

But even if it can convert, I have no reason to do it. Plain text CFG for SPC and XML are bot text files. Both are readable by naked eye, both can be edited by text editor or generated by simple custom tool. But text CFG for SPC needs to be compiled while plain text XML can be used as is. The first one require external binary program, while the second method require nothing.

May be better question is - why I should use SPC for anything ...

David30 · ‎08-16-2019

Ahh, <IPaddress/admin/config.xml> works fine, though how to access it without using the http://userid:password@... syntax (which leaves the admin credentials lying around in browser history and doesn't work anyway) isn't immediately obvious.

An attempt to use SPC to compile an existing, working XML configuration, just out of curiosity, resulted in 28 “unrecognised parameter names”.

I'll probably maintain the XML configuration now as you suggest. It isn't as user-friendly as the interactive utility, but it does allow the differences between two files to be spotted easily using a text-compare utility. Maybe an associated style would help?

Thanks for your assistance.

Dan Lukes · ‎08-24-2019

attempt to use SPC to compile ... resulted in 28 “unrecognised parameter names”.

Did you downloaded the latest SPC compiler (just blind shot, I'm not using SPC) ?

how to access it without using the http://userid:password@... syntax (which leaves the admin credentials lying around in browser history and doesn't work anyway) isn't immediately obvious.

It works for me, but it may be matter of browser used. Also, my browser doesn't save passwords in history. Moreover, it's one-time step. Once configuration gets saved, you need no to access the URL again. But it's not main security issue you have.

SPAxxx devices are NOT designed to be exposed in unfriendly environment. They lacks countermeasures against DoS, brutal-force style of password guessing and there in the past severe security bugs has been discovered including those allowing unauthorized access to the device. So you are in risk of tool fraud and it may be costly experience.

You should keep phone network separated from regular network, so regular users have no access to SPAxxx devices at all. Of course, overall security design of your network depends on local conditions, risks you wish to avoid and - of course - budget and skills you have ...

We have phone network in separate LAN with no connection outside, so no one can arrange DoS against them nor misuse a firmware vulnerability. Devices can speak with local PBX only (just free Asterisk) and PBX can access outside. Configuration are loaded from server via HTTPS protocol, SPAxxx authorizes self to server by in-device embedded certificate - so even if someone connects computer to phone network, he have no chance to fetch configuration of a phone (e.g. passwords stored in configuration can't be compromised) - it in turn mean he can't connect to PBX, so he can't make unauthorized calls (and possible tool fraud).

Oniiz86 · ‎11-14-2019

I believe this issue persists with the recent November 1.4.1 SR5 release, I tried to restore my SPA112_1.3.5.cfg file & it returns the same "Restore Failed" error, seems strange that they chose not to rectify it after it's been a well documented bug since the April 2019 release of 1.4.1 SR3.

Dan Lukes · ‎11-14-2019

You can restore backup from same version only. If it doesn't work, then bug is still here.

Don't restore backup created with different firmware version. It's not bug if it fails.

Oniiz86 · ‎11-14-2019

I didn't realise that, thanks for letting me know, I saved a backup file with the new SR5 release and tried to restore it but the issue is still present & returns a "Restore failed" error, it's a shame they couldn't manage the time to rectify it as I guess it isn't a priority but I believe Cisco support are aware of it, is there a way to notify them that this bug is still not fixed?

Dan Lukes · ‎11-14-2019

While you may wait for Cisco, my experience claim it so risky. Don't depend on backup/restore feature. Learn how provision phone from XML configuration file. Such file allows you to restore phone configuration from file anytime, even on different firmware version (and with some restrictions, even on different model).

David30 · ‎11-14-2019

@Dan Lukes wrote:
Learn how provision phone from XML configuration file. Such file allows you to restore phone configuration from file anytime, even on different firmware version (and with some restrictions, even on different model).

I'll support that. The differences between two XML configurations can also be instantly identified using an appropriate utility (even Windows-7 has a rather basic CLI command for differencing text files).

However it took me a while to discover a process which works; one of the options in the book didn't work for me. You'll need to install the 'curl' utility on the system used to download an existing XML configuration or upload a new one; curl is standard on Linux and there's a version for Windows.

More details are available if you need help...

Dan Lukes · ‎11-14-2019

You'll need to install the 'curl' utility on the system used to download an existing XML configuration

You have configuration in the file already. You provisioned phone from such file.

What's the reason to fetch it ? Assuming you didn't deleted the file by accident (but you have backup of all of important files, isn't it ?)

or upload a new one

Phone download's file from a server. What's the role of curl here ?

David30 · ‎11-14-2019

@Dan Lukes wrote:
You'll need to install the 'curl' utility on the system used to download an existing XML configuration
You have configuration in the file already. You provisioned phone from such file. What's the reason to fetch it? Phone download's file from a server. What's the role of curl here ?

Oniiz86 had a problem uploading the binary version (.cfg) of a configuration file. The provisioning system is designed for environments containing many ATAs, and I think it's inappropriate for users who may only have one or two devices.

However page-36 of the Provisioning Guide mentions the use of curl under "Direct HTTP Post using cURL" and it's a much better solution for those maintaining only one or a few devices.

DavidL

Dan Lukes · ‎11-14-2019

it's a much better solution for those maintaining only one or a few devices.

I strongly disagree with "much" word you used and even without it I have different opinion. Despite of it, you described plausible method which may help and I missed it. Thanks.

I'm not using it because I consider it "unstable". It works for some combinations of SPA models and firmware versions while it doesn't works for others. Also, it's subject of another pending firmware bug CSCud52670

David30 · ‎11-15-2019

@Dan Lukes wrote:
I strongly disagree with "much" word you used and even without it I have different opinion. Despite of it, you described plausible method which may help and I missed it. Thanks.
I'm not using it because I consider it "unstable". It works for some combinations of SPA models and firmware versions while it doesn't works for others. Also, it's subject of another pending firmware bug CSCud52670

Thanks...

I've used the curl method using both Windows and Linux and with all (SR1,SR3,SR4,SR5) versions of SPA1x2 firmware and so far, so good.

Oniiz86 is beginning with a .cfg configuration file. Its XML version can be downloaded by (1) logging into the admin account of an SPA device and then (2) executing the curl command:

http://<SPA-IP-addr>/admin/config.xml

before the browser session times out. curl uses HTTP so it just "looks like" another browser command. Files can be uploaded with:

curl  -d  @/<path>config.xml  "http://<SPA-IP-addr>/admin/config.xml"

Completely replacing the old binary configuration-file system with XML seems pretty straightforward from this distance, after all most of the firmware is already in place.

David L.

Dan Lukes · ‎11-15-2019

@Oniiz86 is beginning with a .cfg configuration file. Its XML version can be downloaded

Just for completeness, it should be noted the config.xml is not full backup (and XML equivalent of .cfg file). Passwords are not disclosed by phone this way. Passwords needs to be re-entered into file before it can be used as "backup" e.g. pushed back into virgin phone.

RonZ_6474 · ‎03-31-2021

This does not give customers a good feeling about acquiring future, more expensive, CISCO products! Why haven't CISCO engineers been able to fix Backup and Restore? They've had plenty of time. While the Backup and Restore feature works properly in Firmware v1.4.1SR1, it does NOT work properly in versions SR2, SR3, SR4, and SR5. Frankly, I'm amazed that this bug hasn't been fixed. It's a shame that firmware is being released which is known to be broken. Doesn't CISCO still take pride in their products? Is someone at CISCO listening, or is everyone asleep? I'm upset because I just wasted a few of my precious hours on this CISCO problem. Other customers have too. CISCO, please reply with the status and include an exact fix date. We need a real fix, not a tedious techie XML workaround. Much thanks.

David30 · ‎03-31-2021

Hi RonZ, I personally find XML configuration better because configuration differences are much easier to identify using your favourite "compare" utility, such as "Kompare" in some Linux distributions or the Windows-7 command-line utility:

fc  file1.txt  file2.txt  OR
fc  file1.txt  file2.txt > differences.txt

Kompare also allows the user to merge differences (e.g. between a benchmark configuration and the factory default).

The XML configuration model probably requires more time, testing, and technical expertise, but I suspect it offers more options and there are easier & more secure download options than using 'curl'.

However the performance & functionality of Cisco's ATAs are worth the effort IMO. (And I have no connection with the company, in case you're wondering :-).