Obi202 Kaput

Ad Above Message List
Save the below block of code as an xml file and upload to the device. It should disable all the necessary components for automated provisioning.

***1 reads the IP back on the handset.

You sure you don't have multiple devices with the same ip on the network. The behavior you describe sure sounds that way. Or devices with the same mac?

Code:
<!--OBi Configuration File-->
<ParameterList>
<Object>
<Name>X_DeviceManagement.ITSPProvisioning.</Name>
<ParameterValueStruct>
<Name>Method</Name>
<Value>Disabled</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>ConfigURL</Name>
<Value/>
</ParameterValueStruct>
</Object>
<Object>
<Name>X_DeviceManagement.Provisioning.</Name>
<ParameterValueStruct>
<Name>Method</Name>
<Value>Disabled</Value>
</ParameterValueStruct>
</Object>
<Object>
<Name>X_DeviceManagement.FirmwareUpdate.</Name>
<ParameterValueStruct>
<Name>Method</Name>
<Value>Disabled</Value>
</ParameterValueStruct>
</Object>
<Object>
<Name>X_DeviceManagement.LUAupdate.</Name>
<ParameterValueStruct>
<Name>Method</Name>
<Value>Disabled</Value>
</ParameterValueStruct>
</Object>
<Object>
<Name>VoiceService.1.X_P2P.1.</Name>
<ParameterValueStruct>
<Name>Enable</Name>
<Value>false</Value>
</ParameterValueStruct>
</Object>
</ParameterList>
 
Ad in Threadview Above Message Content
Thanks - much appreciated! Much quicker with the xml.

Checked ***1 (this time with a dial tone before dialing (dumb me) and IP is the same. Think I'd better wait until tomorrow and after some sleep before doing any more on this.

I let the router assign IP's. Nothing done manually. The only "exotic" thing I'm doing with the router is blocking internet ports on a Windows7 DAW so I can have it on the LAN here without worrying.

I double checked and have no duplicate IP's or MAC #'s (I didn't know duplicate MAC's were even possible.) You did give me an idea though. I backed up the router settings and am thinking of doing a hard reset before anything else, just for drill.

It's been quite a few months - probably before the Obi end-of-life deadline - since I actually got into the Obi's config. I had no problems at all at that time, same as every other time I logged in previously. I first noticed the admin config page problem last weekend, at the same time as the intermittent tel line and disconnect problem started although it could have gone bad before then.
 
@GPz1100

Maybe I'm over thinking here but after a week of trying to determine whether this is a hardware or software problem, and being no closer to a definite answer, I had a question.

Would disconnecting from the ObiTalk portal potentially remove or delete any of the certifications you were interested in recovering? If so, maybe it would be better to proceed with the modded firmware upgrade and retrieve the certifications in case this is a hardware issue and my Obi200 is in fact dying.

I wanted to avoid confusion and wasting the time of the modded firmware folks if hardware issues caused their firmware to not work on this particular Obi.
 
Since you've applied that xml file with the config changes above, that effectively divorces the device from the obitalk portal. Any changes made on obitalk will not make their way to the device, unless you factory reset the device. In that case, you will need to block internet access for the device somehow so you can upload and apply the xml again. You would want to enable the block before doing any factory resets.

If you applied the modded firmware, you should be able to ssh to it and login as obi/root. Then you can run param_dump and the extract_keys binary to obtain the various parameters and certs.

In short, the only way changes on obitalk portal would affect the actual device is by enabling the cloud provisioning options on the device itself.

If it were my device, I'd gather what I need from it then factory reset and provision manually - request the howto file from naf on dslr if you haven't already. If the device still acts up, consider it starting to die a slow death. I have 2 ht802's on hand as backups from 6 years ago, just for when the obi's cease to function.
 
Your description sounds exactly like mine. If you log into the website for your Google Voice line, is the Obi shown as a forwarding device?


I am actually having the same issue with an OBI200. Started a few days ago. So, I highly doubt any of this is hardware related. I'm going to do some additional digging. I hope one of us finds a solution.
 
Maybe obi is pushing self destruct codes to the devices to break gv functionality?

Now we're getting somewhere!

@ikebytes - I've been wondering if/when more would be checking in with this same issue.

@GPz1100 - Thank you for saying this. I've been thinking the same for a while but didn't want to say it.

I've been watching Obi LED and my cordless Panasonic phone status. There seems to be a definite connection between the two in regards to how the phone is cycling between normal, line in use, check tel line, and back to normal.

When Obi200 says "connected" on ObiTalk portal my cordless phone will go through the cycling I mentioned above. It'll go between line in use and check tel line several times than will lock into "check tel line" for a longer period. Then the port LED will do a maybe 1sec off and back on, then the cycling will begin again.

Right now, this process has gone for about two hours and now I have a long lasting "check tel line" on the cordless phone readout. Logged into ObiTalk portal and Obi200 is off line. Just got the "SIP Offline" email from Anveo so the Obi has been online this time for 2hr 8m. I've seen it disconnect in a half hour - it's been all over the place as far as how long it will stay connected.

This pattern between Obi port, LAN and phone LED's has seemed very consistent, almost a loop or something. Powering down the Obi200 will start this same process again. It looks like the LAN LED is actually signalling the hardware. I wasn't sure whether hardware or the outside world was causing the problem and now think maybe it's the outside world.

Obi200 is definitely unusable the way it is so hopefully some experimenting will figure out the solution. Trying to figure out a way to proceed now. I haven't applied the ObiTalk divorce xml yet.

Will contemplate your suggestions, @GPz1100. And definitely open to any suggestions. Maybe first do the "divorce" and see if that fixes?
 
By now my stance on the matter is probably well know. IMO cloud == evil. I was never a fan of any cloud controlled device. Sadly with some we have no choice. I can't disconnect my ecobee from the network if I want to use third party projects like beestat with it. Beestat takes in the raw data - usage, temp, time, outdoor temp, etc and presents it in a manner far more useful and meaning than ecobee's homeiq(less) ever could (https://beestat.io/).

The only issue we've ever had with the obi's is the occasional gv glitch where outbound calls don't work - something about the device not having received a valid response from the service provider. This happens occasionally. Since implementing a nightly restart of the obiapp (main service on the device that interacts with google voice) the complains of this have becomes less.

So, i don't know what's going on, but it seems too coincidental for a number of people to experience the same issue(s) at the same time.
 
By now my stance on the matter is probably well know. IMO cloud == evil.

snip

So, i don't know what's going on, but it seems too coincidental for a number of people to experience the same issue(s) at the same time.

Totally agree on cloud contolled devices - I won't have one. I got stung on an internet radio that required a station aggregating website to work. When Reciva (aggregator) got taken down, apparently many radios of several different brands that depended on it got bricked! Don't want a house, car, refrig or anything else that can easily get "broken" via remote control.

This is not the first time some tech company virtually walked into my house with their "end of life" sledgehammer, walked out smiling and left a pile of junk behind. But this time there is at least one work around with the modded firmware.

As a close friend of mine said, "They used to sell you happiness. Now they want to rent it to you." Funny, I checked to see whether his Obi200 was still working last weekend - it was. Will see how they are doling out these shut downs, if they are indeed doing that.

Thanks for talking and the guidance. It's really helpful for working through problems like this.

I think I will first see what happens by disconnecting from the ObiTalk portal. Even if that works, I think the modded firmware will still be the way to go but at this point, I'm curious to see if this is another corporate sledgehammer.

I haven't ever worked with xml. I'm assuming all I have to do is highlight the Obi config settings you posted, copy and paste them into Notebook++ and save as xml file?

Then I'm assuming I would use the Obi "restore configuration" process to upload your xml and it would only replace the specific items related to ObiTalk portal and leave the rest of the config alone? I can always restore the config I just saved.

Thank you.
 
Here's a graphical version of the xml code.

HjVNBPR.png

dRjEdBd.png
 
Seems o be working now.

Thanks GPz1100. I've had it working for over an hour now. Decided to do it manually. Details :

I appear to have a working Obi again but for how long, I'm not sure. The problem is definitely not a hardware issue!

I decided to manually disable Auto Provisioning 1 step at a time instead of using the XML script in order to see which disable(s) might work.

Disconnect cable modem from router
Reboot both router and Obi200

Log into Obi200 config webpage
1st pass
Auto Firmware Update - "Disabled"

Reconnect cable modem and reboot both router and Obi200
Problem remained - still cycling between line in use, check tel line and normal
Auto Firmware Update Was reset to default again after put online

2nd pass
-Auto Firmware Update - "Disabled"
-LUA Script Update disabled
-ITSP Provisioning - "disabled"
-OBiTalk Provisioning - "disabled"

Reconnect cable modem and reboot router/Obi

Seems to all work now. No more cycling between "line in use", "check tel line", normal operation. Get an immediate dial tone when phone is off hook. Can dial in from cell phone to GV. Can dial out from cordless phone with GV to cell phone. I can even get into the Obi config web page again with no problem and page around to various categories. So far, no "SIM Offline" emails from AnveoE911.

THE DOWNSIDE : I looked at the ObiTalk portal and my Obi was showing "connected". If it actually is, I guess the Obi200 is still using Obi's servers for OAUTH and/or a connection to GV. It seems likely that when Obi dumps the Obitalk portal completely, the phone will stop working permanently.

My many years well justified cynicism towards big tech makes me wonder if they are indeed doling out the death of the Obi hardware gradually for whatever reason? But that is just speculation.

Next step is to contact NAF at DSLReports for "how to" instructions for his/her new firmware per @GPz1100's suggestion.
So far, one hour up. Will see how long that lasts. But again, no cycling line problems - dial tone is available anytime I pick up phone.

I've now got hope that this problem is fixable!
 
Last edited:
That's good news. I'm out and about for a few more hours. When I get back home, I'll try what you did on mine and report back.
 
That's good news. I'm out and about for a few more hours. When I get back home, I'll try what you did on mine and report back.

Still up here, no problems. If it works for you, I'd be interested in knowing what the status of your Obi is at the ObiTalk portal web page.

Gotta say - after a week of pulling my hair out, I've been walking around the house and picking up the phone just to get the pleasure of hearing a dial tone! HA.

But again, I'm thinking this is probably only temporary until Obi/Poly/HP dumps the ObiTalk portal.

Got stuff to catch up on here that got postponed this week. For some reason.
 
Status on obitalk should be disconnected/offline or equivalent. It should NOT be able to communicate with device at all.

Thinking about the offline provisioning process (for gv), it's mostly entirely google based. There is one point where it tries to redirect to obitalk, but that should fail given instructions explicitly say to block obitalk - ie 127.0.0.1 www.obitalk.com or such in hosts file.
 
Status on obitalk should be disconnected/offline or equivalent. It should NOT be able to communicate with device at all.

Thinking about the offline provisioning process (for gv), it's mostly entirely google based. There is one point where it tries to redirect to obitalk, but that should fail given instructions explicitly say to block obitalk - ie 127.0.0.1 www.obitalk.com or such in hosts file.

"should be disconnected/offline or equivalent."
That's what I would have thought but my ObiTalk dashboard shows a green light and Obi200 "connected". Sounds like the Obi200 is not actually connected and the connection might stay up until GVoice changes something. Maybe there is something else in the provisioning that I should have disabled that is allowing this condition.

Obi200 is still up and phone is working great. Up over five hours now. Really nice to have the phone back.

Was thinking about your "duplicate IP #'s" question and was wondering whether it was possible to spoof IP #'s at ObiTalk's end thus causing the GUI collision I was seeing here? I have had NO problems at all with getting into the Obi200 config GUI - it's working as it always used to work before the whole mess started last week.
 
Try making a setting change in obiportal for an unused SPx. Obiexpert should expose the same settings as on the webui. I'd test this myself but that garbage isn't exposing any of the expert settings for the remaining obi device still on file there.

Frankly, if it was me, after getting the custom fw on the device and instructions how to configure gv offline, factory reset while disconnected from internet, disable all the phone home settings, then configure gv manually from scratch. I assure you, the device WILL be divorced permanently from the portal. This is the method I used to be assured there's no obivirus affecting the device. Get a full backup first though, just in case you need to tweak some setting later, but don't actually restore the backup, just view it in notepad++.

It is possible to spoof anything, ip, mac whatever, just need to know how. I remember coming across some nics many years back that had the same mac address encoded. It created quite the mess on the network until i realized what was going on. Using a vendor provided tool I was able to change them to unique entries. This is still even possible with intel nics today. When you have devices with the same ip or mac on the same network segment, you'll get the behavior you describe. Sometimes can access the device, other times not.

There is a mac entry in the obiui on the status page. That should match what's on the label of the device. As for checking other devices, executing arp -a from the firewall should reveal macs (and ip addresses) present on your network. Checking for ip conflicts is more difficult. Probably need to check assigned ip for each device somehow.
 
okay. Here's the deal. I changed what you changed.
So, for auto firmware update, I went from periodically to disabled.
Lua script method - went from system start to disabled
itsp provisioning - went from system start to disabled
obi provisioning - went from periodically to disabled

Obitalk obi dashboard does show connected.

obistatus.png

So far it is working!!!!! Thank you!
 
okay. Here's the deal. I changed what you changed.
So, for auto firmware update, I went from periodically to disabled.
Lua script method - went from system start to disabled
itsp provisioning - went from system start to disabled
obi provisioning - went from periodically to disabled

Obitalk obi dashboard does show connected.

View attachment 174570

So far it is working!!!!! Thank you!

Good news! Thanks for the update. Welcome.
I've been wondering about that green "LED". Maybe I'm imagining but I keep thinking it was actually a lot brighter green when the Obi hardware actually was connected.

I discovered a Google Voice post after I got mine back online around the same time a friend found and sent the link. Will post it after this.
 
For anyone else who shows up here wondering why their Obi device shut down, this Google Voice help post should help in getting your Obi back up a lot faster then I was able to get mine working again :

https://support.google.com/voice/co...e-with-obitalk-devices-after-12-18-2023?hl=en

I discovered this after getting my Obi200 back up and a friend sent it to me a short while later. Read especially the last section!

Sure would have been nice if HP/Poly/Obihai would have sent an email alert advising about their Obi device EOL. If they did, I sure didn't get it. The "digital" age strikes again.
 
Last edited:
@GPz1100 - I definitely plan on getting the third-party obifirmware running! Thanks for your help, time and suggestions!

After some thought, since my Obi200 is working again I think I will delay any third party firmware mods to it until they are necessary.

If there is another problem like this in the near future, maybe I'll just spring for a barebones pay VoIP that supplies it's own hardware interface. That way, any changes will be the responsibility of the VoIP service.

Maybe by the time that Google makes changes that prevent Obi devices from working, the Obi hardware itself may be close to or have already failed?. Got my Obi200 in 2018 and my Obi110 in 2014 and a lot has changed since then. I'm guessing there are more changes to this technology on the way. Maybe there will be new hardware that works with Voice? Could be a lot of options soon.

Anyway, I've got several projects that got put on hold because of the rude interruption of my phone service last week and I'm looking forward to getting back to work on them.
 
Last edited:
Back
Top