Upgrading adguard to latest stops all external network traffic

I used to run HA supervised. Was successfully running Adguard 4.7.6 Back when the next version came out, on startup it would have the following issue:

listen udp 127.0.0.1:53: bind: address already in use

discussed here AdGuard Home couldn't start forwarding DNS server - #7 by farnsy

I recently switched to running HAOS - installed, booted, restored backup and all was going well. I thought I would attempt to update adguard again.

I updated to 4.8.10, started up the add on, and all looked good in the logs - no errors.

However after some time, network traffic would stop - all devices in my house would lose access to the internet. I still had observer loaded in a tab, and it was all showing fine - however I couldn’t browse to my home assistant at all. I resorted to powering off the pi a couple of times. I then stopped adguard for a few hours, and no issues. I downgraded to 4.7.6, and all still good.

I’ve just tested it again, and about 35 minutes after upgrading, all outgoing network activity ceased. I couldn’t access HA from external (via mobile network). I could still access HA internally via IP, however there were no updates in the log for the adguard add on.

Any ideas where to start looking for how to solve this problem

Does 4.7.6 also try to bind to the loopback? It seems uncessary to me, considering its within a docker container, clients will be external in nature, however it’s odd that it would be taken.

If you are using HAos then it shouldn’t have any DNS stub resolver from SystemD.

This is the log output relating to addresses

2023/06/21 14:57:05.844418 [info] dnsproxy: creating udp server socket 192.168.86.132:53
2023/06/21 14:57:05.845319 [info] dnsproxy: listening to udp://192.168.86.132:53
2023/06/21 14:57:05.845364 [info] dnsproxy: creating udp server socket [fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 14:57:05.846245 [info] dnsproxy: listening to udp://[fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 14:57:05.846281 [info] dnsproxy: creating udp server socket 172.30.32.1:53
2023/06/21 14:57:05.847041 [info] dnsproxy: listening to udp://172.30.32.1:53
2023/06/21 14:57:05.847073 [info] dnsproxy: creating udp server socket 127.0.0.1:53
2023/06/21 14:57:05.847706 [info] dnsproxy: listening to udp://127.0.0.1:53
2023/06/21 14:57:05.847733 [info] dnsproxy: creating udp server socket [::1]:53
2023/06/21 14:57:05.848379 [info] dnsproxy: listening to udp://[::1]:53
2023/06/21 14:57:05.848423 [info] dnsproxy: creating tcp server socket 192.168.86.132:53
2023/06/21 14:57:05.849288 [info] dnsproxy: listening to tcp://192.168.86.132:53
2023/06/21 14:57:05.849317 [info] dnsproxy: creating tcp server socket [fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 14:57:05.850054 [info] dnsproxy: listening to tcp://[fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 14:57:05.850082 [info] dnsproxy: creating tcp server socket 172.30.32.1:53
2023/06/21 14:57:05.850660 [info] dnsproxy: listening to tcp://172.30.32.1:53
2023/06/21 14:57:05.850688 [info] dnsproxy: creating tcp server socket 127.0.0.1:53
2023/06/21 14:57:05.852095 [info] dnsproxy: listening to tcp://127.0.0.1:53
2023/06/21 14:57:05.852137 [info] dnsproxy: creating tcp server socket [::1]:53
2023/06/21 14:57:05.852743 [info] dnsproxy: listening to tcp://[::1]:53
2023/06/21 14:57:05.853349 [info] dnsproxy: entering udp listener loop on 192.168.86.132:53
2023/06/21 14:57:05.853543 [info] dnsproxy: entering tcp listener loop on 127.0.0.1:53
2023/06/21 14:57:05.853361 [info] dnsproxy: entering udp listener loop on [::1]:53
2023/06/21 14:57:05.853800 [info] dnsproxy: entering tcp listener loop on [::1]:53
2023/06/21 14:57:05.853405 [info] dnsproxy: entering udp listener loop on 172.30.32.1:53
2023/06/21 14:57:05.853471 [info] dnsproxy: entering udp listener loop on 127.0.0.1:53
2023/06/21 14:57:05.853714 [info] dnsproxy: entering tcp listener loop on 192.168.86.132:53
2023/06/21 14:57:05.853734 [info] dnsproxy: entering tcp listener loop on [fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 14:57:05.853773 [info] dnsproxy: entering tcp listener loop on 172.30.32.1:53
2023/06/21 14:57:05.855792 [info] dnsproxy: entering udp listener loop on [fd7c:582b:680:0:3b70:b416:72fb:1266]:53

and not that it adds much to the overall description, but I’ve had ping running on multiple other machines - ping 8.8.8.8 - and it just starts printing Request timed out

Assuming that’s from 4.7.6, it seems like it does indeed still do that (binds on all available 53).

  1. Have you tried restarting HAos after upgrade in case there’s any zombie?
  2. On 4.8.0, it’s possible it’s creating two instances, might be worth checking the ps logs from docker.

I am running Current version: 4.8.10 - no issues.

Have you tried doing a clean install of the latest version in case there’s lint in the setup from carrying it through different versions?

sorry for the confusion - to clarify, the log posted above is 4.8.10 - the error in my first post was when I upgraded to 4.8.4, when running on Supervised a while ago (as noted in the other thread). When I run 4.7.6, there are no errors in the log - however I’ll just restore the backup and grab that log.

I’ve restarted HAOS a number of times with the issue still present (i.e. my family yelled at me, pulled the plug, plugged it back in later, repeat)

Do you mean a clean install of the latest version of AdGuard? How would i go about that? I’ve restored 4.7.6 a couple of times, and updated to 4.8.10 a couple of times - is there a more brute force method to remove a previous installation?

this is the same section of the log from starting up 4.7.6

2023/06/21 16:25:22.395419 [info] Creating the UDP server socket
2023/06/21 16:25:22.395707 [info] Listening to udp://192.168.86.132:53
2023/06/21 16:25:22.395738 [info] Creating the UDP server socket
2023/06/21 16:25:22.395868 [info] Listening to udp://[fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 16:25:22.395881 [info] Creating the UDP server socket
2023/06/21 16:25:22.395971 [info] Listening to udp://172.30.32.1:53
2023/06/21 16:25:22.395983 [info] Creating a TCP server socket
2023/06/21 16:25:22.396092 [info] Listening to tcp://192.168.86.132:53
2023/06/21 16:25:22.396103 [info] Creating a TCP server socket
2023/06/21 16:25:22.396197 [info] Listening to tcp://[fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 16:25:22.396212 [info] Creating a TCP server socket
2023/06/21 16:25:22.396298 [info] Listening to tcp://172.30.32.1:53
2023/06/21 16:25:22.397173 [info] Entering the UDP listener loop on [fd7c:582b:680:0:3b70:b416:72fb:1266]:53
2023/06/21 16:25:22.397422 [info] Entering the UDP listener loop on 192.168.86.132:53
2023/06/21 16:25:22.397645 [info] Entering the UDP listener loop on 172.30.32.1:53
2023/06/21 16:25:22.397861 [info] Entering the tcp listener loop on 192.168.86.132:53
2023/06/21 16:25:22.397983 [info] Entering the tcp listener loop on 172.30.32.1:53
2023/06/21 16:25:22.398453 [info] Entering the tcp listener loop on [fd7c:582b:680:0:3b70:b416:72fb:1266]:53

Nuke the addon’s data directory.

Havae you tried comparing a standalone install of adguard from your laptop or a raspberry pi for comparison?