Obihai is deleting unwanted topics

[RonR]

ShermanObi,

You did not confirm that after these options are set, Obihai will have no ability to access the device in any way.

Exactly what must be done to ensure that Obihai cannot view or alter a device's configuration nor update the device's firmware?  What settings are required to prevent ALL outside access to an Obihai device by anyone other than the owner?

[ShermanObi]

@Mango:  Use the settings below to achieve the state for which you request confirmation.
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

@ronr: Confirmed.

Have a great weekend and thanks for your support.

[Mango]

Thank you very much for your response, and for all your hard work for the VoIP community.

I hope you as well have a great weekend!

[QBZappy]

ShermanObi,

Thank you for your reply. If you were more clear in your first reply, the last four posts were unnecessary in order to press you for a final and clear reply. You are obviouly replying to Mango and RonR directly, and indirectly to everyone else. The style of your responses makes me feel like I am reading the output of the big "OBihai syslog server".  The reply is in human readable form, however sometimes I'm left scratching my head wondering if I understood the log message completely. It is sometimes too Borg like. Loosen up a little.

You know we all love your product. That's why we care.

Cann't wait for the next update. 

Have a nice weekend.

[VaHam]

To answer questions from RonR and VaHam...

The following parameter settings will disable OBiTALK services.
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

Auto Firmware Update & ITSP Provisioning are parameters used primarily by ITSPs (and managed services VARs). OBiTALK does not use either of these parameters.  Some individuals & organizations may use the Auto Firmware Update as described in this FAQ: Click Here

Your response addresses disabling OBiTALK services and OBiTALK provisioning; but mentions that OBiTALK does not use the Auto Firmware Update & ITSP Provisioning parameters.  Are you saying that anyone who did not have those enabled, should not have been upgraded recently? Or are you saying that OBiHai ignores those settings and performs upgrades when it deems them to be necessary?  Note I am saying OBiHai (the Company) not OBiTALK here; which would include OBiTALK and any other software operated or licensed by OBiHai.

The link you provided describes how enable auto upgrades. ("How do I automate upgrades to the most current available firmware?")

I remain uncertain that the above responds to my question.  Which was:

Can you provide a list of all settings required to disable ObiTalk and any other features necessary so that OBi devices can no longer be accessed by anyone other than the physical owner/user?

Users who are concerned about security over features can then make a choice as to which they prefer.

I am asking for all settings necessary to keep anyone other than myself from being able to access my OBi's for any purpose other than simple processing of phone calls.

[Dan_voip]

I am asking for all settings necessary to keep anyone other than myself from being able to access my OBi's for any purpose other than simple processing of phone calls.

Check ShermanObi's Reply #21 on this topic and you'll have your answer.
I have those 2 settings disabled/unchecked and I can confirm my firmware is still 1.3.0 (Build: 2690) so was not updated.
Beside those 2 you have to disable "Auto Firmware Update" and "ITSP Provisioning", that way you'll be sure your device will not be updated or provisioned.
The difference between Auto Firmware Update and OBiTALK provisioning/service enabled is for the 1st option the OBi device will check and ask for a firmware update while the 2nd one will allow Obihay to push an update to an OBi device.

[RonR]

ShermanObi,

Are you sure we have the full story?

With:

System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

Dialing **5 + nnnn in response to the OBiTALK Web Portal's Add Device prompt allows the OBiTALK Web Portal to take full control of an OBi again and in the process re-enables:

System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Periodically
Voice Services -> OBiTALK Service -> Enable : (checked)

[ShermanObi]

For the purposes of this discussion, the only two parameter settings you need to touch are the ones associated with the OBiTALK Service.  This makes sense, given the desire here is to configure the OBi device so it is untethered to the OBiTALK service.

System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

With these settings, the OBi device has no association to OBiTALK services and features as described in my original post to this topic.

The Obihai platform is quite different from it's peers in the industry in the way it supports multiple services (including the OBiTALK service) and how it approaches multiple provisioned services to be supported simultaneously, e.g. ITSP + OBiTALK.

The Auto Firmware Update parameter is found in the System Management area of the OBi device management system architecture.  This is for use by individuals and organizations who want to remotely manage the firmware residing on their OBi device(s).  When not disabled, the Auto Firmware Update Method parameter will invoke a firmware update based on the settings and syntax of a couple other parameters called Interval and Firmware URL.  There are also UN and PW parameters that can be set to further control how the OBi updates it's firmware.

A similar approach is used for the OBi device configuration profile management when the device is managed by a service provider.  These parameters are found in the ITSP Provisioning area of the OBi device management system architecture.  Again, the Method setting, when not disabled, will key on its sister parameters that tell the OBi when (Interval) to retrieve its service provider provisioned profile and from where to get it (URL).  

These parameters, their function and usage are described in the OBi Device Provisioning Guide found in the Documents and Downloads section of the Obihai Support web page (Click Here).

@RonR - Yes. When a user adds their device to the OBiTALK portal, dialing **5 allows OBiTALK to associate the OBi with the correct user's account.  But then you have probably never done that.  

[RonR]

@RonR - Yes. When a user adds their device to the OBiTALK portal, dialing **5 allows OBiTALK to associate the OBi with the correct user's account.

So, even with:

System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

The OBiTALK Web Portal is still able to take control of an OBi and change its configuration to:

System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Periodically
Voice Services -> OBiTALK Service -> Enable : (checked)

[pc44]

But then you have probably never done that.  

LOL that was the funniest line in the whole thread.

The Obihai platform is quite different from it's peers in the industry in the way it supports multiple services (including the OBiTALK service) and how it approaches multiple provisioned services to be supported simultaneously, e.g. ITSP + OBiTALK.

Different from its peers is not always a bad thing.  Look at Google Chrome.  First major web browser to use/push SILENT UPDATES to all clients -- no user response and no notifications.  Firefox seems to have now followed suit.  While it raises some legitimate privacy concerns, I can see some benefits, as long as end users have an opt-out option as described above.

[VaHam]

@RonR - Yes. When a user adds their device to the OBiTALK portal, dialing **5 allows OBiTALK to associate the OBi with the correct user's account.

So, even with:

System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

The OBiTALK Web Portal is still able to take control of an OBi and change its configuration to:

System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Periodically
Voice Services -> OBiTALK Service -> Enable : (checked)

Don't get me wrong here I love my OBi and have recommended them to many other folks as well. 

That being said I think a direct answer to my question has been side stepped here.  My question is broader than "untethering OBiTALK" but rather includes settings necessary to completely disable anyone other than myself from gaining control of my OBi's.

Based on the above from RonR (I haven't tried the test myself) the reason my broader question has not been addressed, would appear to be that if there are settings which would dis-allow access by anyone other than myself, they are not being presented; since if what RonR says is true then OBiHai can certainly regain control via it's web interface even when the settings referenced thus far are all configured to dis-allow external control.  And it follows that if OBiHai can regain control then someone else may be able to use the same method(s) to gain control.

So once again are there settings which will prevent ANYONE other than myself from gaining control of my OBi's?  This is a yes or no question.

[Ostracus]

@RonR - Yes. When a user adds their device to the OBiTALK portal, dialing **5 allows OBiTALK to associate the OBi with the correct user's account.  But then you have probably never done that.  

Then I guess we better not dial **5 + nnnn, or create an account to associate with.
.

[Mango]

if what RonR says is true then OBiHai can certainly regain control via it's web interface even when the settings referenced thus far are all configured to dis-allow external control.

What RonR says is partly true.  Keep in mind that in order for Obihai to regain control, the user of the device would need to dial **5xxxx.  Based on what I've seen here, the function of **5xxxx appears to be to turn on OBiTALK Provisioning and OBiTALK Service, and add the device to OBiTALK.

So yes, if you turn on OBiTALK Provisioning and OBiTALK service, then OBiTALK Provisioning and OBiTALK service will be turned on.

Disclaimer: don't consider this me defending Obihai.  I absolutely do not agree with automatic firmware updates turned on by default, and I really don't agree with how it's not obvious this is happening, or that the way to disable it is not intuitive.

[VaHam]

What RonR says is partly true.  Keep in mind that in order for Obihai to regain control, the user of the device would need to dial **5xxxx.  Based on what I've seen here, the function of **5xxxx appears to be to turn on OBiTALK Provisioning and OBiTALK Service, and add the device to OBiTALK.

I guess I will have to setup a test to answer my question; by blocking network access to the OBi and then dialing the **5nnnn to see if the update and provisioning bits are enabled by the **5nnnn internal to the OBi itself or are switched on only after access to the OBi network is achieved.  The reason I wonder about this is Sherman's earlier statement:

Auto Firmware Update & ITSP Provisioning are parameters used primarily by ITSPs (and managed services VARs). OBiTALK does not use either of these parameters.  Some individuals & organizations may use the Auto Firmware Update as described in this FAQ:

(emphasis added)

If these are not used by OBiTALK then why are they being enabled by OBiTALK?

[lhm.]

System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (checked)

So even though Auto Provisioning in the above is disabled Auto Provisioning & Auto Firmware Update can still occur if OBiTALK Service -> Enable : is (checked)?

Update: I guess this is the answer to the above, "To maintain OBiTALK OBi-to-OBi calling functionality (and related features), Obihai may make configuration or software modifications to devices that use the OBiTALK Service. Otherwise, when there is a 'service' affecting issue, we may need to update its config or software. This is memorialized in the OBiTALK terms of service and this is what we did on Wednesday." It appears they can override the "OBiTALK Provisioning -> Method : Disabled" setting.

[RonR]

What RonR says is partly true.  Keep in mind that in order for Obihai to regain control, the user of the device would need to dial **5xxxx.  Based on what I've seen here, the function of **5xxxx appears to be to turn on OBiTALK Provisioning and OBiTALK Service, and add the device to OBiTALK.

So yes, if you turn on OBiTALK Provisioning and OBiTALK service, then OBiTALK Provisioning and OBiTALK service will be turned on.

This is NOT the case.  Dialing **5nnnn does NOT turn on OBiTALK Provisioning nor the OBiTALK Service.  I tried numerous variations and tests, with and without rebooting, etc.  **5nnnn always reports that nnnn was sent to the provider but no change occurs to the OBi at that point.   It's only when the OBiTALK Web Portal receives the expected nnnn that the OBiTALK Web Portal sends the necessary commands to the OBi that OBiTALK Provisioning and the OBiTALK Service are re-enabled and the OBi is again under Obihai control.

It's very clear that setting:

System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)

does NOT prevent Obihai from taking control of an OBi.

[shap]

I think your test was incorrect - by dialing **5nnnn you will trigger communication from Obi to Web Portal, and by the end of this communication ObiTalk service will be enabled on your device.

That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.
The only way to be 100% sure that Obi can not get access to the devices - is to sniffer the traffic...
However, I do not thing it is worth to do.

P.S. I have ObiTalk service disabled and did not get firmware upgrade.

[Mango]

That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.

Bingo.  With no NAT hole open in your router and no communication initiated by the device, no one from outside could possibly gain access to your device.  This is basic networking 101.

FTR, I've been running Wireshark to monitor my OBi110 for the past two days and so far can confirm that Sherman's statements are correct.

[RonR]

I've been running Wireshark to monitor my OBi110 for the past two days and so far can confirm that Sherman's statements are correct.

With everything disabled and without being logged into any OBiTALK account, dial **5 + any4digitnumber and watch Wireshark.  You'll see your OBi's product information (SerialNumber/OBiNumber/etc.) being sent off to Obihai.  I guess in addition to the disabling Auto Provisioning and the OBiTALK Service, there needs to be a warning to never dial **5 as there's no way to disable it (as far as I'm aware).

[VaHam]

I think your test was incorrect - by dialing **5nnnn you will trigger communication from Obi to Web Portal, and by the end of this communication ObiTalk service will be enabled on your device.

That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.
The only way to be 100% sure that Obi can not get access to the devices - is to sniffer the traffic...
However, I do not thing it is worth to do.

P.S. I have ObiTalk service disabled and did not get firmware upgrade.

Note: RonR says that no changes take place until after a successful connection to the OBi servers using the correct 4 digit authentication code.  You don't need to sniff with wireshark or even block the OBi's ip at the border router to test this.  Simply make up a four digit code which will be incorrect (i.e. **51234).  The Obi will announce in voice that the code has been sent to the server however since the code is incorrect no changing of the bits takes place.  What this tells you is, that it is the sequence of commands being returned to the OBi which in fact modifies these bits and regains control of the device.  The control bits are not being changed autonomously by the **5nnnn command executed in the device itself without successfully connecting to the OBi server. Thus it is the server and not the device command which changes the control bits. 

What that means is there must be some sequence of commands being returned by the OBi server which actually turns on or allows the Auto Provisioning and Firmware Update control bits to be changed. 

If that is the case, then if OBiHai can do it then it may also be possible that the same commands could be hacked and used by someone else to do the same thing.

While the OBi can happily work behind a firewall, a firewall should not be required in order to assure protection of the device. What about remote users who have the OBi connected directly to a modem?

I am also still puzzled by the statement that OBiTALK does not use these control bits; why are they then being changed by OBiTALK?