Core: zeroconf on multiple interfaces issue

[rds76]

Home Assistant release with the issue: any
Operating environment (Hass.io/Docker/Windows/etc.): linux pyenv
Component/platform: zeroconf
Description of problem:
On system with multiple interfaces, zeroconf exposes itself on unwanted interface with incorrect IP. IP is discovered by openening socket to google, not reflecting server_host configuration where HA is listening.

avahi-browse:

!!wrong interface, should be eth1
+ eth1.3 IPv4 Home                                          _home-assistant._tcp local
= eth1.3 IPv4 Home                                          _home-assistant._tcp local
   hostname = [Home._home-assistant._tcp.local]
   address = [A.B.C.D] !!wrong external IP taken from eth0
   port = [8123]
   txt = ["requires_api_password=true" "base_url=http://192.168.1.1:8123" "version=0.85.0"] !!correct

Is there any option to disable zeroconf at all? I do not have zeroconf: or discovery: option in configuration.yaml and zeroconf starts

[Ttech]

Is this still presently an issue with the current version of Home Assistant?

[rds76]

Yes

[Owersun]

I have the same problem, with multiple interfaces zeroconf bootstrap completely screws up to understand what goes where, take random interfaces, external ip as it's own service and so on.
Even worse it looks in 'netstat -ltpun', it tries to bind to 0.0.0.0 as many times as there are interfaces, half of which queues up packets after that without ability to process them:
udp 213440 0 0.0.0.0:5353 0.0.0.0:* 3763/python3
udp 213440 0 0.0.0.0:5353 0.0.0.0:* 3763/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 3763/python3
second column is number of packets waiting to be processed (Recv-Q).

This thing is broken when there are many interfaces, is there a way to disable zeroconf?

[nicoladefranceschi]

I have the same problem.
Doing sudo ss -nlpu I get.

State     Recv-Q     Send-Q                                Local Address:Port            Peer Address:Port                                                     
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=54))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=52))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=51))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=50))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=49))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=48))             
UNCONN    156416     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=47))             
UNCONN    0          0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=46))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=43))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=42))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=41))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=40))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=39))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=38))             
UNCONN    161792     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=37))             
UNCONN    0          0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=36))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=28))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=27))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=26))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=25))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=24))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=23))             
UNCONN    164096     0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=16))             
UNCONN    0          0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("python",pid=10571,fd=21))             
UNCONN    0          0                                           0.0.0.0:5353                 0.0.0.0:*         users:(("avahi-daemon",pid=1923,fd=12))        

There are too many sockets listening on UDP port 5353. But it seems they are not processing the packets, so they remain in the queue.

I have no idea how to debug this. Any idea?

[nicoladefranceschi]

As you can see from netdata, the UDP sockets memory keeps growing!

[Owersun]

After my debug I figured out that this started to happen after upgrade to ubuntu 19.04 (wasn't happening on 18.10), the only way to push them all through is to restart systemd-resolved (systemctl restart systemd-resolved), restarting anything else doesn't really do any difference.
And additionally the issues seem to be gone after some update either to the system or to homeassistant (I keep updating my software constantly to newer versions).
So it seems it was (or maybe still is, but to the less extent) some security measures to DNS resolver of Ubuntu that suppresses queries and make apps go this weird state.

[nicoladefranceschi]

I'm actually using Ubuntu 18.04.2 LTS
I tried systemctl restart systemd-resolved but that didn't fix it :(

[nicoladefranceschi]

Ok, I'm trying to debug what is going on.
To do that, I monkey-patched all the calls to socket.bind and I printed the stack trace of those calls.

This is the result:

*********
*********
socket.bind
('', 5353)
  File "/usr/local/lib/python3.7/threading.py", line 885, in _bootstrap
    self._bootstrap_inner()
  File "/usr/local/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 80, in _worker
    work_item.run()
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/app/homeassistant/components/homekit/__init__.py", line 226, in setup
    port=self._port, persist_file=path)
  File "/usr/src/app/homeassistant/components/homekit/accessories.py", line 219, in __init__
    super().__init__(**kwargs)
  File "/usr/local/lib/python3.7/site-packages/pyhap/accessory_driver.py", line 175, in __init__
    self.advertiser = Zeroconf()
  File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 1735, in __init__
    self._listen_socket = new_socket()
  File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 1704, in new_socket
    s.bind(('', port))
  File "a.py", line 35, in newbind
    traceback.print_stack()




*********
*********
socket.bind
('', 5353)
  File "/usr/local/lib/python3.7/threading.py", line 885, in _bootstrap
    self._bootstrap_inner()
  File "/usr/local/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 80, in _worker
    work_item.run()
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/app/homeassistant/components/homekit/__init__.py", line 226, in setup
    port=self._port, persist_file=path)
  File "/usr/src/app/homeassistant/components/homekit/accessories.py", line 219, in __init__
    super().__init__(**kwargs)
  File "/usr/local/lib/python3.7/site-packages/pyhap/accessory_driver.py", line 175, in __init__
    self.advertiser = Zeroconf()
  File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 1770, in __init__
    respond_socket = new_socket()
  File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 1704, in new_socket
    s.bind(('', port))
  File "a.py", line 35, in newbind
    traceback.print_stack()

here is the full output:
https://pastebin.com/rj8f6DU4

[nicoladefranceschi]

After removing one component at a time, I found out that the problem seems to be in /usr/local/lib/python3.7/site-packages/zeroconf.py

I believe somehow there are some sockets that are open (listening on port 5353) but never actually read anything, so the OS keeps the UDP packets in a buffer waiting "forever"

[nicoladefranceschi]

I created an issue in zeroconf.
https://github.com/jstasiak/python-zeroconf/issues/171

Hopes they find it useful and fix the problem

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[meme1337]

I have the same issue. Started occurring after enabling homekit in home assistant.
Zeroconf binds to multiple interfaces and quickly saturates memory.
Home assistant is a docker container.

[meme1337]

Bump.