dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2557
share rss forum feed

RonR

join:2003-10-10
Ash Flat, AR
kudos:5

1 edit

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

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.


QBZappy

join:2012-05-10

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.


OZO
Premium
join:2003-01-17
kudos:2
reply to RonR

Very nice! Thanks RonR See Profile

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...



Trev
IP Telephony Addict
Premium
join:2009-06-29
Victoria, BC
kudos:5

1 recommendation

said by OZO:

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'm not RonR See Profile but I have way too much experience working with Obihai provisioning and encryption.

One of the problems I had was if my input file was not a multiple of (going from memory here) 16 bytes, the last bit of the file would end up being decrypted as jibberish which caused the OBi device to discard the whole configuration as invalid.

Solution is to pad your input file with spaces so the file size is a multiple of 16.

I wouldn't be surprised if you ran into the same problem. Of course maybe you found something else altogether.

Syslog logging helped get to the bottom of this in my case.
--
I represent AcroVoice, a full service Canadian VoIP Provider.
Buy your Obihai ATA shipped from within Canada.

OZO
Premium
join:2003-01-17
kudos:2

1 edit

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 See Profile!

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...



Trev
IP Telephony Addict
Premium
join:2009-06-29
Victoria, BC
kudos:5

2 recommendations

said by OZO:

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

Yay!

said by OZO:

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...

Yup... I am sure I lost a solid 20 hours to this until I realised what was going on. Some config files work, most didn't, lots of attempts to isolate which parameters were causing the issue... all I can say is I'm very glad to have been able to help someone else out.

said by OZO:

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...

I'm fairly confident it's a bug in their decryption function. I let them know about it a few months back when I discovered it but I guess they haven't had a chance to address it yet.
--
I represent AcroVoice, a full service Canadian VoIP Provider.
Buy your Obihai ATA shipped from within Canada.

RonR

join:2003-10-10
Ash Flat, AR
kudos:5
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.



Trev
IP Telephony Addict
Premium
join:2009-06-29
Victoria, BC
kudos:5

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.


OZO
Premium
join:2003-01-17
kudos:2
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...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

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.


OZO
Premium
join:2003-01-17
kudos:2
reply to RonR

RonR See Profile, 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...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

said by OZO:

RonR See Profile, 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

I think you've missed a very important aspect of the big picture.

The factory default ITSP Provisioning -> ConfigURL setting in all OBi's is:

tftp://$DHCPOPT66/$DM.xml (with Method = System Start)

$DM is a macro that expands to OBi100, OBi110, or OBi202 depending on the device model.

The goal is to be able to deploy a brand new (or factory reset) device with no initial customization necessary. Since each OBi model is going to request a unique XML file, it's necessary to have all three. The $DM XML files change the ConfigURL to $MAC (which expands into the device's unique MAC address) and configures the decryption keys (if applicable) such that each OBi gets a provisioning file that has been customized for that specific unit.

said by OZO:

2. Users of OBi100/110 will not be perplexed with entering SP3/4 passwords

I don't feel that adding an unnecessary modal aspect to OBiProv is a good idea. Should an unexpected value be entered into the SP3/SP4 Password fields, it will simply be ignored by an OBi100/110 since the associated parameter names don't exist in those devices:

VoiceService.1.VoiceProfile.1.Line.3.SIP.AuthPassword
VoiceService.1.VoiceProfile.1.Line.4.SIP.AuthPassword

OZO
Premium
join:2003-01-17
kudos:2

2 edits

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...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

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.


OZO
Premium
join:2003-01-17
kudos:2
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...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

said by OZO:

Use OBi Default Encryption (optional) for OBi100.xml file, based on obicrypt tool, provided by OBi

Do you have a link to obicrypt.exe? I've emailed Obihai requesting one, but I've not received a reply and don't expect to.

OZO
Premium
join:2003-01-17
kudos:2

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

said by OBi Device Provisioning Guide [pdf] :

command line tool “obicrypt” available for free from Obihai Technology. Currently obicrypt is available on Linux and Windows platforms.


--
Keep it simple, it'll become complex by itself...

RonR

join:2003-10-10
Ash Flat, AR
kudos:5
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.)


OZO
Premium
join:2003-01-17
kudos:2

Thank you, RonR See Profile 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...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

said by OZO:

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.

Because all OBi's would then have to use the same K and IV values. Each device should have its own unique keys in a truly secure provisioning environment.

From page 34 of the OBi Device Provisioning Guide:

As the first profile in the chain, $DM.xml [which is OBiNNN.xml from OBiProv] may contain a few parameters to establish some basic boundaries for the device to operate within. Most importantly, it contains a ConfigURL that points to your provisioning server so that you will gain control of the unit after it is shipped.
.
.
.
As shown in the last URL, the second profile in the chain is $MAC-init.xml (where $MAC should be replaced by the actual MAC address in the name of the configuration file for the device).
.
.
.
The main purpose of $MAC-init.xml [which a $MAC-1.xml from OBiProv] is to store a secret decryption key in the device and to let the device switch to use encrypted profile subsequently. As shown in the listing $MAC-init.xml in the next section, the secret key and the IV are stored in the parameters SPRM0 and SPRM1 respectively. Note that the secret key should be individualized for each device, hence the need to include $MAC in the profile name so that the server can tell which device is making that request.
.
.
.
The last profile in the chain is $MAC-encrypted.cfg [which is $MAC-2.xml from OBiProv] which contains information specific to the user account. This profile must be encrypted with the secret keys established in $MAC-init.xml.

OZO
Premium
join:2003-01-17
kudos:2

Then why do not use just two files:
$MAC-init.xml - obi-encrypted, contains K and IV and points to $MAC-encrypted.cfg
$MAC-encrypted.cfg - AES-encrypted, contains configuration and points to itself

Frankly, I don't see the reason for making $DM.xml at all. Is it because of the default $DHCPOPT66 value in ConfigURL? If it is, I don't think it's working. Think about how many routers have this option? E.g. mine, ZyWALL, cost me $400, doesn't have it. In any case, if you want to target a user, who can't change default ConfigURL setting in OBi to point to your TFTP/HTTP server, then I may assure you, that he won't be able to change his router's "option 66" too... (assuming he even has a router, which supports "option 66") So, IMHO, this idea doesn't fly.

But if you have to ask user to set that ConfigURL manually (which is simpler to do, than to configure his router), then you may provide him with string, that points it to $MAC-init.xml file on your TFTP/HTTP server. So, IMHO there is no real need for the intermediate $DM.xml file...

BTW, I still keep a hope to see support for HTTP option in OBiProv tool...
--
Keep it simple, it'll become complex by itself...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5

1 recommendation

said by OZO:

Frankly, I don't see the reason for making $DM.xml at all. Is it because of the default $DHCPOPT66 value in ConfigURL? If it is, I don't think it's working.

The OBi's default ConfigURL [tftp://$DHCPOPT66/$DM.xml] works perfectly. It's what makes it possible to provision a device fresh out of the box with no pre-configuration (as well as reprovision a unit when it's been reset to factory defaults). The very first test of OBiProv used it and it has never failed.

said by OZO:

Think about how many routers have this option? E.g. mine, ZyWALL, cost me $400, doesn't have it. In any case, if you want to target a user, who can't change default ConfigURL setting in OBi to point to your TFTP/HTTP server, then I may assure you, that he won't be able to change his router's "option 66" too... (assuming he even has a router, which supports "option 66")

Every router that has third-party firmware installed (i.e. Tomato, DD-WRT, etc.) supports DHCPOPT66. Configuring the router consists of nothing more than putting a single line [dhcp-option=66,"192.168.1.125"] in the Dnsmasq Custom configuration box. It couldn't be easier. If your router doesn't support it, simply change the OBi's ConfigURL to tftp://192.168.1.125/$DM.xml. It's too nice a feature to penalize those that have it by using a different scheme.

MrCurious

join:2013-04-14
Pompano Beach, FL
reply to RonR

I hate to sound like a rookie, but is this so I can make encrypted VOIP calls? Also, does the other person on the phone call need to have the same setup (Obi with encryption)? One last thing, will this work with google voice?


OZO
Premium
join:2003-01-17
kudos:2

Unfortunately OBi devices do not support ZRTP or other types of secure communications.
--
Keep it simple, it'll become complex by itself...


RonR

join:2003-10-10
Ash Flat, AR
kudos:5
reply to RonR

An update has been posted:

»Provisioning Utility for OBi100/110/200/202/300/302

The new version now supports OBi100/110/200/202/300/302 devices.


obiliving

join:2011-01-22
reply to OZO

said by OZO:

Unfortunately OBi devices do not support ZRTP or other types of secure communications.

You can use SRTP on the OBi. You may select TLS as the transport for SIP so that the crypto keys may be exchanged securely over SIP (the S-Descriptor method).