Nest Protect cannot connect with DoT enabled - RT-AX88U 384.18

[nickp85]

I was able to enable dns filter to send my Protect to Google DNS while everything else uses my configured DoT setting. It came back online after reconfiguring WiFi and now I’m hoping it stays that way. Hopefully there is a more permanent solution in the works.

 

[aletaziar]

I was able to enable dns filter to send my Protect to Google DNS while everything else uses my configured DoT setting. It came back online after reconfiguring WiFi and now I’m hoping it stays that way. Hopefully there is a more permanent solution in the works.

Did you have trouble getting the Nest to use Google DNS via DNSFilter? I've been trying that solution but it hasn't worked for me. The only thing that works is turning off DoT entirely.

I'm using an AiMesh network of an AC88U main router and AC88U and AX68U nodes. All three are running Merlin 384.18. My WAN DNS is set to 1.1.1.1 and 1.0.0.1. I was trying to use 8.8.8.8 as a custom DNS in DNSFilter for the Protects, but they lose the network if I do that with DoT enabled.

 

[CriticJay]

Anyone continuing to have Nest Protect or Samsung SmartThings DoT issues should consider trying 384.19 beta 1 - since RMerlin has upgraded to dnsmasq 2.82 on it, which may help with some issues (testing needed)

Personally, my single Samsung SmartThings device is working fine with 384.19 beta 1 / DoT enabled.

 

[wraithdu]

Does 384.19 beta 1 include this fix in getdns? It implements name compression from the upstream response, which would mitigate the IoT issues.

Issue #430 listeners reply returned wireformat · getdnsapi/getdns@bda845c

So that proxies based on `getdns_set_listen_addresses()` reply with compression from the original response.

github.com

 

[Kingp1n]

Does 384.19 beta 1 include this fix in getdns? It implements name compression from the upstream response, which would mitigate the IoT issues.

Issue #430 listeners reply returned wireformat · getdnsapi/getdns@bda845c

So that proxies based on `getdns_set_listen_addresses()` reply with compression from the original response.

github.com

I followed nickp85's advice and used DNS filter option to send my Nest Connect to google's DNS and I haven't had any issues since. I'm running the 384.19 beta as well.

 

[john9527]

Neither the 2.82 dnsmasq final or the new (released 3 days ago) getdns patch fixed the problem on my fork.

 

[wraithdu]

I didn't see anything in the dnsmasq release notes that would have mattered, but the getdns patch should work. Assuming it's working as intended and doesn't need a config to activate it.

On your fork where you applied it, what's the dig response look like for frontdoor.nest.com ? If it's working the response size should be less than 300 bytes when not cached by dnsmasq.

 

[wraithdu]

So I spent last night getting the FW to build with the getdns patch, and it looks like it's working. The dig response size is what I would expect.

 

[wraithdu]

And an alternative to dns filter for those using postconf scripts.

dhcp-mac=set:nestp,18:b4:30:*:*:*
dhcp-option=tag:nestp,option:dns-server,8.8.8.8,8.8.4.4

 

[nickp85]

Did you have trouble getting the Nest to use Google DNS via DNSFilter? I've been trying that solution but it hasn't worked for me. The only thing that works is turning off DoT entirely.

I'm using an AiMesh network of an AC88U main router and AC88U and AX68U nodes. All three are running Merlin 384.18. My WAN DNS is set to 1.1.1.1 and 1.0.0.1. I was trying to use 8.8.8.8 as a custom DNS in DNSFilter for the Protects, but they lose the network if I do that with DoT enabled.

Still running standard 348.18 on an AC86U and haven’t had any issues with Protect since enabling it for DNSFilter to use Google DNS.

 

[wraithdu]

@john9527 , my test shows the getdns patch works. Can you try again and see what dig shows? If both of us can confirm the fix, maybe @RMerlin can pull it into 384.19 .

 

[RMerlin]

@john9527 , my test shows the getdns patch works. Can you try again and see what dig shows? If both of us can confirm the fix, maybe @RMerlin can pull it into 384.19 .

There is enough time for me to pull it in ahead of the beta 2 release. That beta cycle should be enough time to test it to ensure it doesn't break anything else.

 

[aletaziar]

Anyone continuing to have Nest Protect or Samsung SmartThings DoT issues should consider trying 384.19 beta 1 - since RMerlin has upgraded to dnsmasq 2.82 on it, which may help with some issues (testing needed)

Personally, my single Samsung SmartThings device is working fine with 384.19 beta 1 / DoT enabled.

I updated to 384.19 beta 1 on my router and two nodes and it still wasn't working yesterday. Today I decided to toggle off/on the DNS Filters for the Protects and the DoT for the whole router. Did that a couple of times, no rebooting, and now the Protects connect.

For anyone else testing this, you should keep in mind that even when everything is working correctly the Protects seem to occasionally fail their network check (long press of Nest button). My Protects successfully check their network connection perhaps every 3 out of 4 times.

 

[wraithdu]

384.19 beta 2 is working for name compression on the DNS response.

I will have to remember however... remove any USB drives and reboot before flashing. I just spent 3 hours fighting through fw rescue mode and the restoration utility to recovery flash the fw to get my radios working again. How is this still a bug in asus's flash process? There doesn't seem to be any way to recover except to flash in rescue mode. I tried all the resets, the nvram script utility, downgrading / re-upgrading. Nothing worked except the restoration utility.

 

[L&LD]

@wraithdu the following steps work for me every time on many different router models. aka 'Dirty Upgrade'.

Release - [Beta] Asuswrt-Merlin 384.19 beta is now available

Dirty flashed from 384.19_alpha4 to 384.19_beta1 and lost my internet connection. Dirty flashed back to 384.19_alpha4 and my internet connection was available again. Bit short on time now to look at the logs. Router model RT-AC86U. Hi, to correct my issue. First of all I noticed no code...

www.snbforums.com

 

[wraithdu]

Thanks. That USB removal is a nasty surprise. Odd, I didn't have problems when upgrading to test my .18 build, coming from Merlin's .18 build. But it all went to hell trying to go to .19.

 

[john9527]

384.19 beta 2 is working for name compression on the DNS response.

Yes, it's working,...but it's not a fix. My test case domain DNS response is about 1300 bytes without compression....with compression about 700 bytes and still fails the DNS lookup. At this point the only 'full' fix is to disable the check in getdns.

At this point, I still don't believe we know the root cause in the interaction between dnsmasq and getdns.

 

[wraithdu]

I think the root cause is understood... These IoT devices don't expect / support truncated responses.

The getdns dev also said he'd create a feature to allow disabling truncation, which would restore prior behavior. I haven't seen that code checked in yet. Keep an eye on that getdns issue and the commits, hopefully something soon for your issue.

What's your domain test case?

 

[john9527]

I think the root cause is understood... These IoT devices don't expect / support truncated responses.

No....I recreate the problem just running ping/nslookup directly on the router. Also, the router OpenVPN client fails when trying to resolve the server name. Nothing to do with IoT devices.

 

[wraithdu]

Well that's no fun. Then it seems DNS truncation is a poorly supported standard. Curious, what's your test domain, and what's the DNS response directly from say 8.8.8.8? Is it >512 bytes and not truncated?