I'm trying to make ITSP Provisioning work with encrypted configuration files. And so far it looks like it doesn't work at all. My experience:
1. ITSP Provisioning using TFTP server and plain text configuration file works.
2. When I try to set configuration with the same (but now encrypted) configuration file - OBi doesn't accept settings.
I'm using direct instructions from OBi Device Provisioning Guide{PDF} (http://www.obihai.com/docs/OBiProvisioningGuide.pdf) and my steps are:
1. Change one line and add into configuration file two new parameters:
<ParameterValueStruct>
<Name>ConfigURL</Name>
<Value>SYNC -A=aes -K=$SPRM0 -IV=$SPRM1 tftp://host/OBi.xml.en</Value>
</ParameterValueStruct>
<P>
<N X_UA="noAccess">SPRM0</N>
<V>000102030405060708090a0b0c0d0e0f</V>
</P>
<P>
<N X_UA="noAccess">SPRM1</N>
<V>00102030405060708090a0b0c0d0e0f0</V>
</P>
2. Encode configuration file using this command:
openssl enc -aes-128-cbc -K 000102030405060708090a0b0c0d0e0f -iv 00102030405060708090a0b0c0d0e0f0 -in OBi.xml -out OBi.xml.en
3. Restore configuration from this file (set up auto provisioning from TFTP server):
<?xml version="1.0" encoding="UTF-8"?>
<!-- Setting encryption for auto provisioning -->
<ParameterList>
<O>
<N>X_DeviceManagement.ITSPProvisioning.</N>
<P>
<N X_UA="noAccess">ConfigURL</N>
<V>SYNC -A=aes -K=$SPRM0 -IV=$SPRM1 tftp://host/OBi.xml.en</V>
</P>
<P>
<N X_UA="noAccess">SPRM0</N>
<V>000102030405060708090a0b0c0d0e0f</V>
</P>
<P>
<N X_UA="noAccess">SPRM1</N>
<V>00102030405060708090a0b0c0d0e0f0</V>
</P>
</O>
</ParameterList>
After reboot, OBi takes new configuration file from TFTP server (I see that from logs of that TFTP server). But there is no change in its configuration. Perhaps it can't decode the file.
Documentation says, that SYNC script returns value in TPRM0 variable. In my case it's always = 0 (which means, accordingly to the documentation, an error). But it's always = 0 even if I upload new plain text configuration file and its configuration changes accordingly. So, I guess OBi has a bug here and it doesn't provide actual error code via that variable anyway...
Did anyone have a success in uploading encrypted configuration file to OBi100 device?
How do you do that? And what's wrong with those simple steps, mentioned above?
http://www.dslreports.com/forum/r28068374-Provisioning-of-the-OBi100-110-202-Made-Easy-
OZOi,
Aren't you and Ron buddy buddies? Didn't he give you a heads up on this. (/LOL)
That's another nail in the coffin for the OBiTALK portal. Let's look at it another way. This tool opens up the market for a whole new class of potential OBi users. I think that the OBi is officially a "Prosumer " class ATA.
It's not clear what the relationship is between RonR and obihai, or even if Ron's efforts are helping or hindering the OBi. In any event as a consumer of the product I'm thrilled to see 3rd party development of this product (with or without the blessing of obihai). I find it interesting to note that I suspect RonR has steered, dare I say "commandeered", the marketing of this product in an unintended direction. I may one day write a book about this. There have been so many twists and turns in the development of this product. I hang around just to see what develops.
It may seem like an effort to "stick it to the man", however there is no harm done. In fact his work enhances what is already a great product. It is a clear case of "more power to the people", complements of the one man crusader RonR.
Quote from: InetUser on March 04, 2013, 08:10:05 PM
http://www.dslreports.com/forum/r28068374-Provisioning-of-the-OBi100-110-202-Made-Easy-
Huh... InetUser? RonR is that you? Sorry but the timing of your post is too funny to ignore. (/LOL)
It looks like there is nothing wrong with the simple way to make encrypted provisioning work, except one thing... (and it's very important!) - .XML file size must be multiple of 16... I've made couple of tests (making sure this requirement is satisfied) and so far it's working. I'll need to make more tests though to make final conclusion. Thanks to BBR forum and particularly to its member - @Trev for that suggestion (http://www.dslreports.com/forum/r28068718-).
.
drat I had hoped there would be sRTP wizards in here
Jsureal,
Specialized feature requests (wizards) such as yours are now handled over at www.dslreports.com in a more timely manner. :)
Quote from: QBZappy on March 04, 2013, 09:13:33 PM
...
That's another nail in the coffin for the OBiTALK portal. Let's look at it another way. This tool opens up the market for a whole new class of potential OBi users. I think that the OBi is officially a "Prosumer " class ATA.
It's not clear what the relationship is between RonR and obihai, or even if Ron's efforts are helping or hindering the OBi. In any event as a consumer of the product I'm thrilled to see 3rd party development of this product (with or without the blessing of obihai). I find it interesting to note that I suspect RonR has steered, dare I say "commandeered", the marketing of this product in an unintended direction. I may one day write a book about this. There have been so many twists and turns in the development of this product. I hang around just to see what develops.
It may seem like an effort to "stick it to the man", however there is no harm done. In fact his work enhances what is already a great product. It is a clear case of "more power to the people", complements of the one man crusader RonR.
I have to jump in to say I have decidely mixed agreement on the points you made here.
On the plus side, yes, it's a good thing to see these "third party" configuration utilities and approaches, and I don't want to discourage people from doing this. Yes, I like looking at them and using (experimenting) with them. I'm still on the fence as far as the ObiTalk portal goes. And yes I like all the "solutions" the author has offered on here, had it not been for some of that designs and we're be lesser sophisticated users, me especially.
On the negative side, I see these as adding one more level of complication in getting troubleshooting assistance and bug fixes from Obi's support. Why is this so important? Maybe it's only me, but I see the recent series of firmware releases as one release being rock solid, and the next release as causing issues that were not present in the prior version. When you approach Obi support on anything an almost immediate reply is 'it will be easier to fix issues if you use the portal.' This wouldn't be such as issue if it were one minor bug here or there. I'm not exaggerating when saying two or three big ones hit me for every other firmware upgrade. Most recently it's been mystery reboots, calls getting dropped within a second or two of begin answered (history shows the call was dropped by the obi not the called party), no dialtone in the morning (fix is a reboot) and today the time server not updating the devices time upon reboot. Contrast that with some recent releases where I could go 35 days of uninterrupted uptime. Maybe it's only me, but the pattern suggests otherwise.
And I'm not even sure I'm on a general availability release (http://www.obitalk.com/forum/index.php?topic=5275.msg35038#msg35038) anymore.
Apologies if this took the thread off track.
I have found the problem. It was my mistake and I feel sorry for that. I always uploaded configuration file (mentioned in p3, see OP) using device web page (Restore Configuration). SPRM0/1 values were not accepted this way. It's very similar to setting passwords problem, I've mentioned earlier. And again, I don't see any reasonable explanation, why I can't set passwords (and now SPRMx values too) from local configuration files created by backup facility using very secure environment - my local network... I can do it from TFTP or HTTP servers only. It looks like a strange logic to me and I just hope it will be corrected in new FW releases...
Two additional points here:
1. You don't need to set SPRM0/1 within main configuration file (p1, see OP). Setting them once via p3 is enough.
2. With current firmware 1.3.0 (Build: 2774) there is no requirement for .XML files to have size multiple of 16. I've reported it too soon and due to two complicated setups, I've been testing at the same time, which made me think it was the cause of the problem.
OZOi,
Since you have gone through all the pain of figuring out ITSP provisioning, can you see this method being used to configure settings that a user would like based on a schedule using the task scheduler and perhaps the RonR provisioning app, or a tftp/http server. ie: control different settings by time of day, weekdays/weekends, etc... I'm thinking that it might be possible to push various configs based on a schedule. What do you think about the possibility of doing this in an automated way using some basic windows tools?
Quote from: QBZappy on March 04, 2013, 09:13:33 PM
That's another nail in the coffin for the OBiTALK portal. Let's look at it another way. This tool opens up the market for a whole new class of potential OBi users. I think that the OBi is officially a "Prosumer " class ATA.
Not really.
1-The portal and the associated services make remote access easier regardless of were one's Obi is located.
2-Self-provisioning is only a small part of the "usefulness" puzzle.* Ron'R's other tool addresses most of that, even if jargon is front and center.
*And reading through the directions "ease of use" it's not.