Can't restore configuration from backup made today

[OZOi]

1. I saved current configuration in backup file
2. Successfully restored old configuration from backup, made in 2011
3. Tried to restore saved in p1 configuration and after reboot there is no change. Configuration is from 2011.

What should I do?

There was a lot of changes in between...

OBi100, 1.3.0 (Build: 2774).

[QBZappy]

You may need to retype in the config manually again. The good news is that you can read the BKUP file using M$ excel.

[OZOi]

With this OBi design, where many settings scattered among multiple different configuration pages, it becomes a tedious task to enter so many fields correctly (the key word here is "correctly"). Then it requires a full test of all features to see if I did everything right this time...

Now, what if I want to change configuration again, using backup file created month ago? Should I go and do this monkey job again? This is ridiculous

Current backup is definitely broken!!!

It was working well and it was broken somewhere between January 2012 and June 2012. Here is old thread from past year where I mentioned the problem and it still broken even now Without backup configuration and testing of anything one tries to do with OBi becomes extremely hard. So, again:

OBi developers, please fix the bug!!!

I made 5 backup files in a row, one-by-one, from the same configuration, getting every time different backup files, which differ not only by structure, but even by their sizes! They all have different parts (usually at the end of the file) missing and / or XML broken. For example, the first backup file has missed this important object:
  <Object>
    <Name>VoiceService.1.VoiceProfile.2.</Name>
...
  </Object>
And I saw broken XML code inside too, that must be removed manually... Only after that it started loading again.

[OZOi]

Here is example of broken XML code, that I've mentioned in my previous post:
      <ParameterValueStruct>
      <Name>X_FaxPassThroughSignal</Nam      <Name>STUNEnable</Name>
      <Value X_UseDefault="Yes"/>

I've seen other cases too...

[CoalMinerRetired]

Have you seen this thread? http://www.obitalk.com/forum/index.php?topic=4098.msg34381#msg34381

I haven't tested the approach yet, zapattack reports it works for him. 

[OZOi]

@CoalMinerRetired, no I haven't. But that's exactly my experience.

The problem is - OBi creates broken backup files. Sometimes it's truncated, sometimes it's missing some parameters, and sometimes it even has broken XML fragments (see my post above). Try to make several backups in a row (without changing configuration in between) and compare those saved files. Because actual configuration was not changed, they should be the same (except time stamps, of course). But they are not...

Saving backup files was broken sometime after January 2012... Before that it was working well. I can restore configuration using those old files without any problem.

Now, if you feel desperate (as I do) and need it to fix it, you have to go and manually edit broken files in hope to restore their XML integrity. I did it with the last file (it took a lot of my time) and now, instead or making changes in web console and then save the next version of backup file to be able to restore it later, I have to edit configuration directly in that file and then restore it into OBi... That's weird! But I don't see any other options now. I can't save configuration backup, without the need of manually correcting them again

[zapattack]

If using IE, try Firefox, or Chrome, or whatever else might work to do a backup.
You should not get partial files.
Remember Passwords are not backed up, as well as a few other items, but Dial Maps should be.

[OZOi]

@zapattack, thanks a lot for useful advice. I've made several backups using Chromium, instead of my default IE and it looks like OBi can make them work. Now I have to remember to use different browser to make backups, than I use to configure OBi... Restoring works fine with IE though.

About keeping passwords within configuration file. I need to keep them in the file. So, when I restore some old configuration - OBi should work immediately, without need for second reboot, required after entering password manually... There is absolutely no any security problem for me in my environment, and I don't share my backup configuration files with anyone. It'd be very, VERY nice if OBI allowed me to save my passwords in those backup files. An option, which offered that (among other backup options), would be very useful. Iit wouldl save my time. Why backup configuration file saves last dialed number (which has absolutely nothing to do with configuration) and not passwords, which are actually part of configuration?

Unfortunately current support of passwords, saved within configuration files, is half-broken. I add these tags into my backup files manually:
    <ParameterValueStruct>
      <Name>AuthPassword</Name>
      <Value>myPass</Value>
    </ParameterValueStruct>
While it always works well for SP2, for some weird reason, it doesn't for SP1. It'd be nice to see at least some fix here.

[zapattack]

Glad your backups are working.
From a security perspective, having passwords in an easy to read  XML document is not good practice.
BUT, if you want to keep them in the same document, put them in your Speed Dial list!!
Nothing checks to see if the data in there is a real number...

[OZOi]

Do you mean to keep passwords handy to be able to copy paste them from speed dial entires to appropriate AuthPassword fields? If so, remembering passwords is not a problem. The problem is, I have to enter passwords manually and make second (unnecessary, IMHO) reboot every time I change configuration, using different providers... So, I change configuration using old backup file and reboot. Then I have to enter passwords and reboot again.

In my environment there is absolutely no security risk in keeping those credentials in configuration files, that I want to maintain. And I enter passwords into them manually. But even in this case (passwords are within configuration files), OBi doesn't honor them and simply discards

Earlier I've come to a wrong conclusion, that OBi can accept password for SP2, while discarding it for SP1. It was due to the case, when I switched between two configuration files, where second provider was the same. Let say I have configuration files: AB.xml and CB.xml (A, B, C are different VoIP providers). When I switched between those two configurations, the second provider (B) had no problems with login (because it was the same in both cases). Now I've made three configurations - AB.xml, CB.xml and CA.xml and it becomes obvious that:
1. OBi always discards AuthPassword value specified in configuration files
2. OBi keeps AuthPassword value from previous configuration, even if provider (account) was changed

I can create separate configuration file, that contains only credentials. For example:
<?xml version="1.0" encoding="UTF-8"?>
<ParameterList>
 <O>
   <N>VoiceService.1.VoiceProfile.1.Line.1.SIP.</N>
   <P>
     <N>AuthUserName</N>
     <V>myAccount</V>
   </P>
   <P>
     <N>AuthPassword</N>
     <V>myPassword</V>
   </P>
 </O>
</ParameterList>
But, when I load it into OBi, only AuthUserName is accepted, while AuthPassword is always discarded. Why is that? Do they changed the name of the latter variable?

How to include passwords within configuration files now?

[QBZappy]

      <V">myPassword</V>    <-----------   <V"><![CDATA[myPassword]]></V> (Replace with this) BTW that " in the V" looks out of place.
  

I'm no coder and more than likely completely off base, but I was curious about what you are trying to do. I read on some other site that an XML parser can be forced to treat data as text using this syntax. Just a stab in the dark.:

<![CDATA[

    <!-- comment treated as plain text -->

  ]]>

[OZOi]

Of course you're right. There should be no " after V. It was a typo, made when I edited my post. Now it's fixed. Thank you, @QBZappy

I tried your suggestion and used:
<ParameterList>
  <O>
    <N>VoiceService.1.VoiceProfile.1.Line.1.SIP.</N>
    <P>
      <N>AuthPassword</N>
      <V><![CDATA[myPassword]]></V>
    </P>
  </O>
</ParameterList>
No luck, unfortunately. This code doesn't work too:
<ParameterList>
  <O>
    <N>VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword</N>
    <P>
      <V>myPassword</V>
    </P>
  </O>
</ParameterList>

But please keep your suggestions coming

Does anybody have any success in entering password from configuration file?

[CoalMinerRetired]

But please keep your suggestions coming

Does anybody have any success in entering password from configuration file?

Based on statements Obi documentation make, such as this "Note:  Neither database maintains storage of passwords used by OBi devices for administrative access or voice service registration.  When a password is entered and submitted via the OBiTALK or OBi Expert Configuration web pages, it is sent securely to the device (on the next profile re-sync) and then deleted." link, it makes you wonder if that same exclusion extends to the XML schema, and possibly there is no field for password.

I don't want to discourage you from investigating this, if you figure it out, then it would be one of those obscure but useful tips and tricks that is worth knowing. But you do have to wonder if it can ever work.  So take this as FYI.

[OZOi]

Well, it sounds somehow discouraging

I don't know about OBiTALK dashboard (I don't use it), but when I submit password using direct web connection to OBi device, the password comes in a plain text (within POST packet). Here is copy/paste example, captured with Wireshark:
uri=\"/result.html?d4777741=myPass\"

But even if they used a digest/hash, I'd like to know that and apply for password values in my configuration files too. So, I don't need to manually re-submit passwords and then reboot the OBi, just to be able to use SIP providers every time I restore configuration from saved XML files...

[QBZappy]

OZOi,

Service providers who manage the OBi devices for their customers obviously have a solution for this. If you want to take this to the final solution, I think you need to set yourself up as a self provisioning server.

I remember some discussion a long time ago about this. You will need to search the forum for this discussion. RonR participated in the thread.There is also some reading material on the OBi web site which I believe is available for everyone regarding ISP providers which may provide some direction. If memory serves, it basically is an XML file approach. I suspect that the passwords may be handled differently as the ISP lock the units from the customers.

I had been interested in doing a "How to" on the topic of self provisioning. Perhaps you will beat me to it. Let us know.

I see that you talk to RonR over at DSL. He would be the right person to ask. It's funny that we have to ask OBi related questions over at some other site because of the strained relationships.

[OZOi]

That's a good idea and it makes sense to look closer on provisioning service. It's based on XML file, perhaps similar to what we can create with backup facility on OBi. Unfortunately I can't find info about how to use it. I guess, @CustomATA knows how to do it, but he is not an active member here...

[QBZappy]

OZOi,

Well if you look in the OBi, we can see that it may be provisioned using tftp.
ITSP Provisioning->ConfigURL = tftp://$dhcpopt66/$DM.xml

Anyone who has flashed a router with 3rd party firmware or upgraded an ATA firmware may be familiar with this tool. I suspect that http can also be used to upload config file. I think the idea is to point the OBi to a tftp server located on your machine if you are doing it over the local lan. Encryption is not necessary doing this local. I can see this being done over wan as well simply by port forwarding to your tftp/http server. Without going into specifics, the provisioning could be accomplished via the phone touch tones or rebooting the unit if the auto provisioning is setup properly.

It's trivially easy to figure out how. I may write up some instructions when/if I find the time.

I interpretted "provisioning it yourself" as local provisioning via 192.168.xxx.xxx, as opposed to OBiTalk.com.

I'm referring to auto-provisioning via "System Management -> Auto Provisioning -> ITSP Provisioning -> ConfigURL".

CustomATA gives us some clues of where to start. He also mentions that it is easy. Self provisioning, once perfected and documented properly can help those that are managing far away units.

How to auto-provision IP phones with DHCP 'option 66:
http://www.3cx.com/sip-phones/DHCP-option-66/
The sub links are intersting

You will need this:
TFTP Server:
http://tftpd32.jounin.net/

Step 1 prepare your XML file (including passwords)
Step 2 follow the guide instructions. (The guide is better than anything that I could ever write)

If you try, let us know the results. You realize that others will be following this thread.

[OZOi]

Well, I've set up local TFTP server and put into its folder backup file, made earlier from current configuration. Then I've set System Management | Auto Provisioning | ITSP Provisioning | ConfigURL value, pointing to that file: (here is example) tftp://host.tld/OBi.xml.

Result of the test is - manually putting passwords into configuration file works well, if file is downloaded from TFTP server, and it doesn't work at all, if the same file is uploaded with web browser...

Again, it's possible to use ITSP Provisioning feature, but it adds extra hassle. First, you have to set op TFTP server. Then you have to move backup files into its folder. Then, if you want to keep some configuration, you have not to forget and manually edit that file, and particularly, its internal ConfigURL value to point to itself. If you don't do that carefully, you may get the old configuration back, when you don't need it anymore...

I think we have to ask OBi developers for a help here. We need an option (presumably in Backup Configuration section), that will allow users to save/keep/restore AuthPassword values in backup configuration files, in case if we need it. That would really help to avoid unnecessary reboots of OBi device, when we change / restore its configuration from local XML files. A warning box, telling that passwords will be saved inside backup file, could benefit the backup process too... Current implementation of this feature in OBi devices creates unnecessary problems for uses who don't need them.

[QBZappy]

OZOi,

Glad to hear that it worked.

I think we have to ask OBi developers for a help here. We need an option (presumably in Backup Configuration section), that will allow users to save/keep/restore AuthPassword values in backup configuration files, in case if we need it. That would really help to avoid unnecessary reboots of OBi device, when we change / restore its configuration from local XML files. A warning box, telling that passwords will be saved inside backup file, could benefit the backup process too... Current implementation of this feature in OBi devices creates unnecessary problems for uses who don't need them.

I don't see any problem with this request if the exercise is to be performed on the lan or over the wan if you understand the consequences if you don't use some form of encryption. However I can see the problem from obihai's point of view as well. Consider that their OBiTALK 'provisioning' portal will be used to upload configs, including passwords. I'm certain their lawyers would prefer not to touch that issue with a ten foot pole. That could make them  guilty by association, by providing the tools which permit cracking the OBi passwords while connected to their servers. As useful as it may be for users, they probably have no interest in making their servers available for this.

I can think of at least two examples which show us that they prefer to err on the side of safety/security. The first is the approach in addressing passwords in the XML bkup file which we are currently discussing, the other which come to mind is the wan port lock they have installed. We can not view the local unit web page using wan port without punching in some numbers on the attached phone to unlock the web browser.
   
The real value of this discussion is to document a way to push configs to OBi units local and even remotely. This method is more efficient, and under admin control without any of the limitations of the OBiTALK portal.

[OZOi]

1. I'd not worry about any layer. Period. They will never be "guilty by association", ever. I'm talking from my experience... And BTW, they don't waste their own time, waiting for double reboots and entering passwords. I do.

2. As I mentioned earlier, when user submits password to OBi device using web browser, the password is sent in plain text. Why I can not to do the same (send passwords) when I'm uploading configuration file? What is the difference?

3. TFTP provisioning allows uploading XML configuration files with passwords. Why I can't do the same with uploading the very same XML configuration file using web browser? What it the difference?

4. I know what I'm doing. I know why I'm doing it. And I need to do it this way. It's because it makes my work faster and easier. I don't want to double the number of OBi reboots, while entering passwords in the middle every time I change configuration. How should I express my desire more clearly than that?

5. And finally, if developers don't want to see passwords in plain text in XML configuration file (I personally don't mind it at all, but let's assume that they don't), they can hash them. And BTW, they should hash them the same way when user sends submit request too. That will make Obi a bit more secure. Not a speculation about some fictitious layer's liability.