What's new

Time Machine issue because of Adguard

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ComputerSteve

Senior Member
I've been having problems with time machine backup and I think i've narrowed it down to Adguard--- I am noticing that I can't complete a backup successfully,and it seems to be something with how adguard is handling domain names of local clients /DNS..
I see this in the adguard logs & on my Macbook Pro time machine gets stuck connecting to disk...

Request:
gt-ax11000_pro-den.local
Type: AAAA, Plain DNS

Response:
Rewritten
0.08 ms
Response details:
Status
Rewritten
Elapsed
0.08 ms
Response code
NOERROR

Client:
Client details
Address
192.168.50.25
Name
Stephens-MBP-2.local


I have this in the upstream:
[/router.asus.com/][::]:553
[/www.asusnetwork.net/][::]:553
[/www.asusrouter.com/][::]:553
[/use-application-dns.net/][::]:553
[/dns.resolver.arpa/][::]:553
[/local/][::]:553
[//][::]:553
9.9.9.9
8.8.8.8
tcp://9.9.9.9
tcp://8.8.8.8

I have this in private reverse servers:
[::]:553
[/10.in-addr.arpa/][::]:553
[/168.192.in-addr.arpa/][::]:553

Can I get some insight.. Thanks =)

I can fix this whole problem by bypassing dns local name resolution and setting the time machine location manually with this terminal command : sudo tmutil setdestination -ap afp://Admin@192.168.50.1/Backups.backupdb --- However I would like to resolve this problem or have response on how I can fix this without modifying MacOS with terminal commands.
 
Are you using .local for your lan name? If so, I believe that can cause issues.
 
No it used to be the default -- lan -- but I changed it to local to see if that fixed the problem... It didn't. Doing the same thing.
 
So I now installed Diversion and that doesn't have the problem... so something with adguard is stopping time machine from communicating...
 
People may want to see the earlier thread by the OP to gain context how the OP arrived at starting this thread about Adguard.
 
I don't use AdguardHome or macbooks so take what I say with a pinch of salt. But a couple of things strike me as odd.

1. Your [/local/][::]:553 line should have your local DNS domain name instead of local, e.g. [/myhomenetwork.lan/][::]:553. Never use local as your local DNS domain name as that is reserved for mDNS.
2. Why is your macbook even trying to resolve IPv6 .local addresses through DNS, it should be doing that via mDNS? Maybe the macbook is misconfigured.
2a. Or maybe there's a wider network problem as indicated by your previously reported issues with DHCP.
 
Last edited:
I don't use AdguardHome or macbooks so take what I say with a pinch of salt. But a couple of things strike me as odd.

1. Your [/local/][::]:553 line should have your local DNS domain name instead of local, e.g. [/myhomenetwork.lan/][::]:553. Never use local as your local DNS domain name as that is reserved for mDNS.
2. Why is your macbook even trying to resolve IPv6 .local addresses through DNS, it should be doing that via mDNS? Maybe the macbook is misconfigured.
2a. Or maybe there's a wider network problem as indicated by your previously reported issues with DHCP.
So I reinstalled adguard using AMTM and this is the new entries & my domain name is set to lan in the lan tab of the router so that seems correct --- However it still does it:

[/router.asus.com/][::]:553
[/www.asusnetwork.net/][::]:553
[/www.asusrouter.com/][::]:553
[/use-application-dns.net/][::]:553
[/dns.resolver.arpa/][::]:553
[/lan/][::]:553
[//][::]:553
9.9.9.9
8.8.8.8
tcp://9.9.9.9
tcp://8.8.8.8
 
So lan was what it was I changed it to local to see if it fixed the problem. It didn’t work. Meaning it works the same way !
 
So update... It appears that the firmware is the issue meaning Merlin has some incompatibility with time machine... The same problem is still happening even without any scripts installed. I have factory reset both my GT-AX11000 & GT-AX11000 Pro then installed the latest merlin and it didn't work meaning it gets stuck on "connecting to disk"... I then reinstalled the stock firmware & it worked.
 
So update... It appears that the firmware is the issue meaning Merlin has some incompatibility with time machine... The same problem is still happening even without any scripts installed. I have factory reset both my GT-AX11000 & GT-AX11000 Pro then installed the latest merlin and it didn't work meaning it gets stuck on "connecting to disk"... I then reinstalled the stock firmware & it worked.
But you previously said it was working when you removed AdGuardHome and installed Diversion. Then it stopped working again when you reversed that change.

So the results of your testing seem to be inconsistent or contradictory. We can't really speculate further as we don't know much about your setup, other than inferring from your latest post that you're using AiMesh and that you've had (still have?) DHCP issues on your LAN. Too many unknown variables.
 
But you previously said it was working when you removed AdGuardHome and installed Diversion. Then it stopped working again when you reversed that change.

So the results of your testing seem to be inconsistent or contradictory. We can't really speculate further as we don't know much about your setup, other than inferring from your latest post that you're using AiMesh and that you've had (still have?) DHCP issues on your LAN. Too many unknown variables.
I didn't update the post but it did begin to work for 1 time after diversion but then it stopped again.. So I decided to redo my whole setup and try both routers with nothing else configured meaning no AImesh and just check the time machine functionality... I have discovered that it never works reliably on the Merlin firmware but works every time on the stock firmwares of both the Asus AX-GT11000 & Asus AX-GT11000 pro.
 
Don't use .local for your LAN...

It's a reserved item for mDNS/Avahi/Bonjour...

.lan works fine there, and this should clean things up...
This was covered in posts 2 and 3 above
 
So just an update --- After testing I have come to the determination that the GT-AX11000 and the routers based on code base 3004.388 seem to all suffer from that connecting bug meaning even on stock firmware with time capsule. When I factory reset my GT-AX11000 Pro I didn't realize the stock firmware is now based on 3006. That version of the stock firmware works with time machine without the connecting bug. So for right now the only fix on the lower branch of firmware is to run this command on your mac sudo tmutil setdestination -ap afp://Admin@192.168.50.1/Backups.backupdb --- Update the IP to your router ip and the username from Admin to your username. This command allows the time machine to backup successfully without getting stuck on connecting to backup disk. The latest version of Merlin version 3004.388.8 with mDNS included still doesn't fix it. I didn't expect it to fix it because it doesn't even work on the stock version for the GT-AX11000 from ASUS. So in conclusion.. 3004 branch doesn't work on stock / 3006 branch does work on stock.
 
@ComputerSteve, RMerlin pushed out 3004.388.8 (if you haven't seen it already):
Fixes include the following which, if I remember right, may be relevant to your Time Machine issue:
- NEW: Added mDNS support to the router's local name resolution (nss).
 
Last edited:
@ComputerSteve, RMerlin pushed out 3004.388.8 (if you haven't seen it already):
Fixes include the following which, if I remember right, may be relevant to your Time Machine issue:
- NEW: Added mDNS support to the router's local name resolution (nss).
Yes, I tried it.. It doesn't fix the issue... I also found out that the stock firmware not based on the newest code meaning 3006 all suffer from this problem. Meaning If I upgrade my GT-AX11000 pro to the newest codebase the time machine works. Hopefully Merlin will release more supported models on the firmware 3006 instead of just the RT-BE96U & GT-BE98_PRO
 
So just an update --- After testing I have come to the determination that the GT-AX11000 and the routers based on code base 3004.388 seem to all suffer from that connecting bug meaning even on stock firmware with time capsule. When I factory reset my GT-AX11000 Pro I didn't realize the stock firmware is now based on 3006. That version of the stock firmware works with time machine without the connecting bug. So for right now the only fix on the lower branch of firmware is to run this command on your mac sudo tmutil setdestination -ap afp://Admin@192.168.50.1/Backups.backupdb --- Update the IP to your router ip and the username from Admin to your username. This command allows the time machine to backup successfully without getting stuck on connecting to backup disk. The latest version of Merlin version 3004.388.8 with mDNS included still doesn't fix it. I didn't expect it to fix it because it doesn't even work on the stock version for the GT-AX11000 from ASUS. So in conclusion.. 3004 branch doesn't work on stock / 3006 branch does work on stock.
I had run into Time Machine issues as well. Console logs on my mac indicated that it couldn't find afp://admin@routername_afpovertcp._tcp.local. Despite being able to manually mount that path in Finder. I also tried updating to 388.8 and that didn't fix it for me either. But I wanted to thank you for that tip about setting the TM location using the IP address! That has been working great so far for me :)
 
I had run into Time Machine issues as well. Console logs on my mac indicated that it couldn't find afp://admin@routername_afpovertcp._tcp.local

time to move on - direct attached storage is a better answer...

afpovertcp_tcp.local isn't supported on current MacOS

Roll the dice perhaps - but with backups, don't take the risk...
 
time to move on - direct attached storage is a better answer...

afpovertcp_tcp.local isn't supported on current MacOS

Roll the dice perhaps - but with backups, don't take the risk...
Yeah but it works if its set as the IP so IDK? Also it works on the latest GPL of 3006 firmware without using the IP meaning just using stock.
 
So I reinstalled adguard using AMTM and this is the new entries & my domain name is set to lan in the lan tab of the router so that seems correct --- However it still does it:

Do avahi right, or don't do it at all...

$ avahi-browse -at
+ eth0 IPv6 iPad _flametouch._tcp local
+ eth0 IPv4 iPad _flametouch._tcp local
+ eth0 IPv6 onn4k-br _androidtvremote2._tcp local
+ eth0 IPv4 onn4k-br _androidtvremote2._tcp local
+ eth0 IPv6 HomePod-Bedroom _srpl-tls._tcp local
+ eth0 IPv6 AppleTV-Office _srpl-tls._tcp local
+ eth0 IPv6 HomePod-Office _srpl-tls._tcp local
+ eth0 IPv4 HomePod-Bedroom _srpl-tls._tcp local
+ eth0 IPv4 AppleTV-Office _srpl-tls._tcp local
+ eth0 IPv4 HomePod-Office _srpl-tls._tcp local
+ eth0 IPv6 HomePodSensor 64120 _hap._tcp local
+ eth0 IPv6 HomePodSensor 252210 _hap._tcp local
+ eth0 IPv4 HomePodSensor 64120 _hap._tcp local
+ eth0 IPv4 HomePodSensor 252210 _hap._tcp local
+ eth0 IPv6 lefty VNC Remote Access local
+ eth0 IPv4 lefty VNC Remote Access local
+ eth0 IPv6 lefty Apple TimeMachine local
+ eth0 IPv4 lefty Apple TimeMachine local
+ eth0 IPv6 9C3E5300D43A@AppleTV-Office AirTunes Remote Audio local
+ eth0 IPv6 A4CF99AD21F1@HomePod-Bedroom AirTunes Remote Audio local
+ eth0 IPv6 A4CF99AD36C6@HomePod-Office AirTunes Remote Audio local
+ eth0 IPv6 A851ABC5759F@AppleTV-Bedroom AirTunes Remote Audio local
+ eth0 IPv4 A4CF99AD21F1@HomePod-Bedroom AirTunes Remote Audio local
+ eth0 IPv4 A851ABC5759F@AppleTV-Bedroom AirTunes Remote Audio local
+ eth0 IPv4 A4CF99AD36C6@HomePod-Office AirTunes Remote Audio local
+ eth0 IPv4 9C3E5300D43A@AppleTV-Office AirTunes Remote Audio local
+ eth0 IPv6 HomePod-Bedroom AirPlay Remote Video local
+ eth0 IPv6 HomePod-Office AirPlay Remote Video local
+ eth0 IPv6 AppleTV-Office AirPlay Remote Video local
+ eth0 IPv6 AppleTV-Bedroom AirPlay Remote Video local
+ eth0 IPv4 HomePod-Bedroom AirPlay Remote Video local
+ eth0 IPv4 AppleTV-Bedroom AirPlay Remote Video local
+ eth0 IPv4 AppleTV-Office AirPlay Remote Video local
+ eth0 IPv4 HomePod-Office AirPlay Remote Video local
+ eth0 IPv6 HomePod-Bedroom _companion-link._tcp local
+ eth0 IPv6 neo _companion-link._tcp local
+ eth0 IPv6 AppleTV-Bedroom _companion-link._tcp local
+ eth0 IPv6 AppleTV-Office _companion-link._tcp local
+ eth0 IPv6 HomePod-Office _companion-link._tcp local
+ eth0 IPv4 neo _companion-link._tcp local
+ eth0 IPv4 AppleTV-Bedroom _companion-link._tcp local
+ eth0 IPv4 HomePod-Bedroom _companion-link._tcp local
+ eth0 IPv4 AppleTV-Office _companion-link._tcp local
+ eth0 IPv4 HomePod-Office _companion-link._tcp local
+ eth0 IPv6 70-35-60-63.1 HomePod-Bedroom _sleep-proxy._udp local
+ eth0 IPv6 70-35-60-63.1 AppleTV-Bedroom _sleep-proxy._udp local
+ eth0 IPv6 70-35-60-63.1 AppleTV-Office _sleep-proxy._udp local
+ eth0 IPv6 70-35-60-63.1 HomePod-Office _sleep-proxy._udp local
+ eth0 IPv4 70-35-60-63.1 AppleTV-Bedroom _sleep-proxy._udp local
+ eth0 IPv4 70-35-60-63.1 HomePod-Bedroom _sleep-proxy._udp local
+ eth0 IPv4 70-35-60-63.1 AppleTV-Office _sleep-proxy._udp local
+ eth0 IPv4 70-35-60-63.1 HomePod-Office _sleep-proxy._udp local
+ eth0 IPv6 671ddf84-4d3e-3c96-ecfe-f58259243664 _googlezone._tcp local
+ eth0 IPv4 671ddf84-4d3e-3c96-ecfe-f58259243664 _googlezone._tcp local
+ eth0 IPv6 onn.-4K-Streaming-Bo-16d4bd61ac1b4f87ffda786c24ccee79 _googlecast._tcp local
+ eth0 IPv6 Google-Nest-Hub-671ddf844d3e3c96ecfef58259243664 _googlecast._tcp local
+ eth0 IPv4 Google-Nest-Hub-671ddf844d3e3c96ecfef58259243664 _googlecast._tcp local
+ eth0 IPv4 onn.-4K-Streaming-Bo-16d4bd61ac1b4f87ffda786c24ccee79 _googlecast._tcp local
+ eth0 IPv6 226de0cbb796fed9 _trel._udp local
+ eth0 IPv6 921a14f99b530445 _trel._udp local
+ eth0 IPv6 b223335efaa4047d _trel._udp local
+ eth0 IPv6 763fc3694f82561a _trel._udp local
+ eth0 IPv4 226de0cbb796fed9 _trel._udp local
+ eth0 IPv4 b223335efaa4047d _trel._udp local
+ eth0 IPv4 921a14f99b530445 _trel._udp local
+ eth0 IPv4 763fc3694f82561a _trel._udp local
+ eth0 IPv6 Google Nest Hub (fed9) _meshcop._udp local
+ eth0 IPv6 Apple BorderRouter #0445 _meshcop._udp local
+ eth0 IPv6 Apple BorderRouter #047D _meshcop._udp local
+ eth0 IPv6 Apple BorderRouter #561A _meshcop._udp local
+ eth0 IPv4 Google Nest Hub (fed9) _meshcop._udp local
+ eth0 IPv4 Apple BorderRouter #047D _meshcop._udp local
+ eth0 IPv4 Apple BorderRouter #0445 _meshcop._udp local
+ eth0 IPv4 Apple BorderRouter #561A _meshcop._udp local
+ eth0 IPv6 lefty Microsoft Windows Network local
+ eth0 IPv6 TURBO Microsoft Windows Network local
+ eth0 IPv4 lefty Microsoft Windows Network local
+ eth0 IPv4 TURBO Microsoft Windows Network local
+ eth0 IPv4 BUILDER Microsoft Windows Network local
+ eth0 IPv6 TURBO Device Info local
+ eth0 IPv4 TURBO Device Info local
+ eth0 IPv6 netgate Web Site local
+ eth0 IPv6 MR2200ac-ND8S57 Web Site local
+ eth0 IPv6 phpMyAdmin on blaster Web Site local
+ eth0 IPv6 phpMyAdmin on blue Web Site local
+ eth0 IPv4 phpMyAdmin on blaster Web Site local
+ eth0 IPv4 BUILDER Web Site local
+ eth0 IPv4 netgate Web Site local
+ eth0 IPv4 MR2200ac-ND8S57 Web Site local
+ eth0 IPv4 phpMyAdmin on blue Web Site local
+ eth0 IPv4 BUILDER [00:08:9b:ef:dc:5e] Workstation local
+ eth0 IPv4 BUILDER QNAP NAS local
+ lo IPv4 phpMyAdmin on blue Web Site local
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top