OOMA DNS Issues

[johnnywoz]

The short story: my OOMA Telo is making huge DNS queries which then cripples my RT-AC88U (running latest Merlin firmware) and thusly causes all my other devices to lose their internet connection.

When looking in the syslog, I see OOMA (10.0.10.11) making a bunch of DNS requests to my custom DNS setting (1.1.1.1) and then to also Google DNS servers;
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.4.4 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=51017 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.8.8 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=51017 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=1.1.1.1 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=51017 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.4.4 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=44129 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.8.8 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=44129 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=1.1.1.1 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=44129 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.4.4 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=16159 DPT=53 LEN=55
Jul 19 09:31:13 kernel: ACCEPT IN=br0 OUT=eth0 SRC=10.0.10.11 DST=8.8.8.8 LEN=75 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=16159 DPT=53 LEN=55
it goes on and on...then eventually I get this;
dnsmasq[32016]: Maximum number of concurrent DNS queries reached (max: 150)
and the cycle starts over. The only way to get a reliable internet connection is to unplug OOMA.

The long story: I have had a OOMA Telo since 2013 which has worked fine (as far as I know) until recently when one of my IOT devices started dropping off my 2.4 wireless connection. After a ton of troubleshooting that device I found that my 2.4 wireless was having issues and then also noticed my internet connection would slow down from time to time. So I did a factory reset of my router (an older ASUS RT-AC also running Merlin), but the issues continued. So thinking my router was bad (or hacked) I replaced it with the AC88U. And still the issues continued. So I dug into the SYSLOG and found the OOMA making these DNS requests and I promptly contact OOMA support. After a bunch of troubleshooting they replaced my Telo with a new model (very good customer support), and the issues still continue. The only other thing I could think of was that I did just start using the ASUS AiProtection feature, so I turned it off, OOMA still making a ton of DNS requests.

And now I am here on the forum to see if anyone has seen this before and knows what to do about it. My next step is to factory reset the new router and do the most basic of setup just to get the router running and see if OOMA still has problems.

Thanks in advance for your input.
-John

 

[ColinTaylor]

Do you have anything configured or installed on the router that would interfere with normal DNS resolution, like ad-blocking or DNSFilter?

It seems strange that you're getting an error message from dnsmasq but the syslog only shows requests heading to 1.1.1.1, 8.8.4.4 and 8.8.8.8. My guess would be that the OOMA is trying to resolve a particular name but for some reason it is not able to do so, hence it continuously retries the request.

My next step is to factory reset the new router and do the most basic of setup just to get the router running and see if OOMA still has problems.

That would be my next suggestion.

 

[johnnywoz]

Do you have anything configured or installed on the router that would interfere with normal DNS resolution, like ad-blocking or DNSFilter?

It seems strange that you're getting an error message from dnsmasq but the syslog only shows requests heading to 1.1.1.1, 8.8.4.4 and 8.8.8.8. My guess would be that the OOMA is trying to resolve a particular name but for some reason it is not able to do so, hence it continuously retries the request.

That would be my next suggestion.

No rules or filters or third party, except for the AiProtection which is currently off.

 

[st3v3n]

Johnnywoz; We've had an ooma box for 5 years. There've been several times we've seen the logs fill up with similar material and it's always when latency is at it's highest.

The box has always connected no matter how we set it up on our router but performs best, on it's own OpenVPN tunnel. It always locks on to ooms's servers in a minute or two. Our ISP doesn't need to copy all our call detail, the tunnel gives us a bit of security rather than dumping it into the ISP servers.

Unless you have a business account/service with ooma, you're stuck dealing with their service in Manila. When ours went down, ooma's foreign customer service was clueless.. Since they didn't know what to make of the copy of router logs re our telo, that the tele would work if we would plug it 'into the internet' ahead of our router, but the ISP only allows the router MAC. Unfortunately, Ooma is the only US company that forces it's non-business VOIP customers to speak to overseas customer service, the number one source of complaints.

Your logs appear similar to the errors we saw prior to the box locking up last year. It seems that every now and then ooma pushes upgrades to certain units without notifying owners and if the update falters, it bricks the box, with no user recovery possible. On the day after we noticed an increase in the volume of log entries the ooma box rebooted, then locked itself into a never-ending loop of flashing red signals, never completing the boot or connecting to the ooma servers. We followed all troubleshooting guides for a full day, then emailed their regular customer service, which only made things worse. Ooma always replied with same scripted response, telling us to call them in Manila. We'd gone with ooma's box when we decided to cut the cord, and couldn't call them; they could never accept that we had no 'mobile'. Manila first said the problem was due to a failed router, then they tried to blame it on our ISP, and then they asked for system information that made no sense at all, mentioning something about windows updates. What a hoot.

When they advised us to take the box to a neighbor's house, to use the neighbor's phone to call them for additional troubleshooting, or that we could try 'buying' another ISP to try to fix the failed box, we called off all further dealings with Manila. There are no other ISPs in our area and windows has nothing to do with an ooma box.

We wrote a snail-mail to the corporate headquarters the next day and posted it on their customer web forum. Someone finally emailed an apology, and asked us to turn the telo back on so they could attempt a log in to work with what was obviously the failed update to the box. They over-wrote the errant update and 20 minutes later, the box rebooted and we've had no further issues.

This issue is a small but consistent batch of ooma boxes whenever they ram these updates through; when they fail and brick the box it can be quite frustrating. Ooma's saving grace is that even with their E911 tax scam, ooma is still cheap, and the box still works. The next time, we're moving to SIP.

We'd have never discovered the source of the problem if we hadn't spent a great deal of time searching, then combed through their user web forum; if ooma hadn't finally responded, it would've been shipped back to the company, and after posting consumer complaints to various platforms and agencies, we'd have jumped ship them. Many users never get a meaningful response. If your box doesn't beging behaving, or the errors become worse post on their web forum, and request an admin escalate your issue. If you have an alternate phone you don't mind trusting them with (not one you'd want to post in a forum) they might have a competent tech call to help sort it out before the box locks up.

Ooma must be getting desperate, or more than they've been previously. Over the last six months ooma has begun playing games by shifting monthly billing dates for customer's credit cards. It always was on a certain day each month, but would vary from one month to the next, never the same date twice. We didn't discover it until the next statement but talking to them does no good. During the same period they began emailing customers product marketing spam;, definitely not cool, and always the quickest way to lose formerly loyal customers. Hope this was of some use and hope you get your logs and ooma box where they should be.