VOIP etc > Voice Over IP - VOIP > VOIP Tech Chat > Provisioning of the OBi100/110/202 (Made Easy)

Provisioning of the OBi100/110/202 (Made Easy)

Screenshot
OBiProv.zip 1,003,392 bytes Archive

OBiProv.exe is a Windows program intended to greatly simplify the steps needed for the provisioning of OBi100, OBi110, and OBi202 devices. Provisioning is a process whereby the devices pull their configuration from a host server at initial startup (and optionally periodically thereafer).

OBiProv compresses all XML files using GZIP and optionally encrypts them using AES or RC4 algorithms.

While either an HTTP or TFTP server may be used, TFTP is used by OBiProv due to its simplicity of installation and ease of use. The steps required to provide provisioning support are:

1. Install a TFTP server if not already present. Two possible sources are:

»tftpd32.jounin.net/
»www.solarwinds.com/products/free···ver.aspx

2. Create a backup of the target device at:

System Management -> Device Update -> Backup Configuration

'Use OBi Version' must be checked.

Passwords and PINs are not included in the backup file created.

3. Run OBiProv. Enter the TFTP server IP address or hostname. Select a previously created backup file. Enter the applicable passwords and PINs to be added to the provisioning file.

4. Select File -> Output $DM Files. This will create the following files:

OBi100.xml
OBi110.xml
OBi202.xml

These files will need to be recreated only if the TFTP server or the encryption keys are changed.

5. Select File -> Output XML File(s). This will create the provisioning file(s) from the selected backup file. For example, if the selected backup file is backup9CADEF123456.xml, the provisioning file(s) will be:

9CADEF123456-1.xml
9CADEF123456-2.xml (if AES/RC4 encryption was used)

The original backup file will not be altered.

6. Copy the following files into the TFTP server's root directory:

OBi100.xml
OBi110.xml
OBi202.xml
9CADEF123456-1.xml
9CADEF123456-2.xml (if AES/RC4 encryption was used)

7. If your router supports DHCP Option 66 (as does those running third party firmware such as Tomato or DD-WRT), enter the following Dnsmasq Custom configuration entry:

dhcp-option=66,"192.168.1.150"

Use the actual IP address of your TFTP server in place of 192.168.1.150.

Provisioning will now be fully automatic, even following a factory reset.

If your router does not support DHCP Option 66 , you will need to set the OBi100, OBi110, and OBi202 devices as follows:

System Management -> Auto Provisioning -> ITSP Provisioning -> ConfigURL

tftp://192.168.1.150/$DM.xml

Use the actual IP address of your TFTP server in place of 192.168.1.150.

This setting will need to be re-entered only if the device is factory reset.

In all cases, set:

System Management -> Auto Provisioning -> ITSP Provisioning -> Method

System Start

8. Reboot the OBi100, OBi110, or OBi202 device. You should see the TFTP server deliver the appropriate OBi100.xml, OBi110.xml, or OBi202.xml file followed by 9CADEF123456-1.xml and 9CADEF123456-2.xml (if AES/RC4 encryption was used) after an intervening reboot.

To encrypt the provisioning file, enter an AES or RC4 key in the 'K' field of OBiProv. AES encrytion also requires an entry in the 'iv' field. Both values must be 32 characters long consisting only of hex digits (0-9 and A-F). If both the 'K' and 'iv' fields are populated, AES encrytpion is used. If only the 'K' field is populated, RC4 encryption is used. If both fields are left blank, no
encryption is used.

If the Method field of OBiProv is set to System Start, the target device will only retrieve its provisioning file when the device is rebooted. If Method is set to Periodically and an Interval (in seconds) is specifed, the target device will periodically check the provisioning file and deploy any changes found the next time the device is idle. If Method is set to Disabled, the device will be provisioned only once. To allow further device provisioning, it will be necessary to set:

System Management -> Auto Provisioning -> ITSP Provisioning -> Method

System Start

File -> Output Text File creates a file that lists all parameters generated by OBiProv.

OBiProv configurations may be saved with File -> Export Configuration and restored with File -> Import Configuration.

If OBiProv is executed with a command line option of a configuration filename (for example: OBiProv.exe OBiProv.cfg), the specified configuration file will be loaded at startup.

The following files must be in the same folder as OBiProv.exe:

gzip.exe
libeay32.dll
obcrypt.exe
openssl.exe
ssleay32.dll

Nothing is installed and no modifications are made to Windows by running OBiProv.exe.

Once again, that looks like some very interesting piece of work. Thanks for sharing. Looks like you're going to make the OBiTALK portal obsolete.

reply to RonR
Very nice! Thanks RonR

At the same time you've posted your new tool here, I've posted my problem using encrypted provisioning files in Obi forum. And I'm stuck with question, where the problem is. Could you please take a look and post your opinion (here, if you don't want to post there).

I've tested your tool and it works well. Couple of questions though:
1. Generated files are not XML files. They are binaries. Is it possible to make output files with proper extensions (anything, but not .XML)? When folks will find XML files, which are not text, they may consider them as corrupted files and remove them as a result...

2. Can we use a different file (not specifically named backup file) as input to this program? I usually name backup files accordingly to date when they were created and particular configuration. For example, 130304_GV+Vms.xml (meaning it's made today, two providers configured as indicated). I'd like to input one of such files into your provisioning tool and generate an output.
--
Keep it simple, it'll become complex by itself...

Wow!!! That was a bull's eye shot

What is the probability of the event when file size is not a multiple of 16 bytes? That's exactly was my chance to make it working...

Huge thumbs down to developers of OBi who did not take care about it and actually did not mention about it (at least I can't see that) in the section of the OBi Device Provisioning Guide, described how to make encrypted provisioning work

This hidden "feature" (I'd rather say - bug) makes my work much harder. Especially if my text editor trims extra white spaces from lines... One more hindrance to remember to jump over while working with other problems.

Thanks a lot, Trev !

And BTW, when I decoded the encrypted configuration file using openssl enc -d .. command it produced correct XML file, exactly as the source. I've checked it, when I tried to troubleshoot this sudden problem...
--
Keep it simple, it'll become complex by itself...

reply to Trev
I think you'll find that anything properly encrypted with aes-128-cbc will have a resulting file size that is a multiple of 16. If you're ending up with an encrypted file whose size is not a multiple of 16, it's probably due to a bug in the openssl program you're using. None of the pre-encrypted XML files I've fed to openssl have had a file size that was a multiple of 16, but all of the encrypted output files from openssl are a multiple of 16 and OBi's have never failed to decrypted them properly.

Yes the resulting encrypted file should be a multiple of 16 but the ultimate decrypted plaintext file may not be. I understand there is padding (IIRC if you need 3 bytes of padding, those bytes become 0x03 or something like that) for the purpose of being able to encrypt the whole block, but that padding should be removed when the original content is reconstituted.

Edit: for the record: OpenSSL 1.0.0j 10 May 2012
--
I represent AcroVoice, a full service Canadian VoIP Provider.
Buy your Obihai ATA shipped from within Canada.

reply to RonR
We've talking about .XML files (plain text) here. Not about encrypted (binary) files.

I've made multiple tests with different source files (all of them have sizes not equal to multiple 16) and openssl (v0.9.8d in my case) decrypts encrypted files exactly as their respective sources. Binary comparison is 1 to 1.

It's the problem with decryption algorithm, used within OBi, that creates that trouble...
--
Keep it simple, it'll become complex by itself...

I don't know what to tell you. None of the source XML files here are a multiple of 16 bytes in length. Whether I send them to an OBi as a plain-text XML file or a gzip'ed XML file or an AES/RC4 encrypted XML file, the OBi's happily accept them and set the appropriate parameters.

reply to RonR
RonR , I think you may want to offer users to choose particular type of their device (OBi100, OBi110 or OBi202). The same way as you did in OBiCfg tool. In this case:
1. There will be only one $DM.xml file to take care and move to TFTP server
2. Users of OBi100/110 will not be perplexed with entering SP3/4 passwords
The less potential confusion, the better for the end user
--
Keep it simple, it'll become complex by itself...

May be there is a big picture and some important aspect in it, that I'm missing, but please tell me why I need two files OBi110.xml and OBi202.xml to keep and move them to TFTP server, If the only device that I have is OBi100...

And second, it's good to hear that you, developer, know that SP3 and SP4 values will be ignored. But the OBi100 user will be thinking what he has to enter into those fields, why his OBi100 doesn't have those settings and even what will happen to configuration if he will just omit them. Again, when you offer a tool to public, you should should think about their potential way of thinking and try to avoid completely unnecessary questions...

BTW, you have offered that choice in OBiCfg perhaps to avoid questions from OBi100 users what to do with LINE tab at the bottom of the tool (along with other device specific settings not pertained to OBi100). The same principle should apply here as well.
--
Keep it simple, it'll become complex by itself...

I wrote OBiProv to be very simple to use and yet be very general in supporting all devices without having to care about what particular models are in use now or in the future. Clearly, if you only have an OBi100, you don't need the OBi110.xml and OBi202.xml files. But again, OBiProv was written to handle all situations generally rather than be unnecessarily specific. I don't think it makes sense to have OBiProv work on only one model at a time simply to prevent it from outputting two 350 byte files that do no harm if you don't happen to need them at this paticular moment.

I have to believe that anyone who is at the stage of considering the use of provisioning has figured out that his OBi100/OBi110 doesn't have an SP3/SP4 trunk. Unnecessarily restricting OBiProv to deal with one model at a time to simply disable the SP3/SP4 fields seems like overkill.

OBiCfg is quite different. Where OBiProv has no need to differentiate between models, OBiCfg needs to know exactly what it's dealing with.

reply to RonR
Two more suggestion for this tool to consider:
1. Support for HTTP server (not only TFTP) for provisioning
2. Use OBi Default Encryption (optional) for OBi100.xml file, based on obicrypt tool, provided by OBi (very similar approach to using openssl). You may take MAC address from the name of input file or ask user to enter it separately, if user loads input file, that doesn't contain MAC.

1st suggestion is based on statistics that generally HTTP servers are used way more often than TFTP (which is often used only for provisioning devices, like OBi). Some users may prefer to provide OBi provisioning via HTTP (which is supported bow), rather than via additional dedicated TFTP service. And, so far, I don't see the way to configure that in OBiProv.

2nd suggestion is based on idea, that user has to have some security to initially set OBi device remotely without sending in plain text (gzipped) keys within OBi100.xml file. As OBi mentions in its documentation, it's not secure as AES or RC4, but nevertheless, is recommended for transfer the initial settings (in this case, with OBi100.xml file).
--
Keep it simple, it'll become complex by itself...

Hmm, interesting. I can't find that either. They say:

reply to RonR
OBiProv has been updated. If AES/RC4 encryption is used, the provisioning file sent to an OBi that contains the AES/RC4 keys is now encrypted using "obcrypt" ("obcrypt" is a command line tool available for free from Obihai Technology that is executed automatically and silently by OBiProv to perform the encryption.)

Thank you, RonR again.

Why now we have to deal with 3 files instead of just 2?
• OBi100.xml - gzipped plain text, asking to load $MAC-1.xml
• $MAC-1.xml - obi-encrypted. Contains K and IV values. Points to $MAC-2.xml
• $MAC-2.xml - AES-encrypted. Contains actual configuration.

Why the followed and simpler solution doesn't work for you?
• OBi100.xml - obi-encrypted. Contains K and IV values. Points to $MAC.xml
• $MAC.xml - AES-encrypted. Contains actual configuration.
--
Keep it simple, it'll become complex by itself...