search

hassio-addons / addon-adguard-home

AdGuard Home - Home Assistant Community Add-ons
https://addons.community
MIT License
395 stars 48 forks source link

[fatal] couldn't start forwarding DNS server #385

Closed naked-head closed 1 year ago

naked-head commented 1 year ago

Problem/Motivation

After upgrading to new versione I got this error [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp 127.0.0.1:53: bind: address already in use

Environment:

Supervised on Debian 11 Kernel 5.10.158-2 Supervisor 2022.12.1 Home Assistant 2023.1.6

I tried to restore to previous version and the addon is function again, so I upgraded again and got same error.

Steps to reproduce

Upgrading to latest version

patanachai commented 1 year ago

Facing the same problem with a little-bit different error for me. it is

listen udp [::1]:53: bind: cannot assign requested address

This change makes it looking for ::1 even IPv6 is disable.

KruseLuds commented 1 year ago

I have the same issue and had to revert back to Adguard Home 4.7.6 from 4.8.0 due to this error message:

[fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp 127.0.0.1:53: bind: address already in use

Also, this file (BEFORE UPGRADING FROM 4.7.6 to 4.8.0):

/usr/share/hassio/addons/data/a0d7b954_adguard/adguard/AdGuardHome.yaml contents are:

bind_host: 127.0.0.1
bind_port: 45158
beta_bind_port: 0
users: []
auth_attempts: 5
block_auth_min: 15
http_proxy: ""
language: ""
debug_pprof: false
web_sesion_ttl: 720
dns:
  bind_hosts:
    - 192.168.0.34
    - 172.30.32.1

Note, when I upgrade to 4.8.0, the above file appears to be the same except the bind_hosts section changes to only the IP address 127.0.0.1 - and I saw in suport forums in the past that people would change it to 0.0.0.0 and restart Adguard and it would then change to the host IP where adguard is running (in my case an RPI 4B 8G RAM w/a 1TB SSD Home Assistant Supervised which has the IP address 192.168.0.34). I am NOT using adguard as a dhcp server. I also tried changing the AdGuardHome.yaml to include the two IP addresses above and restart it - but the section in the file just changes to the one entry 192.168.0.34 - and also still has the same error message about port 53.

BTW, I did a search as it looked like the port 53 was already being used by something else and all I could find for processes using port 53 was systemd_resolved but I think that was leading me down a rabbit hole as it wasn't really the issue - nothing else had changed in the configuration....

(BTW I also tried temporarily disabling the core_dns_override addon but that made zero difference.)

Here is my setup currently:

## System Information

version | core-2023.1.6
-- | --
installation_type | Home Assistant Supervised
dev | false
hassio | true
docker | true
user | root
virtualenv | false
python_version | 3.10.7
os_name | Linux
os_version | 5.10.0-20-arm64
arch | aarch64
timezone | America/New_York
config_dir | /config

<details><summary>Home Assistant Community Store</summary>

GitHub API | ok
-- | --
GitHub Content | ok
GitHub Web | ok
GitHub API Calls Remaining | 4698
Installed Version | 1.29.1
Stage | running
Available Repositories | 1266
Downloaded Repositories | 23

</details>

<details><summary>AccuWeather</summary>

can_reach_server | ok
-- | --
remaining_requests | 6

</details>

<details><summary>Home Assistant Cloud</summary>

logged_in | false
-- | --
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok

</details>

<details><summary>Home Assistant Supervisor</summary>

host_os | Debian GNU/Linux 11 (bullseye)
-- | --
update_channel | stable
supervisor_version | supervisor-2022.12.1
agent_version | 1.4.1
docker_version | 20.10.22
disk_total | 915.4 GB
disk_used | 14.0 GB
healthy | true
supported | true
supervisor_api | ok
version_api | ok
installed_addons | AppDaemon (0.11.0), Core DNS Override (0.1.1), Duck DNS (1.15.0), File editor (5.5.0), Home Assistant Google Drive Backup (0.110.1), Log Viewer (0.14.0), Mosquitto broker (6.1.3), Samba share (10.0.0), Terminal & SSH (9.6.1), AdGuard Home (4.7.6)

</details>

<details><summary>Dashboards</summary>

dashboards | 4
-- | --
resources | 15
views | 31
mode | storage

</details>

<details><summary>Recorder</summary>

oldest_recorder_run | December 20, 2022 at 5:06 PM
-- | --
current_recorder_run | January 20, 2023 at 4:25 PM
estimated_db_size | 2239.96 MiB
database_engine | sqlite
database_version | 3.38.5

</details>
InToSSH commented 1 year ago

Facing the same problem with a little-bit different error for me. it is

listen udp [::1]:53: bind: cannot assign requested address

This change makes it looking for ::1 even IPv6 is disable.

I have exactly the same problem after the upgrade. Is there a way to manually specify the bind_hosts? If I rewrite the AdGuardHome.yaml file, it gets rewritten again when the addon starts.

naked-head commented 1 year ago

Facing the same problem with a little-bit different error for me. it is

listen udp [::1]:53: bind: cannot assign requested address

This change makes it looking for ::1 even IPv6 is disable.

Searching with netstat -tulpn | grep ":53 " I found the guilty: in supervised we use ConnMan to listen to 127.0.0.1:53.

The solution may be to add this function to the changed file

def check_port():
    import socket, errno
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    try:        s.bind(("127.0.0.1",53))
    except socket.error as e:
        if e.errno == errno.EADDRINUSE:
            return False
        else:
            return True   
    s.close()

and then, the actual row 60, change like this:

if check_port():
   hosts+=("127.0.0.1")
   hosts+=("::1")

or something like that

uroh commented 1 year ago

I have the same problem, i downgraded the addon to restore adguard. The system has the following configuration: fixed ip 192.168.2.51/32, gw 192.168.2.1, dns 192.168.2.51, ipv6 disabled, router 192.168.2.1 with dns server 192.168.2.51. With version 4.7.8 everything works perfectly.

rucanunes commented 1 year ago

Same problem.

naked-head commented 1 year ago

Meanwhile I found a server configuration solution: Changing my ConnMan systemd configuration, in file /etc/systemd/system/multi-user.target.wants/connman.service I changed the row ExecStart=/usr/sbin/connmand -n to ExecStart=/usr/sbin/connmand -n -r. After that I had to restart the system and finally upgraded to new version of AdGuard that can listen to 127.0.0.1:53.

uroh commented 1 year ago

I am happy for you! In my case I have not installed ConnMan systemd in my distribution (armbian), in other words there is no connman.service file to edit.

uroh commented 1 year ago

Anyway with version 4.7.8 everything works perfectly and adguard listens in the following ports: tcp 0 0 192.168.2.51:53 0.0.0.0: LISTEN 77750/./AdGuardHome tcp 0 0 127.0.0.53:53 0.0.0.0: LISTEN 839/systemd-resolve tcp 0 0 172.30.32.1:53 0.0.0.0: LISTEN 77750/./AdGuardHome udp 0 0 172.30.32.1:53 0.0.0.0: 77750/./AdGuardHome udp 0 0 192.168.2.51:53 0.0.0.0: 77750/./AdGuardHome udp 0 0 127.0.0.53:53 0.0.0.0: 839/systemd-resolve

With version 4.8 I have the same problem as @patanachai with the following message in the log: "listen udp [::1]:53: bind: cannot assign requested address"

tjorim commented 1 year ago

I am happy for you! In my case I have not installed ConnMan systemd in my distribution (armbian), in other words there is no connman.service file to edit.

@uroh armbian is not a supported installation method.

tjorim commented 1 year ago

Meanwhile I found a server configuration solution: Changing my ConnMan systemd configuration, in file /etc/systemd/system/multi-user.target.wants/connman.service I changed the row ExecStart=/usr/sbin/connmand -n to ExecStart=/usr/sbin/connmand -n -r. After that I had to restart the system and finally upgraded to new version of AdGuard that can listen to 127.0.0.1:53.

@naked-head good catch. Home assistant supervisor only supports NetworkManager anyway, so your installation is not supported anyway.

tjorim commented 1 year ago

It would probably help us troubleshoot better if people post their system information: settings -> system -> repairs -> the three dots in the top right -> system information -> copy button in the bottom right.

naked-head commented 1 year ago

It would probably help us troubleshoot better if people post their system information: settings -> system -> repairs -> the three dots in the top right -> system information -> copy button in the bottom right.

I honestly don't know why I have ConnMan, I thought it was a homeassistant dependence. I did a fresh clean install with Homeassistant Supervised and nothing more....I will investigate on it...

Anyway the solution, if no change are made to this new version, is to stop the service (whatever it is) that lock the socket.

that's my system:

System Information

version core-2023.1.6
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.7
os_name Linux
os_version 5.10.0-20-amd64
arch x86_64
timezone Europe/Rome
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4999 Installed Version | 1.29.1 Stage | running Available Repositories | 1267 Downloaded Repositories | 69
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2022.12.1 agent_version | 1.4.1 docker_version | 20.10.23 disk_total | 204.7 GB disk_used | 12.4 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | Samba share (10.0.0), Home Assistant Google Drive Backup (0.110.1), Vaultwarden (Bitwarden) (0.19.0), AdGuard Home (4.8.0), Mosquitto broker (6.1.3), Log Viewer (0.14.0), MariaDB (2.5.1), phpMyAdmin (0.8.3), Studio Code Server (5.5.1), SSH & Web Terminal (13.0.2), Scrutiny (v0.6.0), Nginx Proxy Manager (0.12.3), Nextcloud (25.0.0-10), Portainer (2.16.2)
Dashboards dashboards | 4 -- | -- resources | 41 views | 15 mode | storage
Recorder oldest_recorder_run | January 11, 202312:22 -- | -- current_recorder_run | January 11, 2023 16:07 estimated_db_size | 667.41 MiB database_engine | sqlite database_version | 3.38.5
InToSSH commented 1 year ago

Here is my system info for troubleshooting. For the time being I reverted back to the older version. If you need more specific info I would be happy to provide that.

System Information

version core-2023.1.5
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.7
os_name Linux
os_version 5.10.0-20-amd64
arch x86_64
timezone Europe/Prague
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4465 Installed Version | 1.29.0 Stage | running Available Repositories | 1272 Downloaded Repositories | 37
Home Assistant Cloud logged_in | true -- | -- subscription_expiration | January 6, 2024 at 01:00 relayer_connected | true remote_enabled | true remote_connected | true alexa_enabled | true google_enabled | true remote_server | eu-central-1-2.ui.nabu.casa can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2022.12.1 agent_version | 1.4.1 docker_version | 20.10.22 disk_total | 191.4 GB disk_used | 76.0 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | Terminal & SSH (9.6.1), Samba share (10.0.0), File editor (5.5.0), Check Home Assistant configuration (3.11.0), Node-RED (14.0.1), Mosquitto broker (6.1.3), ESPHome (2022.12.3), InfluxDB (4.5.0), Grafana (8.1.0), AppDaemon (0.11.0), MariaDB (2.5.1), phpMyAdmin (0.8.3), TasmoAdmin (0.23.0), AdGuard Home (4.7.6), Amcrest2mqtt (1.0.16.1), Uptime Kuma (0.5.2), Let's Encrypt (4.12.7), Home Assistant Google Drive Backup (0.110.1), EMQX (0.2.1)
Dashboards dashboards | 3 -- | -- resources | 15 views | 9 mode | storage
Recorder oldest_recorder_run | December 28, 2022 at 01:51 -- | -- current_recorder_run | January 21, 2023 at 00:54 database_engine | mysql database_version | 10.6.8
Sonoff version | 3.3.1 (b20e33c) -- | -- cloud_online | 2 / 3 local_online | 0 / 0
Spotify api_endpoint_reachable | ok -- | --
Xiaomi Miot Auto component_version | 0.7.4 -- | -- can_reach_server | ok can_reach_spec | ok logged_accounts | 1 total_devices | 3
uroh commented 1 year ago

Thank you @tjorim for the valuable contribution. However, I have taken the liberty of writing to request a different type of contribution aimed at resolving a problem that was not present in the previous version. Perhaps the implementation of binding to localhost is only oriented towards specific supported distributions or, perhaps, it contains some imperfections! In any case, I will be publishing the specifications of my unsupported server:

System Information

version core-2023.1.6
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.7
os_name Linux
os_version 5.15.85-flippy-80+o
arch aarch64
timezone Europe/Rome
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.29.1 Stage | running Available Repositories | 1204 Downloaded Repositories | 44
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2022.12.1 agent_version | 1.4.1 docker_version | 20.10.22 disk_total | 119.2 GB disk_used | 23.0 GB healthy | true supported | failed to load: Unsupported supervisor_api | ok version_api | ok installed_addons | AdGuard Home (4.7.6), Bookstack (1.4.0), Caddy 2 (1.3.1), File editor (5.5.0), Grafana (8.1.0), Home Assistant Google Drive Backup (0.110.1), InfluxDB (4.5.0), Terminal & SSH (9.6.1), WireGuard (0.7.1), Zigbee2MQTT (1.29.2-1), Node-RED (14.0.1), ESPHome (2022.12.3), MariaDB (2.5.1), phpMyAdmin (0.8.3)
Dashboards dashboards | 1 -- | -- resources | 27 views | 7 mode | storage
NextDNS can_reach_server | ok -- | --
Recorder oldest_recorder_run | 15 gennaio 2023 07:52 -- | -- current_recorder_run | 20 gennaio 2023 16:41 estimated_db_size | 106.86 MiB database_engine | mysql database_version | 10.6.8
Sonoff version | 3.3.1 (b20e33c) -- | -- cloud_online | 0 / 6 local_online | 4 / 4
Xiaomi Miot Auto component_version | 0.7.5 -- | -- can_reach_server | ok can_reach_spec | ok logged_accounts | 1 total_devices | 2
sysadmin-info commented 1 year ago

Hi,

I have the same issue:

2023/01/22 09:09:05.912562 [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp [::1]:53: bind: cannot assign requested address [09:09:05] INFO: Service Adguard Home exited with code 1 (by signal 0) s6-rc: info: service legacy-services: stopping s6-rc: info: service legacy-services successfully stopped s6-rc: info: service discovery: stopping s6-rc: info: service nginx: stopping s6-rc: info: service discovery successfully stopped [09:09:06] INFO: Starting AdGuard Home server... 2023/01/22 09:09:06.087628 [info] AdGuard Home, version v0.107.22 2023/01/22 09:09:06.087802 [info] AdGuard Home updates are disabled 2023/01/22 09:09:06.094936 [info] tls: using default ciphers 2023/01/22 09:09:06.105808 [info] Initializing auth module: /data/adguard/data/sessions.db 2023/01/22 09:09:06.106261 [info] auth: initialized. users:0 sessions:0 2023/01/22 09:09:06.106432 [info] tls: number of certs: 1 [09:09:06] INFO: Service NGINX exited with code 0 (by signal 0) s6-rc: info: service nginx successfully stopped s6-rc: info: service init-nginx: stopping s6-rc: info: service adguard: stopping s6-rc: info: service init-nginx successfully stopped 2023/01/22 09:09:06.154138 [info] Received signal "terminated" 2023/01/22 09:09:06.154174 [info] stopping AdGuard Home 2023/01/22 09:09:06.162480 [info] web: initializing 2023/01/22 09:09:06.169438 [info] stopped [09:09:06] INFO: Service Adguard Home exited with code 0 (by signal 0) s6-rc: info: service adguard successfully stopped s6-rc: info: service init-adguard: stopping s6-rc: info: service init-adguard successfully stopped s6-rc: info: service legacy-cont-init: stopping s6-rc: info: service legacy-cont-init successfully stopped s6-rc: info: service fix-attrs: stopping s6-rc: info: service base-addon-log-level: stopping s6-rc: info: service fix-attrs successfully stopped s6-rc: info: service base-addon-log-level successfully stopped s6-rc: info: service base-addon-banner: stopping s6-rc: info: service base-addon-banner successfully stopped s6-rc: info: service s6rc-oneshot-runner: stopping s6-rc: info: service s6rc-oneshot-runner successfully stopped

23-01-22 09:43:38 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon AdGuard Home is failed, restarting... 23-01-22 09:43:38 INFO (SyncWorker_6) [supervisor.docker.interface] Cleaning addon_a0d7b954_adguard application 23-01-22 09:43:39 INFO (SyncWorker_7) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/adguard/aarch64 with version 4.8.0 23-01-22 09:43:42 INFO (MainThread) [supervisor.api.middleware.security] /network/info access from a0d7b954_adguard 23-01-22 09:43:43 INFO (MainThread) [supervisor.api.middleware.security] /network/interface/eth0/info access from a0d7b954_adguard 23-01-22 09:43:47 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.RUNNING 23-01-22 09:43:48 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete 23-01-22 09:43:49 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/hassio-addons/repository repository 23-01-22 09:43:49 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/esphome/home-assistant-addon repository 23-01-22 09:43:49 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/brenner-tobias/ha-addons repository 23-01-22 09:43:49 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/sabeechen/hassio-google-drive-backup repository 23-01-22 09:43:49 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/home-assistant/addons repository 23-01-22 09:43:49 INFO (MainThread) [supervisor.updater] Fetching update data from https://version.home-assistant.io/stable.json 23-01-22 09:43:50 ERROR (MainThread) [aiohttp.server] Error handling request Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request resp = await request_handler(request) File "/usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/aiohttp.py", line 126, in sentry_app_handle reraise(_capture_exception(hub)) File "/usr/local/lib/python3.10/site-packages/sentry_sdk/_compat.py", line 57, in reraise raise value File "/usr/local/lib/python3.10/site-packages/sentry_sdk/integrations/aiohttp.py", line 116, in sentry_app_handle response = await old_handle(self, request) File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle resp = await handler(request) File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl return await handler(request) File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 138, in system_validation return await handler(request) File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 204, in token_validation return await handler(request) File "/usr/src/supervisor/supervisor/api/utils.py", line 62, in wrap_api answer = await method(api, args, **kwargs) File "/usr/src/supervisor/supervisor/api/store.py", line 178, in store_info ATTR_ADDONS: [ File "/usr/src/supervisor/supervisor/api/store.py", line 179, in self._generate_addon_information(self.sys_addons.store[addon]) File "/usr/src/supervisor/supervisor/api/store.py", line 114, in _generate_addon_information ATTR_ADVANCED: addon.advanced, File "/usr/src/supervisor/supervisor/addons/model.py", line 221, in advanced return self.data[ATTR_ADVANCED] File "/usr/src/supervisor/supervisor/store/addon.py", line 19, in data return self.sys_store.data.addons[self.slug] KeyError: 'core_cec_scan' 23-01-22 09:43:52 INFO (MainThread) [supervisor.store] Loading add-ons from store: 70 all - 0 new - 0 remove 23-01-22 09:43:52 INFO (MainThread) [supervisor.store] Loading add-ons from store: 70 all - 0 new - 0 remove 23-01-22 09:43:59 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon AdGuard Home is failed, restarting... 23-01-22 09:43:59 INFO (SyncWorker_4) [supervisor.docker.interface] Cleaning addon_a0d7b954_adguard application 23-01-22 09:43:59 INFO (SyncWorker_5) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/adguard/aarch64 with version 4.8.0 23-01-22 09:44:02 INFO (MainThread) [supervisor.api.middleware.security] /network/info access from a0d7b954_adguard 23-01-22 09:44:03 INFO (MainThread) [supervisor.api.middleware.security] /network/interface/eth0/info access from a0d7b954_adguard 23-01-22 09:44:09 INFO (MainThread) [supervisor.homeassistant.core] Detect a running Home Assistant instance 23-01-22 09:44:19 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon AdGuard Home is failed, restarting... 23-01-22 09:44:19 INFO (SyncWorker_1) [supervisor.docker.interface] Cleaning addon_a0d7b954_adguard application 23-01-22 09:44:19 INFO (SyncWorker_6) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/adguard/aarch64 with version 4.8.0 23-01-22 09:44:22 INFO (MainThread) [supervisor.api.middleware.security] /network/info access from a0d7b954_adguard 23-01-22 09:44:22 INFO (MainThread) [supervisor.api.middleware.security] /network/interface/eth0/info access from a0d7b954_adguard 23-01-22 09:44:38 ERROR (MainThread) [asyncio] Task exception was never retrieved future: <Task finished name='Task-2338' coro=<Addon.watchdog_container() done, defined at /usr/src/supervisor/supervisor/addons/addon.py:988> exception=AddonsJobError('Rate limit exceeded, more then 10 calls in 0:30:00')> Traceback (most recent call last): File "/usr/src/supervisor/supervisor/addons/addon.py", line 1002, in watchdog_container await self._restart_after_problem(self, event.state) File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 144, in wrapper raise on_condition( supervisor.exceptions.AddonsJobError: Rate limit exceeded, more then 10 calls in 0:30:00

Debian 11 kernel version: 5.15.84-v8+ Docker version: 20.10.22, build 3a2c30b Supervisor: 2022.12.1 Home Assistant: 2023.1.6 Core: 2023.1.6 Adguard Home addon version: 4.8.0

[root@raspberrypi:~]# ss -tulpen | grep ":53 " udp UNCONN 0 0 172.30.32.1:53 0.0.0.0: users:(("AdGuardHome",pid=4480,fd=46))
udp UNCONN 0 0 10.10.0.100:53 0.0.0.0: users:(("AdGuardHome",pid=4480,fd=45))
udp UNCONN 0 0 127.0.0.53:53 0.0.0.0: users:(("systemd-resolve",pid=446,fd=16))
tcp LISTEN 0 4096 172.30.32.1:53 0.0.0.0: users:(("AdGuardHome",pid=4480,fd=49)) ino:19438 sk:b cgroup:/docker/f2403bee533dfd7202f2c2da8c528dcc1987c97cfa833e7d2514718d38142fb1 <->
tcp LISTEN 0 4096 10.10.0.100:53 0.0.0.0: users:(("AdGuardHome",pid=4480,fd=48)) ino:19437 sk:c cgroup:/docker/f2403bee533dfd7202f2c2da8c528dcc1987c97cfa833e7d2514718d38142fb1 <->
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0: users:(("systemd-resolve",pid=446,fd=17)) uid:103 ino:8910 sk:d cgroup:/system.slice/systemd-resolved.service <->

[root@raspberrypi:~]# systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-01-22 19:16:16 CET; 7s ago Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 31609 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 8985) CGroup: /system.slice/systemd-resolved.service └─31609 /lib/systemd/systemd-resolved

Jan 22 19:16:16 raspberrypi systemd[1]: Starting Network Name Resolution... Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: Positive Trust Anchors: Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.>Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: Using system hostname 'raspberrypi'. Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding tra>Jan 22 19:16:16 raspberrypi systemd-resolved[31609]: mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding tra>Jan 22 19:16:16 raspberrypi systemd[1]: Started Network Name Resolution.

Any logic explanation why this localhost change has been provided? I do not see any option to disable it on Adguard Home addon level in Home Assistant Supervised.

naked-head commented 1 year ago

@naked-head good catch. Home assistant supervisor only supports NetworkManager anyway, so your installation is not supported anyway.

Today I have removed ConnMan going back to NetworkManager, my installation is now supported. AdGuard is still working even uninstalling I removed the only change I played in systemd configuration file of ConnMan, so with supported installation everything work well.

Anyway I think that would be better if people can choose if AdGuard can listen on localhost or not. Using the correction I suggested before, or better adding a new configuration parameter.

InToSSH commented 1 year ago

Just to add to this issue, unlike @naked-head I am not using ConnMan, but I have NetworkManager, my installation should be supported running on Debian 11. Yet I still get this error, exactly this one:

listen udp [::1]:53: bind: cannot assign requested address

So I don't think it is only the ConnMan causing that. My only help was to revert back to the older version. I checked what is listening on port 53 and I get this:

tcp        0      0 172.30.32.1:53          0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.3.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.2.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.1.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      330/systemd-resolve
tcp6       0      0 fd4e:xxxx:xxxx:1:xxx:53 :::*                    LISTEN      20436/./AdGuardHome
tcp6       0      0 2a06:xxxx:xxxx:xxxx::53 :::*                    LISTEN      20436/./AdGuardHome
sysadmin-info commented 1 year ago

I am going to test the solution for the systemd-resolved from here: https://github.com/AdguardTeam/AdGuardHome/wiki/FAQ#why-am-i-getting-bind-address-already-in-use-error-when-trying-to-install-on-ubuntu

I am using Debian 11 and I observed the same behavior. Probably when I will disable the service, Supervised will inform me that I am running unsuppoeted version. :) But I can live with it.

InToSSH commented 1 year ago

@sysadmin-info I tried your solution, but that unfortunately didn't help. I still get the same error, this is the log:

2023/01/22 19:56:32.553891 [info] Creating the UDP server socket
2023/01/22 19:56:32.554249 [info] Listening to udp://10.10.1.10:53
2023/01/22 19:56:32.554372 [info] Creating the UDP server socket
2023/01/22 19:56:32.555258 [info] Listening to udp://[2a06:xxxx:xxxx:xxxx:1755:xxxx:xxxx:xxxx]:53
2023/01/22 19:56:32.555490 [info] Creating the UDP server socket
2023/01/22 19:56:32.555720 [info] Listening to udp://[fd4e:xxxx:xxxx:1:8f7f:[xxxx:xxxx:9048](xxxx:xxxx:xxxx)]:53
2023/01/22 19:56:32.555886 [info] Creating the UDP server socket
2023/01/22 19:56:32.556116 [info] Listening to udp://10.10.2.10:53
2023/01/22 19:56:32.556228 [info] Creating the UDP server socket
2023/01/22 19:56:32.556490 [info] Listening to udp://10.10.3.10:53
2023/01/22 19:56:32.556608 [info] Creating the UDP server socket
2023/01/22 19:56:32.557098 [info] Listening to udp://172.30.32.1:53
2023/01/22 19:56:32.557231 [info] Creating the UDP server socket
2023/01/22 19:56:32.557697 [info] Listening to udp://127.0.0.1:53
2023/01/22 19:56:32.557829 [info] Creating the UDP server socket
2023/01/22 19:56:32.581014 [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp [::1]:53: bind: cannot assign requested address

Only now the 127.0.0.53:53 is gone from the netstat:

tcp        0      0 172.30.32.1:53          0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.3.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.2.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.1.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp6       0      0 fd4e:xxxx:xxxx:1:xxx:53 :::*                    LISTEN      20436/./AdGuardHome
tcp6       0      0 2a06:xxxx:xxxx:xxxx::53 :::*                    LISTEN      20436/./AdGuardHome

This is running the old version after your suggestion. Of course after upgrade there is nothing coming up because Adguard won't start.

caraar12345 commented 1 year ago

@InToSSH have you tried running netstat -tulpn?

The issue is binding UDP port 53; your netstat is only showing TCP

InToSSH commented 1 year ago

@caraar12345 Yes, sorry, I just copied the wrong part. This is what it looks like after disabling systemd-resolved by applying the fix from AdGuard wiki:

  root@loki:/etc/systemd/resolved.conf.d# netstat -tulpn | grep ":53 "
tcp        0      0 172.30.32.1:53          0.0.0.0:*               LISTEN      367374/./AdGuardHom
tcp        0      0 10.10.3.10:53           0.0.0.0:*               LISTEN      367374/./AdGuardHom
tcp        0      0 10.10.2.10:53           0.0.0.0:*               LISTEN      367374/./AdGuardHom
tcp        0      0 10.10.1.10:53           0.0.0.0:*               LISTEN      367374/./AdGuardHom
tcp6       0      0 fd4e:xxxx:xxxx:8f7:53 :::*                    LISTEN      367374/./AdGuardHom
tcp6       0      0 2a06:xxxx:xxxx:3781::53 :::*                    LISTEN      367374/./AdGuardHom
udp        0      0 172.30.32.1:53          0.0.0.0:*                           367374/./AdGuardHom
udp        0      0 10.10.3.10:53           0.0.0.0:*                           367374/./AdGuardHom
udp        0      0 10.10.2.10:53           0.0.0.0:*                           367374/./AdGuardHom
udp        0      0 10.10.1.10:53           0.0.0.0:*                           367374/./AdGuardHom
udp6       0      0 fd4e:xxxxxxxxxx:53 :::*                                367374/./AdGuardHom
udp6       0      0 2a06:xxxxx:3781::53 :::*                                367374/./AdGuardHom

The result is the same. After the AdGuard update the above command doesn't return anything.

EDIT: I think I found some lead on what might be causing the issue. I checked the ip addr show and noticed that the loopback interface doesn't have the ::1 address, can't even ping it. So I checked the /etc/sysctl.conf file and found (which I completely forgot I did this in the past) I had this:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

for some reason even with this my main interface was getting IPv6 address, but the loopback doesn't seem to have it. I will do some testing tomorrow, but I think either way the AdGuard should realize there is no ::1 IP on the interface and shouldn't try to bind to it.

uroh commented 1 year ago

Just to add to this issue, unlike @naked-head I am not using ConnMan, but I have NetworkManager, my installation should be supported running on Debian 11. Yet I still get this error, exactly this one:

listen udp [::1]:53: bind: cannot assign requested address

So I don't think it is only the ConnMan causing that. My only help was to revert back to the older version. I checked what is listening on port 53 and I get this:

tcp        0      0 172.30.32.1:53          0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.3.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.2.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 10.10.1.10:53           0.0.0.0:*               LISTEN      20436/./AdGuardHome
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      330/systemd-resolve
tcp6       0      0 fd4e:xxxx:xxxx:1:xxx:53 :::*                    LISTEN      20436/./AdGuardHome
tcp6       0      0 2a06:xxxx:xxxx:xxxx::53 :::*                    LISTEN      20436/./AdGuardHome

Is it correct/normal to have the address 127.0.0.53:53? Shouldn't it be 127.0.0.1:53?

InToSSH commented 1 year ago

Is it correct/normal to have the address 127.0.0.53:53? Shouldn't it be 127.0.0.1:53?

Yes that is a normal behavior of systemd-resolved. The 127 A Class network is a loopback network a basically you can use anything in that subnet and it will work, so you can even ping 127.52.11.252 and it will work. Why they chose 53 instead 1.. I don't know.

uroh commented 1 year ago

@InToSSH, Looks like you've been to my house as well, as I've discovered a similar setup on my server. I took this opportunity to get my distro running smoothly with the home assistant. It is now fully supported except for the installation process. :)

System Information

version core-2023.1.7
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.7
os_name Linux
os_version 5.15.85-flippy-80+o
arch aarch64
timezone Europe/Rome
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4642 Installed Version | 1.30.0 Stage | running Available Repositories | 1204 Downloaded Repositories | 43
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2023.01.1 agent_version | 1.4.1 docker_version | 20.10.23 disk_total | 119.2 GB disk_used | 23.1 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | AdGuard Home (4.8.0), Bookstack (1.4.0), Caddy 2 (1.3.1), File editor (5.5.0), Grafana (8.1.0), Home Assistant Google Drive Backup (0.110.1), InfluxDB (4.5.0), Terminal & SSH (9.6.1), WireGuard (0.7.1), Zigbee2MQTT (1.29.2-1), Node-RED (14.0.1), ESPHome (2022.12.7), MariaDB (2.5.1), phpMyAdmin (0.8.3)
Dashboards dashboards | 1 -- | -- resources | 27 views | 7 mode | storage
NextDNS can_reach_server | ok -- | --
Recorder oldest_recorder_run | 20 gennaio 2023, 14:48 -- | -- current_recorder_run | 26 gennaio 2023, 18:22 estimated_db_size | 109.53 MiB database_engine | mysql database_version | 10.6.8
Sonoff version | 3.3.1 (b20e33c) -- | -- cloud_online | 0 / 6 local_online | 4 / 4
Xiaomi Miot Auto component_version | 0.7.5 -- | -- can_reach_server | ok can_reach_spec | ok logged_accounts | 1 total_devices | 2
sysadmin-info commented 1 year ago

You did restart the systemd-resolved without changing the resolved.conf. There is the whole guide and is explained what and how to modify resolv.conf. Do this, then upgrade Adguard Home and perform a check, please. Now it shows me the 502 bad gateway. I diabled the systemd-resolved.service but it did not solve the problem.

sysadmin-info commented 1 year ago

How to roll back? Go to Settings -> System -> Backups Click on the version of adguard home 4.7.6 , select small checkboxes that you want only rollback the addon adguard, there are only two checkboxes, so select both and then click restore. Then go to Settings -> Addons -> Adguard, stop the addon and start it.

m-l commented 1 year ago

For me it is sometimes crashing like below, maybe it is a hint. I run HA Supervised on RPi4. Previous version of AdGuard worked perfectly... :/ As with others, the version 4.8 cannot bind DNS to network interfaces 

2023/01/28 04:56:10.704793 [info] stopping AdGuard Home
2023/01/28 04:56:10.704813 [info] stopping http server...
2023/01/28 04:56:10.704872 [info] stopped http server
2023/01/28 04:56:10.710696 [info] dnsproxy: cache: enabled, size 4096 b
2023/01/28 04:56:10.710731 [info] MaxGoroutines is set to 300
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7dc0e0]
goroutine 1 [running]:
github.com/AdguardTeam/AdGuardHome/internal/home.(*Web).TLSConfigChanged(0x0, {0x1da2fd4, 0x382e058}, {0x0, {0x0, 0x0}, 0x0, 0x1bb, 0x355, 0x355, ...})
    github.com/AdguardTeam/AdGuardHome/internal/home/web.go:148 +0x40
github.com/AdguardTeam/AdGuardHome/internal/home.(*tlsManager).start(0x391d560)
    github.com/AdguardTeam/AdGuardHome/internal/home/tls.go:111 +0x84
github.com/AdguardTeam/AdGuardHome/internal/home.run({{0x0, 0x0}, {0xbee4ec3b, 0xd}, {0x0, 0x0}, {0x0, 0x0}, {0x0, 0x0}, ...}, ...)
    github.com/AdguardTeam/AdGuardHome/internal/home/home.go:532 +0x658
github.com/AdguardTeam/AdGuardHome/internal/home.Main({0x1d9efa0, 0x1da9f58})
    github.com/AdguardTeam/AdGuardHome/internal/home/home.go:145 +0x124
main.main()
    github.com/AdguardTeam/AdGuardHome/main.go:17 +0x28
[04:56:10] INFO: Service Adguard Home exited with code 2 (by signal 0)

With previos version all worked fine:

2023/01/28 05:01:52.231454 [info] Creating the UDP server socket
2023/01/28 05:01:52.231594 [info] Listening to udp://172.30.32.1:53
2023/01/28 05:01:52.231616 [info] Creating a TCP server socket
2023/01/28 05:01:52.231719 [info] Listening to tcp://192.168.254.20:53
2023/01/28 05:01:52.231739 [info] Creating a TCP server socket
2023/01/28 05:01:52.231816 [info] Listening to tcp://172.30.32.1:53
2023/01/28 05:01:52.232176 [info] Entering the tcp listener loop on 172.30.32.1:53
2023/01/28 05:01:52.232643 [info] Entering the UDP listener loop on 192.168.254.20:53
2023/01/28 05:01:52.233472 [info] Entering the UDP listener loop on 172.30.32.1:53
2023/01/28 05:01:52.233474 [info] Entering the tcp listener loop on 192.168.254.20:53
uroh commented 1 year ago

what do you see with the "ip a" command?

m-l commented 1 year ago

what do you see with the "ip a" command?

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:7b:58:fe brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.20/24 brd 192.168.254.255 scope global dynamic noprefixroute eth0
       valid_lft 555sec preferred_lft 555sec
    inet6 fe80::306c:21f6:a58d:cc5f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether dc:a6:32:7b:59:00 brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:a1:9b:00:59 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c7:67:ef:1b brd ff:ff:ff:ff:ff:ff
    inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
       valid_lft forever preferred_lft forever
55: veth05350d5@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether ce:af:3c:16:6c:c9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
57: veth355327d@if56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether f6:4d:29:ee:a6:3f brd ff:ff:ff:ff:ff:ff link-netnsid 1
59: vethed3d10d@if58: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 0e:d4:09:93:fa:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 1
61: vethf343779@if60: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 6e:a9:5b:8d:c8:90 brd ff:ff:ff:ff:ff:ff link-netnsid 2
63: veth9503d50@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 7a:5d:cd:ca:96:6f brd ff:ff:ff:ff:ff:ff link-netnsid 3
65: vethea5d778@if64: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 7e:79:d9:ba:d3:ba brd ff:ff:ff:ff:ff:ff link-netnsid 4
67: veth8c740ed@if66: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 7a:76:0e:18:67:5d brd ff:ff:ff:ff:ff:ff link-netnsid 5
69: vethae1d5b7@if68: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 4e:ad:57:c9:42:30 brd ff:ff:ff:ff:ff:ff link-netnsid 8
71: veth5add810@if70: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether e6:c8:88:24:46:ea brd ff:ff:ff:ff:ff:ff link-netnsid 6
73: veth872bb99@if72: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 8a:6d:96:36:fb:dd brd ff:ff:ff:ff:ff:ff link-netnsid 7
uroh commented 1 year ago

Unfortunately the latest version of adguard wants to bind to localhost including on [::1]:53. You probably have ipv6 binding disabled. Check out the latest posts, especially those from @InToSSH. You will be able to get Adguard working when "inet6" appears on all network interfaces. For example:

7: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c8:30:96:4c brd ff:ff:ff:ff:ff:ff
    inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
       valid_lft forever preferred_lft forever
    inet6 fe80::42:c8ff:fe30:964c/64 scope link 
       valid_lft forever preferred_lft forever
KruseLuds commented 1 year ago

@uroh you are saying although it is a bug, if IP6 is enabled then it should still work? Are there any other reasonable reasons why I should enable IP6 since IP4 will still be used for everything for the foreseeable future (I've turned off IP6 on my router)?

uroh commented 1 year ago

@KruseLuds, you should try to find what you are asking.

KruseLuds commented 1 year ago

@KruseLuds, you should try to find what you are asking.

Ok - why should I have to turn on ipv6 everywhere just to have Adguard work? In other words, for what other reason should I go to all that hassle?

m-l commented 1 year ago

Unfortunately the latest version of adguard wants to bind to localhost including on [::1]:53. You probably have ipv6 binding disabled.

Thank you. Indeed, re-enabling ipv6 helped.

ciB89 commented 1 year ago

I have ipv6 enabled yet have the same issue:

2023/01/31 12:11:27.651755 [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp [::1]:53: bind: cannot assign requested address

uroh commented 1 year ago

ip a?

KruseLuds commented 1 year ago

Facing the same problem with a little-bit different error for me. it is

listen udp [::1]:53: bind: cannot assign requested address

This change makes it looking for ::1 even IPv6 is disable.

I had the same issue and tried to implement IP6 on my network but I could not and my ISP tells me that IP6 is not yet available for my account, so it is impossible for me to use IP6 at this time. Therefore I still have the same issue, and did try to update to 4.8.0 and the issue has not gone away, so had to go back to the version I was using before (which is now two releases back). Needless to say, I am a little disheartened that this has been an open issue for three weeks. Why is that I wonder. FYI for all reading this thread, here is my setup:

System Information

version core-2023.2.3
installation_type Home Assistant Supervised
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.7
os_name Linux
os_version 5.10.0-21-arm64
arch aarch64
timezone America/New_York
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.30.1 Stage | running Available Repositories | 1274 Downloaded Repositories | 24
AccuWeather can_reach_server | ok -- | -- remaining_requests | 31
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Debian GNU/Linux 11 (bullseye) -- | -- update_channel | stable supervisor_version | supervisor-2023.01.1 agent_version | 1.4.1 docker_version | 23.0.1 disk_total | 915.4 GB disk_used | 14.6 GB healthy | true supported | true supervisor_api | ok version_api | ok installed_addons | AppDaemon (0.11.0), Core DNS Override (0.1.1), Duck DNS (1.15.0), File editor (5.5.0), Home Assistant Google Drive Backup (0.110.1), Log Viewer (0.14.0), Mosquitto broker (6.1.3), Samba share (10.0.0), Terminal & SSH (9.6.1), AdGuard Home (4.7.6)
Dashboards dashboards | 5 -- | -- resources | 15 views | 31 mode | storage
Recorder oldest_recorder_run | January 16, 2023 at 6:55 PM -- | -- current_recorder_run | February 12, 2023 at 6:12 PM estimated_db_size | 1916.20 MiB database_engine | sqlite database_version | 3.38.5
sysadmin-info commented 1 year ago

Hi,

If I understand correctly the IPv6 should be set for the internal network at home. Will have to find a time to figure it out and write a simple guide how to make it work. It is related to the operating system on which the Adguard Home is working as an addon, which in my case is a Home Assistant Supervised created as a docker container that is working on the host with Raspberry Pi 4b under the Debian 11. So first step should be: enable IPv6 on the host, the second step should be: figure out how to enable it for Docker container, and at the end how to enable it inside the Home Assistant Supervised and inside the addon Adguard Home. Because I think that not much people are using Adguard Home as an Home Assistant addon, I suppose that the developer is not pushed to the limit to fix the problem on his/hers end by giving an option to disable the IPv6 inside the Adguard Home addon.

Kind regards

Adrian Ambroziak

pon., 13 lut 2023, 16:01 użytkownik KruseLuds @.***> napisał:

Facing the same problem with a little-bit different error for me. it is

listen udp [::1]:53: bind: cannot assign requested address

This change https://github.com/hassio-addons/addon-adguard-home/pull/382/files#diff-a52270148c44e181fee61ac297ae1c14ec646740d424d493ea1ccc8cbdfde1aeR59-R61 makes it looking for ::1 even IPv6 is disable.

I had the same issue and tried to implement IP6 on my network but I could not and my ISP tells me that IP6 is not yet available for my account, so it is impossible for me to use IP6 at this time. Therefore I still have the same issue, and did try to update to 4.8.0 and the issue has not gone away, so had to go back to the version I was using before ()which is now two releases back). Needless to say, I am a little disheartened that this has been an open issue for three weeks. Why is that I wonder.

— Reply to this email directly, view it on GitHub https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1428088372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFULAOWNYU733JG5KJICRSDWXJEEPANCNFSM6AAAAAAUBYBDQU . You are receiving this because you were mentioned.Message ID: @.***>

KruseLuds commented 1 year ago

I am happy for you! In my case I have not installed ConnMan systemd in my distribution (armbian), in other words there is no connman.service file to edit.

Same here. And how come this bug isn't assigned to anyone yet?

Aryankids commented 1 year ago

got the same issue both on the 80 and 81 versions. is there a fix for this problem? it is very annoying to not be able to update Adguard whilst all other addons are growing

KruseLuds commented 1 year ago

This is still an issue in 4.8.1, so I had to again roll back to 4.7.6. And still not assigned to anyone?

uroh commented 1 year ago

got the same issue both on the 80 and 81 versions. is there a fix for this problem? it is very annoying to not be able to update Adguard whilst all other addons are growing

https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1407407821

sysadmin-info commented 1 year ago

Hi,

The problem for Adguard Home working as addon in Home Assistant Supervised is not so trivial. Why? Well in Home Assistant Supervised there is a network section where you can set the IP address v4 and v6. The problem is that it requires a gateway IP address. So, first you have to enable an IPv6 on the machine with Home Assistant Supervised, so you have to check what operating system is running on it and enable it. There are tutorials for Debian and other operating systems how to set it permanently. Then you have to enable IPv6 on your router, because you need gateway IP address in v6 format. I am lucky, because I have a Mikrotik router that allows to set the IPv6 for whole home network. And then at the end you provide IPv6 address if the host with Home Assistant Supervised, IPv6 gateway and save changes. It is good to restart Home Assistant Supervised and even better to restart the whole host in which the HA Supervised is running.

Kind regards

Adrian Ambroziak

wt., 21 lut 2023, 06:17 użytkownik uroh @.***> napisał:

got the same issue both on the 80 and 81 versions. is there a fix for this problem? it is very annoying to not be able to update Adguard whilst all other addons are growing

385 (comment)

https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1407407821

— Reply to this email directly, view it on GitHub https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1437874544, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFULAOU7YN6BB4TMPRD7ZFDWYRFV3ANCNFSM6AAAAAAUBYBDQU . You are receiving this because you were mentioned.Message ID: @.***>

InToSSH commented 1 year ago

I see it still troubles a lot of people. So ultimately what fixed it for me was just enabling IPv6 on the loopback interface to get the [::1] address.

root@loki:~# sysctl -w net.ipv6.conf.lo.disable_ipv6=0
root@loki:~# ifdown lo
root@loki:~# ifup lo
root@loki:~# ip addr show lo

and check that your output has the ::1 address on loopback.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

Try if Adguard works now. If it does you can persist this setting by adding this line to the /etc/sysctl.conf file:

net.ipv6.conf.lo.disable_ipv6 = 0

If you didn't get the ::1 address you can try manually adding it using:

ip addr add ::1 dev lo

If you get it working after using this command, you can in theory manually set the IP in /etc/network/interfaces:

iface lo inet6 static
    address ::1
    netmask 128
Aryankids commented 1 year ago

worked like a charm thanks @InToSSH

sysadmin-info commented 1 year ago

Hi folks,

I followed the guide provided by Jarda T. It solved the issue for good. Indeed there is no need to configure the IPv6 inside the Home Assistant at all. All you need is to allow the IPv6 on the operating system level for the loopback (127.0.0.1) connection. Have no idea why and it would be good to read about this, why this is required and how this is working in fact. For me it is not enough that I know how to figure it out to solve the problem, but I also need to know why the change has been included and how in fact it is working on the loopback. Is there any documentation I can read about it?

Kind regards

Adrian Ambroziak

On Fri, Feb 24, 2023 at 6:07 PM Aryankids @.***> wrote:

worked like a charm thanks @InToSSH https://github.com/InToSSH

— Reply to this email directly, view it on GitHub https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1444045494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFULAOWFVAUPFLCOSZUVOD3WZDTE3ANCNFSM6AAAAAAUBYBDQU . You are receiving this because you were mentioned.Message ID: @.***>

rucanunes commented 1 year ago

Where can I find the guide by Jarda please?

InToSSH commented 1 year ago

Where can I find the guide by Jarda please?

@rucanunes That would be me 😄 It's the guide I have written above https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1440825645

@sysadmin-info Yes, you don't need IPv6 set for other interfaces, or even IPv6 working on your network. The only change is that for some reason now the AdGuard wants to bind to the [::1]:53 address by default. IPv6 on loopback should be enabled by default on most distros, that's why not that many people are complaining, but for some the ::1 address is disabled on loopback. We can safely assume that the loopback will have 127.0.0.1 ipv4 address, but I think they should add a check to first see if the loopback has IPv6 enabled and if not, just produce a warning, but not fail completely, because it is not necessary to run AdGuard.

sysadmin-info commented 1 year ago

Hi folks,

in the /etc/sysctl.conf on my Raspberry Pi 4b rev. 1.4 I have these two entries added at the bottom:

net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0

I did not change anything in /etc/network/interfaces/etc/network/interfaces

These two entries solved the problem in my case.

Kind regards

Adrian Ambroziak

On Tue, Feb 28, 2023 at 11:22 AM Jarda T. @.***> wrote:

Where can I find the guide by Jarda please?

That would be me 😄 It's the guide I have written above #385 (comment) https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1440825645

— Reply to this email directly, view it on GitHub https://github.com/hassio-addons/addon-adguard-home/issues/385#issuecomment-1447924855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFULAOSZSG2DXDFLL4ZVF5LWZXGWHANCNFSM6AAAAAAUBYBDQU . You are receiving this because you were mentioned.Message ID: @.***>