News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obihai is deleting unwanted topics

Started by Dan_voip, May 09, 2012, 07:22:03 PM

Previous topic - Next topic

Ostracus

From the OBi Device Provisioning Guide:
QuoteAuto Recovery Mode
The OBi device may enter into an auto recovery mode to address and remedy a failure of a firmware upgrade, such as power lost in the middle of the upgrading procedure etc. In this mode, the OBi device tries to get firmware from the last URL where the firmware was successfully downloaded until the firmware is downloaded or the device is powered off. If the firmware is downloaded, the OBi will install the firmware automatically and restart itself, and progressively return to normal mode. While the device keeps retrying, the firmware can be installed from device management pages as well.

VaHam

Quote from: Ostracus on May 15, 2012, 09:40:41 AM
From the OBi Device Provisioning Guide:
QuoteAuto Recovery Mode
The OBi device may enter into an auto recovery mode to address and remedy a failure of a firmware upgrade, such as power lost in the middle of the upgrading procedure etc. In this mode, the OBi device tries to get firmware from the last URL where the firmware was successfully downloaded until the firmware is downloaded or the device is powered off. If the firmware is downloaded, the OBi will install the firmware automatically and restart itself, and progressively return to normal mode. While the device keeps retrying, the firmware can be installed from device management pages as well.

I added the bold since it is this portion I would be worried about knowing how other devices behave under re-flash conditions.  I don't really think this is a guarantee but I'd be happy to be corrected on that issue by OBIHai.  :)

ProfTech

#62
If you look through the postings you will see at least 1 person that reported that he was running with ObiTalk -> Enabled -> UNchecked and auto firmware update disabled and they did not receive the update. So I think that particular question has been answered.

Modified: I re-read your post. I for one had Auto provisioning  disabled but ObiTalk Enabled [checked] and yes I did receive the update but haven't been overly concerned about it. I have since unchecked ObiTalk since I don't really use it anyway. I need something more flexible and "Commercial".

RonR

#63
Quote from: VaHam on May 15, 2012, 09:17:35 AM
I would be interested to hear if any folks who had the ObiTALK auto provisioning disabled but the ObiTALK service enabled received a push last week or not.

The first thing I set when I take a new OBi out of the box is:

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

I also change the Admin password from 'admin' to a private password known only to me.

The OBiTALK Service was always enabled as it had not been disclosed that by leaving it enbled, the above settings are negated.

With these settings, I have had the firmware in OBi's updated on numerous occasions (sometimes at inopertune times).

As I've previously stated, access to the OBi's contents is also open with the above settings as evidenced by the following response I received to a question I asked via email:

"We just checked your OBi's configuration 200 123 456
SP2's X_InboundCallRoute has {('asterisk'):}, ..."

stevea

I don't dismiss security concerns at all, however they need to be considered in terms of realistic exploits..

I've tracked network traffic from power-up through the the **5nnnn via wireshark.
The Obi110 requests addresses for 'prov.obitalk.com' and 'root.pnn.obitalk.com'  (I have provisioning enabled).  This DNS resolution appears to happen only at Obihai powerup.    Also ntp servers and google server names are resolved by DNS.   So yes we should be concerned about DNS security.  Primarily wrt ISP name resolution.

The '**5nnnn' call causes the Obihai110 to make a tcp connection to 'root.pnn.obitalk.com' port 6800.  Some minor tcp traffic takes place however the identification number for the ObiHai110 is sent unencrypted.  Then it *appears* that an SSL.v3-like connection is setup on the TCP connection after exchanging some Obihai self-signed certs.  The openSSL certs sent to the Obihai are not verified via any public service like Verisign, however that doesn't mean they aren't verified against an in-firmware cache.   *Assuming* that the key exchange is secure and note the crypto selected (AES-256) is good  - then the content of the traffic after SSL setup is quite safe.  IOW the cert exchange and SSL means that Obihai device can be quite certain it is communicating to the Obihai server and not to a fake server, and the encrypted traffic is 'safe enough'.  The security issue is similar to the concept of pointing your web browser to your bank and accepting the https certificate as assurance you have the correct site.

SO *ASSUMING* the key exchange is secure, and the certs are verified from firmware .... an exploit requires an evildoer to steal the private crypto key from Obihai, install a DNS or IP routing exploit to send traffic to his evil-server with a matching cert, and then he must arrange for the '**5nnnn' sequence to be entered on the phone, then he must download evil-firmware to the Obihia or at least change the settings.

I am greatly reassured knowing that there some sort of secure connection on this channel.   I'd like to hear more about the cert verification issue - but so far I have no reason to doubt or distrust ObiHai's design decisions.

I wonder of the firmware download and ObiTalk remote settings use a similar secure channel ?




Mango

#65
For anyone concerned, adding !**5S0| as the first sequence of your PHONE Port DigitMap appears to block access to this code.

VaHam

Very nice work steve!  I am handicapped at the moment since I loaned my only Ethernet hub to a friend and don't have it available to assist with wiresharking right now.

Quote from: stevea on May 15, 2012, 03:09:21 PM
I don't dismiss security concerns at all, however they need to be considered in terms of realistic exploits..

I've tracked network traffic from power-up through the the **5nnnn via wireshark.
The Obi110 requests addresses for 'prov.obitalk.com' and 'root.pnn.obitalk.com'  (I have provisioning enabled).  This DNS resolution appears to happen only at Obihai powerup.    Also ntp servers and google server names are resolved by DNS.   So yes we should be concerned about DNS security.  Primarily wrt ISP name resolution.

It would also be nice to know the behavior of the Obi device, particularly at power up, with regard to under what circumstances the devices actually make connections to the ObiHai servers.  You mentioned the DNS requests but was a connection to the ObiHai server also performed with provisioning enabled and the service disabled?  I would suspect they would have to do that in order to determine the ip of the Obi so that provisioning could later be done if necessary and was enabled.  If not then it would seem that auto provisioning could only really take place if the ObiTALK service is enabled which of coarse would require a connection and thus could be used to determine the ip of the Obi device.

Of coarse a complete functional test of the connection attempts would have to be done with all four combinations of the two control bits (provisioning and service) and noting the server, port and protocol the connections take place on.

Quote from: stevea on May 15, 2012, 03:09:21 PM
The '**5nnnn' call causes the Obihai110 to make a tcp connection to 'root.pnn.obitalk.com' port 6800.  Some minor tcp traffic takes place however the identification number for the ObiHai110 is sent unencrypted.  Then it *appears* that an SSL.v3-like connection is setup on the TCP connection after exchanging some Obihai self-signed certs.  The openSSL certs sent to the Obihai are not verified via any public service like Verisign, however that doesn't mean they aren't verified against an in-firmware cache.   *Assuming* that the key exchange is secure and note the crypto selected (AES-256) is good  - then the content of the traffic after SSL setup is quite safe.  IOW the cert exchange and SSL means that Obihai device can be quite certain it is communicating to the Obihai server and not to a fake server, and the encrypted traffic is 'safe enough'.  The security issue is similar to the concept of pointing your web browser to your bank and accepting the https certificate as assurance you have the correct site.

SO *ASSUMING* the key exchange is secure, and the certs are verified from firmware .... an exploit requires an evildoer to steal the private crypto key from Obihai, install a DNS or IP routing exploit to send traffic to his evil-server with a matching cert, and then he must arrange for the '**5nnnn' sequence to be entered on the phone, then he must download evil-firmware to the Obihia or at least change the settings.

Not sure about that last pert of having to wait until a **5nnnn took place since that was not required when the push was performed last week.  We really do not know what is required to initiate firmware push.  The fact that a **5nnnn would cause one, even with the "control" bits have disabled tell us the process is completely at the desecration of the OBiHai servers though. Thus if the OBIHai server can determine your device's ip address then they have the ability to, as minimum, perform a firmware change so for all purposes they have complete control of your device.

Unfortunately to test the key exchange I think would require writing code to emulate the function of the provisioning server (including keys to further test the key exchange) and using iptables in the router to redirect traffic intended for the provisioning server to the emulator; which is a much harder task than testing normal communications.

Quote from: stevea on May 15, 2012, 03:09:21 PM
I am greatly reassured knowing that there some sort of secure connection on this channel.   I'd like to hear more about the cert verification issue - but so far I have no reason to doubt or distrust ObiHai's design decisions.

I wonder of the firmware download and ObiTalk remote settings use a similar secure channel ?

I agree that using SSL is a good practice and like you would be willing to assume that they also are handling the key exchange properly. (I admit I am too lazy to develop something to test that )  Hopefully the firmware download and remote settings are handled properly.  We know that OBiHai has the ability to push firmware updates at their will based on the fact they did last week.  Testing has revealed that the control bits in the OBi device do not control the functions in the device but rather simply pass the preferences to the OBi server which OBiHai can honor or not.

That leaves the possibility of flash updates being performed at inopportune times a major reason one may wish to disable auto provisioning.

Unfortunately as we have been told, in this thread, that currently also means one must disable the ObiTALK service.  Without the ObiTALK service I think the ObiApp becomes useless as well.

If one has to give up the functions of the Obi, then they may as well take the next step and block all connections to Obi in their border routers; once we have discovered all domain names/ ip addresses they use. 

For the customer to be assured they can keep from having firmware updates pushed to them basically all remote features of the Obi devices must be sacrificed.  I find this sad since as I suggested earlier it does not have to be that way.

RonR

Quote from: VaHam on May 16, 2012, 06:42:37 PM
I am handicapped at the moment since I loaned my only Ethernet hub to a friend and don't have it available to assist with wiresharking right now.

If your PC has two Ethernet ports, simply have Windows bridge them and have Wireshark monitor the bridge.  Modem/Router on one port, OBi(s) on the other.

Quote from: VaHam on May 16, 2012, 06:42:37 PM
Unfortunately as we have been told, in this thread, that currently also means one must disable the ObiTALK service.  Without the ObiTALK service I think the ObiApp becomes useless as well.

If one has to give up the functions of the Obi, then they may as well take the next step and block all connections to Obi in their border routers; once we have discovered all domain names/ ip addresses they use. 

For the customer to be assured they can keep from having firmware updates pushed to them basically all remote features of the Obi devices must be sacrificed.  I find this sad since as I suggested earlier it does not have to be that way.

OBi-to-OBi and smartphone calling can be accomplished using Single-Stage Dialing Through Any OBi Trunk Using SIP, which eliminates any reliance on OBiON Apps, the OBiTALK Service, and the OBiTALK Web Portal.

MichiganTelephone

Quote from: VaHam on May 15, 2012, 09:17:35 AM
In my opinion attempting to degenerate people who are discussing technical issues by using terms such as ("paranoid about security", "handful of complainers that are going to gripe", "dwell on the negative", "a few vocal complainers") is uncalled for. Genuine skepticism is very good thing and often leads to better ideas and products. From the preceding link
Quote"Pseudo-skeptics often are typically disbelievers - i.e. they are firmly entrenched in believing "no" about certain things. Although they may "claim" that they are open to new information, they typically react with strongly unfriendly if not hostile criticisms when their beliefs and assumptions are challenged by new ideas and evidence."

VaHam, my comments are really about the (in my opinion) one backstabbing person who tries to play expert/authority in this forum, then goes on BroadbandReports.com and appears to have some desire to trash Obihai's reputation any way he can.  It just amazes me that he still even uses Obihai products, given his apparently low opinion of the company.  When they try to help him, or fix bugs that he's reported, he gets mad because they don't consult with him before pushing a firmware update first, whereas typically a person would be happy that their problem was addressed.  And I think perhaps his negativity may have rubbed off on one or two others. so I say there may be "a handful of vocal complainers" but it's pretty clear there is one ringleader.  Most of this thread would probably not have existed except for his provocation, nor would the threads on BroadbandReports that kick Obihai all over the place.

I'm not saying this is an issue that should be hidden, and in fact I think Obihai did the wrong thing by deleting that entire initial thread, when they could have just deleted the posts containing the bad information.  But this has been a case of making a mountain out of a molehill.  When you think of Obihai's overall customer base, most of which bought an Obihai specifically to use with Google Voice, you have to realize that most are probably quite happy that their devices were fixed with no intervention on their part.  The only ones who are unhappy are the type that see "an enemy behind every tree", so to speak, and think that maybe someone's just chomping at the bit to hack their Obihai devices.  If such a thing had ever happened, I would be a lot more concerned, but I've never seen a bona fide report of anyone hacking an Obihai device.  Oh, and those who didn't want a firmware update were also unhappy, but most people do want firmware updates, particularly when they fix problems.

I'm not really upset that this issue has been discussed; in fact I wrote about it in a couple of articles in my blog.  But at some point a reasonable person would have to conclude, as I did, that there's not much to see here.  Yes, Obihai probably should have made it clearer how to disable firmware updates that come directly from Obihai, but now we know, and as I say, the majority of Obihai users don't want to do that anyway (and they shouldn't, in my opinion, except under special circumstances).  What does tick me off just a bit, even though it probably shouldn't, is the way one person can come into this forum and try to project the image of being the go-to guy for Obihai questions, then go into other forums and essentially trash talk Obihai devices.  How can someone do that?  WHY would someone do that?  Where is the loyalty?  Again, I'm NOT saying you can't ever criticize a product you like, heck, just about all of us have done that, but to keep beating the drum of negativity over this issue the way he's done is something else entirely.

And please understand that I am not feeling this way because I got free review units from Obihai - in fact, it would probably bother me a lot more if I had actually paid out of pocket for the devices I have, because then it would be as if he's attacking my wisdom in purchasing a device.  It would be like telling someone who's bought a new car that they just spent their money on a piece of junk, vs. telling someone who was given a free car that it's not the greatest brand ever made — you know which would be more likely to get you punched in the nose!

There are appropriate ways to address this issue and many of the posts in this thread have, in fact, addressed it appropriately.  But we must remember that it's not just us "expert users" that read these threads.  Suppose that a new user found this thread via a Google search — if he didn't fully understand what he was reading, he might come to the conclusion that Obihai devices have this huge security hole, when in fact that's simply not the case.  Just because something doesn't work the way one guy, or a few people think it ought to work doesn't mean it's insecure.  I appreciate those who have the expertise and have taken the time to run tests using Wireshark and provide actual information, not wild speculation.  I appreciate those who have contributed suggestions on how this problem can be addressed.  I don't appreciate those that just want to bleat constantly about what a bad company Obihai is because no one at Obihai will kiss their ring (or some other part of their anatomy) when they say something should be done a certain way.  Obihai is certainly not perfect (probably in part because they are a small company, and there are only so many hours in the day, and they are in the middle of rolling out new products) but they are a LOT more responsive than many other companies we interact with.  Ever tried to get a response from Google when you have an issue with Google Voice? You might have better luck trying to get the President (or Prime Minister for you Canadians/Brits) to come sit and have coffee with you while you tell him what's wrong with the government!

You made some good suggestions near the end of your post.  I'm sure the folks at Obihai will think twice before pushing any more automatic firmware updates but the fact remains that there are probably more people who are glad they did it then those annoyed by it — but most of those who are glad they did may never visit this forum.  So I think there is some tension between what is best for the "typical user" vs. what will keep the "expert users" that tend to hang out in this forum happy, and I'm not sure they will ever be able to keep everyone happy all of the time!
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

VaHam

Quote from: RonR on May 16, 2012, 07:03:30 PM
Quote from: VaHam on May 16, 2012, 06:42:37 PM
I am handicapped at the moment since I loaned my only Ethernet hub to a friend and don't have it available to assist with wiresharking right now.

If your PC has two Ethernet ports, simply have Windows bridge them and have Wireshark monitor the bridge.  Modem/Router on one port, OBi(s) on the other.

Good tip!  Basically as I admit I am lazy.  I have ethernet cards I could install in the desktop here however it has only one currently.  My Router and OBis, PBXs and other voip devices are located in a room at the other end of the house so it is not real convenient to move stuff around.  I usually just plug the hub into my border router and then temporarily move the cat5s from my desktop and the device under test to the hub when wiresharking. If it is one of the PBXs then I just use tshark running on the PBX and save the result file, download it to my desktop and run wireshark on it here.

Quote from: RonR on May 16, 2012, 07:03:30 PM
OBi-to-OBi and smartphone calling can be accomplished using Single-Stage Dialing Through Any OBi Trunk Using SIP, which eliminates any reliance on OBiON Apps, the OBiTALK Service, and the OBiTALK Web Portal.

Again good tips!  Yes those provide ways to regain most of what unfortunately one would have to give up if they have to block the OBi servers in order to have control over the OBi device.  I did however use the OBi console for configuration and have in the past recommended using it to new comers

I actually think OBiHai did a very good job of simplifying the provisioning process with their web portal, which is especially helpful to users who have never dealt with voip before, and found using the expert mode met my needs in customizing the OBis.  But, I have no problem myself with using device's own web gui to provision it either so to me that is not a big deal.

VaHam

Quote from: MichiganTelephone on May 16, 2012, 08:25:47 PM
I'm not saying this is an issue that should be hidden, and in fact I think Obihai did the wrong thing by deleting that entire initial thread, when they could have just deleted the posts containing the bad information.

I would rather see the title of this thread be something more like "A discussion of OBiHai firmware updating procedures". I don't like the idea of deleting entire threads either and this one certainly has not been.  The current title sounds like somebody is trying to hide something and I don't really think that is the case.  I also think OBiHai took the action they did last week to help the majority of their current customers using only Google Voice as do you.  The action did raise my awareness of the detailed workings of the device however; especially after I learned that even with auto provisioning set to off that it took place.  That then leads one to ponder all the other ramifications of that capability.  If auto provisioning cannot be positively disabled within the device one should examine all of the possibilities that may arise as a result of that.

You raised a very good point about inopportune firmware updates with regard to power stability during the firmware re-flash; one that hadn't even occurred to me up until that time, but has been known to cause problems in many other devices.   

As I said earlier even the remote risk of some security issue is not a big problem if your only using Google Voice and that if your using a paid sip provider that you could limit any big liability there by incremental funding and pay as you go.

I don't know if Google Voice will remain free forever which has no doubt been a big benefit to OBiHai sales.  I know the Obi device preceded free Google Voice and IMHO I prefer the OBi devices over other ATAs and think they will dominate in the future even if Google Voice ceases to be free.

I would think that practices which may be acceptable in a consumer product using only Google Voice and OBiTALK network may not be acceptable for commercial type use.  If I were an ITSP providing the devices to my customers I certainly wouldn't want updates pushed to them automatically. 

Quote from: MichiganTelephone on May 16, 2012, 08:25:47 PM
The only ones who are unhappy are the type that see "an enemy behind every tree", so to speak, and think that maybe someone's just chomping at the bit to hack their Obihai devices.  If such a thing had ever happened, I would be a lot more concerned, but I've never seen a bona fide report of anyone hacking an Obihai device.

Well in the big scheme of things the OBi's are fairly new devices so if there are vulnerabilities which could be exploited they may have just not been found yet.  So far none have been uncovered but I for one find it an interesting technical issue if nothing else to explore the possibilities before any thing bad could happen.  The OBi's would certainly make attractive targets for voip thieves.  There are or will be many more of them than PBXs to exploit, if they can be, and most are I suspect operated as you pointed out by novices.

I think the OBi's are great products but there is room for improvement even in great products.


QBZappy

I see that RonR has been punished. Anyone else notice it?
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

RonR

Quote from: QBZappy on May 17, 2012, 08:52:03 AM
I see that RonR has been punished. Anyone else notice it?

I was apparently demoted yesterday from 'Beta Tester' to simply 'Forum Member' with no rating.

Several posts that had resulted in getting users operational by having them log into their OBi's directly were also deleted.  Apparently, any suggestion of directly accessing an OBi is now grounds for censorship.

VaHam

#73
Quote from: RonR on May 17, 2012, 09:24:54 AM
Quote from: QBZappy on May 17, 2012, 08:52:03 AM
I see that RonR has been punished. Anyone else notice it?

I was apparently demoted yesterday from 'Beta Tester' to simply 'Forum Member' with no rating.

Several posts that had resulted in getting users operational by having them log into their OBi's directly were also deleted.  Apparently, any suggestion of directly accessing an OBi is now grounds for censorship.


I may not always agree with your opinions regarding the Web portal for configuration since I think it is pretty good and that provisioning via the device's web gui is probably better left to advanced users.

But I recognize the great amount of time and contributions you have made in this forum helping others!!!  My first experience here was responded to by you and your input was appreciated greatly by me.  If you were to get fed up and stop helping folks then I wonder if any one else would pick up that slack and respond to requests for help as prolifically as you have.

Alas, it turns out that currently the only way to keep firmware updates from being pushed is to disable all of ObiTALK services, then the web portal is also not usable so anyone who chooses not to receive the pushes will be forced to use your preferred method of provisioning directly with the devices web gui.

Ostracus

Quote from: RonR on May 17, 2012, 09:24:54 AM
Quote from: QBZappy on May 17, 2012, 08:52:03 AM
I see that RonR has been punished. Anyone else notice it?

I was apparently demoted yesterday from 'Beta Tester' to simply 'Forum Member' with no rating.

Several posts that had resulted in getting users operational by having them log into their OBi's directly were also deleted.  Apparently, any suggestion of directly accessing an OBi is now grounds for censorship.


Well aside from the deletion, does not being a beta tester really mean anything?

RonR

Quote from: Ostracus on May 17, 2012, 01:03:50 PM
Well aside from the deletion, does not being a beta tester really mean anything?

Nope.  Obihai stopped participating and responding to our questions in the Beta Tester's section long long ago.  New firmware releases are not previewed to Beta Testers before the general public.  'Beta Tester' carried no out-of-the-ordinary consideration whatsoever.

I'm actually pleased that I no longer have that designation in the forum as it has mistakenly led some users to think I'm affiliated with Obihai in some way.

stevea

More ...

With obitalk enabled, the obihai periodically sends a small (110 bytes of data) UDP packet from port 10000 to the server port 10870 and receives a ~424B return packet at regular intervals.  The packet content seems to NOT be encrypted in it's entirety since there are a few repeated header bytes and a few fields are 'common' between most packets.   However the data is binary - nothing easily decipherable.  I suspect the packets have a sequence number or reply code  embedded or something similar - since if the Obi doesn't get a reply then it resends the exact same packet repeatedly

The Obitalk reply packet (the ~400B ata transfer)  can clearly contain the commands telling the obidevice to download new obitalk configs, (which it then does via webdav to the obitalk website)  and likely also this mechanism command it to 'phone home' for an automatic firmware update.

Typical soho router firewall settings don't allow any external TCP initiation from outside to touch the obidevice.  Nor can UDP packets be addressed to the Obidevice unless the Obi first sends an outbound packet to that system.   So clearly the Obidevice has to initiate any route that permits Obiitalk to command an update.   It appears this ObiTalk periodic traffic is the mechanism.

I've found that
ObiTalk Provisioning == disabled
OBiTALK Service Settings, Enable = UNchecked

Is sufficient to prevent the periodic ObiTalk UDP messages.  And it therefore should prevent any externally generated control from ObiHai..

Firewall blocking UDP traffic to/from port 10000 on the Obi should enforce this decision.


Throughout this I think I've found potential means to examine someone's  ObiTalk settings  (again many requirements) ,but since the VOIP account passwords aren't there - it's not a serious problem I think.


carl

Quote from: VaHam on May 17, 2012, 12:18:21 PM
Quote from: RonR on May 17, 2012, 09:24:54 AM
Quote from: QBZappy on May 17, 2012, 08:52:03 AM
I see that RonR has been punished. Anyone else notice it?

I was apparently demoted yesterday from 'Beta Tester' to simply 'Forum Member' with no rating.

Several posts that had resulted in getting users operational by having them log into their OBi's directly were also deleted.  Apparently, any suggestion of directly accessing an OBi is now grounds for censorship.


I may not always agree with your opinions regarding the Web portal for configuration since I think it is pretty good and that provisioning via the device's web gui is probably better left to advanced users.

But I recognize the great amount of time and contributions you have made in this forum helping others!!!  My first experience here was responded to by you and your input was appreciated greatly by me.  If you were to get fed up and stop helping folks then I wonder if any one else would pick up that slack and respond to requests for help as prolifically as you have.

Alas, it turns out that currently the only way to keep firmware updates from being pushed is to disable all of ObiTALK services, then the web portal is also not usable so anyone who chooses not to receive the pushes will be forced to use your preferred method of provisioning directly with the devices web gui.

I absolutely agree with  VaHam. Ron's contributions were have been not only useful, but highly needed by many of us. In a way he has been providing the level of customer service in certain areas Obihai should, but does not. Obihai would have less customers and worse ratings = less business without him.
Unfortunately, this type of actions are quite common on proprietary support forums. One great advantage on the Magic Jack support forum was that it was independent ( off course who needs Magic Jack these days!).

Billt928

I know I'm new here and this is my first post, but been lurking a few weeks and I have been following this thread.

I do think that a few of you are



mrjoe

QuoteRon's contributions were have been not only useful, but highly needed by many of us. In a way he has been providing the level of customer service in certain areas Obihai should, but does not. Obihai would have less customers and worse ratings = less business without him.

I couldn't agree more!
RonR should be on Obhai's Payroll!

He has helped many of us.  I sometimes search the forum for "RonR" to read through his very informative and easy to understand posts.