Need extra help installing your Ooma Hub or Telo system? Let us know.
#55237 by jacque
Mon May 10, 2010 6:14 pm
Yes. Ooma is setup as a static IP at in its network pane, and the connection is set to "static ip". I have a matching reserved IP in the router reservation table and have placed the Telo's MAC address in my network access list. The IP is what I'm using to access the page in the browser; i.e.:

Something has happend in the few minutes since my last post. I switched to my laptop and tried again. Access to Setup (via the IP address) timed out twice, then on the third attempt the Telo suddenly woke up, the logo turned blue, the Home page loaded, and all the content now is available. Sigh.

Here's what it says, but this is while it's working, since I can't access it when it blinks:

Your ooma Network is Connected (161xxxxxxx)
Internet: Connected
Ooma Core: Connected
Phone Line: Disconnected
Ooma Services
Phone Setup: Your phone line is configured for the ooma network
Second Line: Enabled
Voice Mail: Enabled

Device Status - Rev: 1.36111

MODEM: Connected : []
HOME: Disconnected
Ooma Tunnel: Connected
Telephony: 526 - Running
DNS: 5798 - Running
Web Server: 519 - Running
VPN: 1614 - Running
Free: 206004


HOME Link encap:Ethernet HWaddr 00:18:61:04:E1:E0
inet addr: Bcast: Mask:
RX packets:305 errors:0 dropped:0 overruns:0 frame:0
TX packets:259 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:52881 (51.6 KiB) TX bytes:104367 (101.9 KiB)
MODEM Link encap:Ethernet HWaddr 00:18:61:04:E1:E1
inet addr: Bcast: Mask:
RX packets:13923 errors:0 dropped:0 overruns:0 frame:0
TX packets:8508 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1959642 (1.8 MiB) TX bytes:1147627 (1.0 MiB)
#55238 by sfhub
Mon May 10, 2010 6:20 pm
I think what you are describing as "waking up" is actually Ooma rebooting and taking a little bit of time to be ready to go.

I think something between your router and Ooma is causing Ooma to reboot every few hours. Before it might have rebooted and stayed red, never coming back up, but this time it rebooted and completed starting up.

Not knowing your previous firmware revision, I guess it is possible the reboot was just the required one after downloading new firmware. You currently have the latest firmware, so if it was a new firmware reboot, it shouldn't happen again.

Try doing the pingplotter stuff in the previous post.
#55239 by jacque
Mon May 10, 2010 6:24 pm
Maybe. The first time I noticed it though, it had been blinking all night, but you'd know better than I do.

Oh, incidentally, I did happen to swap cables. Since I had problems with the one Ooma supplied, I substituted a new patch cable I had. I didn't try changing the router port though.

It looks like PingPlotter is a Windows app, and I'm all Mac here. Macs come with some built-in network tools, including a ping utility. I'm not sure it does what PingPlotter does, but I can set the number of repetitions. All we'll get from that is basic time values though. I could search for an equivalent Mac tool, maybe.
#55240 by sfhub
Mon May 10, 2010 6:31 pm
Use whichever tool you want. I just want to visually see the ping response over time. I'm expecting your Ooma to stop responding at some point. I'm wondering if there is some associated behavior with the Internet connection to Ooma's servers.

With PingPlotter, it will give you the ping results over 48hrs and allow you to look back in time. So if you find your Ooma is red, you can look back to see what time it happened. Then you can look back at the ping results to Ooma's servers to see if anything happened around that time.

Actually you should probably do 3 pings

This will tell you (assuming your ping tool records results over time) if your internet route to Ooma went down or if your router went down at the time Ooma stopped responding.
Last edited by sfhub on Mon May 10, 2010 6:33 pm, edited 1 time in total.
#55241 by jacque
Mon May 10, 2010 6:33 pm
Found this, if I can figure out how to use it:

I'll see if it does what you describe. Thanks. By the way, Ooma asked me to fill out a satisfaction survey today. Basically I told them their tech support was not very helpful, but their customers were great.
#55242 by sfhub
Mon May 10, 2010 6:38 pm
Looks like one of the stats or log subpages might give you the history. It probably will do what is needed. Hopefully the trial version has what you need.

Here's another product that you might be able to try, they give you a 15-day trial of the full version:

I think you can also send email to ntoy (through the forum) and ask him to look at your Ooma logs to see if they say why your unit is going down or rebooting. Ooma devices are constantly sending log information to the Ooma server to record status information.
#55244 by jacque
Mon May 10, 2010 7:15 pm
Looks like this will work. I need to choose a protocol: ICMP, TCP, or UDP. The TCP protocol enables most of the various options, but isn't VoIP mostly UDP?
#55246 by sfhub
Mon May 10, 2010 7:58 pm
Usually ping is done by ICMP. You don't need to use the same protocol right now, we are just trying to figure out what the network looks like when Ooma goes red.
#55257 by sfhub
Mon May 10, 2010 9:55 pm
Under your dlink advanced->firewall settings, what do you have NAT EndPoint Filtering set to for TCP and UDP?

When you have time, you can try
1) removing the port forward we created in the Ooma setup pages
2) reboot Ooma
3) add Ooma IP as the DMZ (and enable DMZ) in the dlink advanced->firewall settings page

I suggested removing the port forward rule in Ooma because if you add the Ooma as the DMZ, then people on the Internet would be able to access your setup pages.

DMZ basically disables all the firewall rules for and forwards all incoming WAN packets to that IP address. See if Ooma still turns red. If it doesn't turn red anymore, then it means some firewall rule was not working well with Ooma.
#55276 by jacque
Tue May 11, 2010 9:22 am
NAT endpoint filtering for both UDP and TCP are "address restricted". That was the default, I've never changed it.

I couldn't run an all night ping test, the utility I downloaded seems to overload my Mac after a while. I ran it for a few minutes though and think I found my latency problem. The latency on a server (GBLX) 5 hops away is up to 796ms. There's another bad one 7 hops away, at 191ms. It's 9 hops to ooma, which is the IP I tested using TCP protocol on port 80. The average latencies on the other hops are about 72ms. So I guess it adds up.

The Telo did not go red all night. 13 hours later, this morning, it did. It is now blinking and I can't get it started again in spite of rebooting the router and the telo a few times. I will have to hook it up to an ethernet connection again and jog it back awake. That's a hassle, resetting everything and then undoing it all again to get my laptop back on the network. I let it blink for an hour to make sure it would not reboot by itself. Apparently the disconnect is not always within a 4-6 hour time frame, which means my overnight test when it was between the router and modem may not have proved anything.

I emailed ntoy last night but haven't heard back. I guess I'll try your DMZ suggestion later today, if I can get it rebooted.

Who is online

Users browsing this forum: No registered users and 9 guests