Ooma Hubs unable to connect Dec 2021

[ww4397]

Problem fixed. Did the factory reset BUT it took a few minutes after doing the reset until all was back to normal.

I thought the factory reset had failed based of the fact that the red lights were still on after the reset. I walked away figuring I'd try again later. After a short while I picked up the phone just for the heck of it and, "miraculously," I heard dial tone. Made a call and it worked. Received a call and that worked too.

Good luck everyone.

[FerrariGuy]

I've not been able to spend much time with my OpenWRT firmware on my Netgear router, so I don't yet have OpenWRT instructuions, but someone else on the Reddit forums ALSO had success it with a redirect wwith a Ubiquit Edge router.

Quote:

I'm using an Ubiquiti Edgerouter ER-X and someone on the Ubiquiti forums told me how to redirect traffic meant for 208.83.244.20 to 208.83.246.20. Once I did that, my Hub came to life. It did reboot several times but then settled down and now I can make and take calls.

For those with a Ubiquiti Edge router, you do the following:

go to the Firewall/NAT tab
click on NAT
Add a 'destination NAT rule'
Inbound interface switch0
translations 208.83.246.20
all protocols
Dest address 208.83.244.20

So until or unless Ooma is able to address the backbone routing issue outside of their network and outside (probably) of their direct control, this is what we'll all have to do. And might be the key to keepting these things alive with future problems.

[FerrariGuy]

Sadly Engineer support above Tier 3 didn't really answer or even seem to address the problem seen by tracert from command prompt.

The response recieve was

"I've confirmed that the IP ranges are 162.253.220/22 and 208.83.244/22 (CIDR notation)
so that is ranges: 162.253.220.0 to 162.253.223.255 | 208.83.244.0 to 208.83.247.255

Or for easier troubleshooting, you might also want to try to temporarily turn off your router firewall and see if your Hub will turn back up 10-20 minutes after."

Which says nothing that we don't alreay know or can't find out just by looking up Ooma's owned IP ranges.

There's zero response about testing the actual pathway to the specific IP's that are apparently hard coded into the Ooma Hubs from different locations. And sadly some of Tier 3 support doesn't even know what a Tracert is or why it's an important diagnostic tool. It's unclear if the problem was properly communciated with Engineering or not even though they insist that it was. If it was Engineering gave a non-response. The problem has been run back up the chain but I suspect the only solution for some of us is going to be to buy equipment that will let us manually redirect the queries ourselves. Very dissapointing.

[7605573590]

My hub has been down for a week, ever since I experienced a power failure. It showed 1 and 2 in red. I did a factory reset by removing power and holding the OOMA tab on the rear, applying power and continued to hold the tab for 30 seconds. After a minute, my OOMA was back online.

[FerrariGuy]

Ok my Ooma is back up and running, proving there is NOTHING wrong with the hardware, this is a communcations issue that no one seems willing to solve.

Here's what I had to do in OpenWRT firmware:

Simply: Navigate to "Firewall" under the "Network" dropdown. Click the tab that says "Firewall Custom Rules"

Add these two lines (you could vary the destination IP to Ooma DNS or NTP servers probably instead of using Googles) after whatever is there.

iptables -t nat -I PREROUTING -d 208.83.244.20 -j DNAT --to-destination 8.8.8.8
iptables -t nat -I PREROUTING -d 208.83.244.21 -j DNAT --to-destination 8.8.8.8

My Ooma tab INSTANTLY went Blue, and I could see that DNS and NTP traffic was passing multiple and larger packets rather than attemtping the single opening packet.

Its sad when an end user knows more about what's going on (technically) than the service providers themeselves - and that's I guess not saying much. I can say at least one Ooma Tier3 member *tried* her best to help.

[7605573590]

My hub failed with solid red 1 & 2. Did a hard reset and that fixed the problem.

[FerrariGuy]

Well there's a new discovery.

After fixing the communicaiton issue with the firewall DNAT fix, the OOma is now suddenlty able to ask for and communicate with different Ooma DNS servers AND has a new update code:

When all this started it was stuck at: (Device Status - Rev: 63962.63962)

Now it has Device Status - Rev: 105153.105153

So it almost seems like the communcaiton redirection was needed dto bootstrap the device into being able to download an updated firmware so that it could talk to different IP addresses. I now see NTP communcation to port 123 of IPs like 208.83.246.21 and 206.81.5.45

[xBroker]

Did the factory reset procedure, a number of times. It had 2 lights on before. Now it has 6 lights on. Either way, it does not work. Not sure what 6 lights means... probably means don't try that again. No phone service for 2 weeks now. ..

[FerrariGuy]

xBroker, if it's all 6 right buttons red its probably 3 combined things:

top two: Cant talk to the Ooma network (reason for this thread)
middle two: no IP from the router/gateway - check your cable / reboot. It's probably not getting an IP assigned to it.
bottom two: a reasult of the top two... wont' detect a phone line/phone without FIRST connecting to the Ooma network.

IF your problem is like mine the ONLY clear solution is to do what the rest of us outliers have had to do... and force it to talk to reachable DNS and NTP servers. ONCE that has been done it very much looks like it DOES get a new firmware update which lets it then talk to new working reachable IP addresses without the temporary advanced technical help it needs to bootstrap it to that point.... Otherwise you may be waiting for Ooma to clear up the communicaiton issue to .244.20 and .244.21 which may or (looks like may not) happen.

[xBroker]

xBroker, if it's all 6 right buttons red its probably 3 combined things:

Wow.. Often all these acronyms overwhelm me & I just chalk it up to no interest in anything remotely related to programming language. Despite this mental block, I was able to see the logic in what you said. . I ran the incoming fiber wire to an unmanaged switch and connected the ooma to that; and the satanic magic took hold. It ran its course and fired up.

I think my blue light of life might be dead or something. Can't remember seeing that in a long time; but the ooma appears to be finally working. I still have to figure out what I unplugged to get the rest of the house going, but what a relief to have a phone to use again after 2 weeks. I had tried this set up before, but that was before I had learned about the factory reset ritual.

Afterward, I it started working, I hooked everything back up the way it is supposed to be, all wired 'after' the router and it still works. So, true to what you said it would do, I guess it did it. Seems to me, they could have just sent us a firmware update we could have plugged into the ooma usb port... Thank you FerrariGuy!! I really did not want to migrate to another phone system after all this time with ooma. I'm going to go back to the ooma pay service, even though I don't really need it. 120 a year isn't terrible..