[Errno 101] Network unreachable

[gittygitnice]

When I disable IPv4 in the settings of Homeassistant (Core v2025.2.4) and leave only IPv6 enabled, the following error is logged every few minutes and is spamming the log:

Logger: async_upnp_client.ssdp
Source: runner.py:154
First occurred: 20:24:12 (272 occurrences)
Last logged: 22:39:42

Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=22 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=22, family=2, type=2, proto=0, laddr=('0.0.0.0', 52238)>

When I enable IPv4 and the network adapter gets an IPv4 address via DHCP, the error no longer pops up. Can this be fixed? I moved my home lab to "IPv6 only". Thanks!

[StevenLooman]

Thank you for this issue @gittygitnice. Did you restart Home Assistant after disabling IPv4 on the network adapter?

[gittygitnice]

Yes, unfortunately the problem remains even after a reboot (I tried many times). The error shows up twice and repeats every ten minutes:

2025-03-04 18:06:06.231 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=37 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=37, family=2, type=2, proto=0, laddr=('0.0.0.0', 52388)>
2025-03-04 18:06:06.231 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=40 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=40, family=2, type=2, proto=0, laddr=('0.0.0.0', 56494)>
2025-03-04 18:16:06.232 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=37 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=37, family=2, type=2, proto=0, laddr=('0.0.0.0', 52388)>
2025-03-04 18:16:06.232 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=40 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=40, family=2, type=2, proto=0, laddr=('0.0.0.0', 56494)>

I currently only have the default integrations of Home Assistant enabled, no additional add-ons are loaded. The only thing I did was disable IPv4. (The error also shows up with IPv4 set to "Automatic" (DHCP) in Home Assistant and disabling the IPv4 DHCP Server in the network.)

If I can be of any help with identifying and fixing the problem, please let me know :)

[StevenLooman]

You've already provided information needed to try to reproduce it myself. I'll try to do so myself soon.

The cause might be in Home Assistant itself. The SSDP integration (I assume this is the cause) enumerates over all the IPs it gets from Home Assistant and starts a server for it at https://github.com/home-assistant/core/blob/0d329bd83df47c3a2ce57688ef419c373ed8499b/homeassistant/components/ssdp/__init__.py#L915C32-L915C54 I would assume that Home Assistant would not give any IPv4 IPs when IPv4 is disabled.

[gittygitnice]

Thank you for taking a look :)

[StevenLooman]

I'm trying to reproduce this, but I cannot disable (or enable, for that matter) based on IP, only on adapter. Do you an adapter which has no IPv4 IP(s), just IPv6 IPs?

Also, can you enable logging specifically for ssdp? Follow the instructions at https://www.home-assistant.io/integrations/upnp/#debugging-integration, but instead of enabling the homeassistant.components.upnp logger, enable the homeassistant.components.ssdp logger. Then restart Home Assistant and get the logs. You can either post the logs here in this issue, or mail these to me if you think it contains sensitive data.

[gittygitnice]

I just disable IPv4 in the settings of Home Assistant itself (Settings->System->Network, see attached screenshot) and only leave IPv6 enabled (SLAAC).

Here is the log (I masked the mac address part in IPv6 addresses) and deleted some (to my knowledge) unrelevant lines to make the log more concise. It is still pretty long but includes the two error messages.

Cheers!

[StevenLooman]

The log shows this:

2025-03-05 22:57:55.453 DEBUG (MainThread) [async_upnp_client.advertisement] Start listening for advertisements
2025-03-05 22:57:55.453 DEBUG (MainThread) [async_upnp_client.ssdp] Creating socket, source: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'fe80::XYZ', ('fe80::XYZ', 0, 0, 2)), target: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'ff02::c%2', ('ff02::c', 1900, 0, 2))
2025-03-05 22:57:55.453 DEBUG (MainThread) [async_upnp_client.advertisement] Binding socket, socket: <socket.socket fd=34, family=10, type=2, proto=0, laddr=('::', 0, 0, 0)>, address: ('', 1900)
2025-03-05 22:57:55.454 DEBUG (MainThread) [async_upnp_client.advertisement] Start listening for advertisements
2025-03-05 22:57:55.454 DEBUG (MainThread) [async_upnp_client.ssdp] Creating socket, source: (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '172.30.32.1', ('172.30.32.1', 0)), target: (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '239.255.255.250', ('239.255.255.250', 1900))
2025-03-05 22:57:55.454 DEBUG (MainThread) [async_upnp_client.advertisement] Binding socket, socket: <socket.socket fd=33, family=2, type=2, proto=0, laddr=('0.0.0.0', 0)>, address: ('', 1900)
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.advertisement] Start listening for advertisements
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.ssdp] Creating socket, source: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'fe80::XYZ', ('fe80::XYZ', 0, 0, 4)), target: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'ff02::c%4', ('ff02::c', 1900, 0, 4))
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.advertisement] Binding socket, socket: <socket.socket fd=36, family=10, type=2, proto=0, laddr=('::', 0, 0, 0)>, address: ('', 1900)
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.advertisement] Start listening for advertisements
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.ssdp] Creating socket, source: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'fe80::XYZ', ('fe80::XYZ', 0, 0, 3)), target: (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, 'ff02::c%3', ('ff02::c', 1900, 0, 3))
2025-03-05 22:57:55.455 DEBUG (MainThread) [async_upnp_client.advertisement] Binding socket, socket: <socket.socket fd=37, family=10, type=2, proto=0, laddr=('::', 0, 0, 0)>, address: ('', 1900)
2025-03-05 22:57:55.456 DEBUG (MainThread) [async_upnp_client.advertisement] Start listening for advertisements
2025-03-05 22:57:55.456 DEBUG (MainThread) [async_upnp_client.ssdp] Creating socket, source: (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '172.30.232.1', ('172.30.232.1', 0)), target: (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '239.255.255.250', ('239.255.255.250', 1900))
2025-03-05 22:57:55.456 DEBUG (MainThread) [async_upnp_client.advertisement] Binding socket, socket: <socket.socket fd=35, family=2, type=2, proto=0, laddr=('0.0.0.0', 0)>, address: ('', 1900)

I do think Home Assistant is still seeing network interfacer with IPv4 addresses and forwards these to the SSDP component. The SSDP component 'asks' the network component for the enabled source IPs at https://github.com/home-assistant/core/blob/e78139edf13aee5a1c4cd4ec957da4d0d3cc5a7a/homeassistant/components/ssdp/__init__.py#L269. https://github.com/home-assistant/core/blob/e78139edf13aee5a1c4cd4ec957da4d0d3cc5a7a/homeassistant/components/network/__init__.py#L79 shows the code being used, which in turn uses https://github.com/home-assistant/core/blob/e78139edf13aee5a1c4cd4ec957da4d0d3cc5a7a/homeassistant/components/network/__init__.py#L87. This only checks if the adapter itself is enabled, not if IPv4 or IPv6 is enabled or not.

[gittygitnice]

When using the "ip a" command, I can indeed see that Home Assistant assigns two IPv4 addresses from the Class B range to two virtual network interfaces(?) even if IPv4 is disabled. The network interfaces are part of the Home Assistant OS (see the attached screenshot). When enabling IPv4, the two network interfaces still get assigned two IPv4 addresses from the Class B range while the main network adapter/NIC receives a normal Class C IPv4 address from the DHCP Server. (So enabling or disabling IPv4 has no effect on the virtual network interfaces in question.)

Do you have an idea how to proceed? I don't know why Home Assistant assigns IPv4 addresses to virtual network interfaces when IPv4 is disabled and if they are required. Would it be feasible to let async ignore IPv4 addresses when the main NIC has no IPv4 assigned?

[StevenLooman]

I think there are three thing potentially to be done here. The first is to determine why the error occurs. This probably has something to do with the network set up done by Home Assistant OS. Perhaps a firewall is being changed, or there are no routes available? Or perhaps this library is doing something wrong.

Secondly, maybe the network component should look at the setting and, dependent on these settings, should or shouldn't give the IPv4 address(es) to other components such as the SSDP component. I would create an issue at the https://github.com/home-assistant/core/ repo.

Finally, Home Assistant OS should not create the IPv4 addresses when IPv4 is disabled, if possible. Maybe this isn't possible due to these addresses being used (internally) for specific purposes. Creating an issue (or looking if there hasn't been an issue about this before) can't hurt, at https://github.com/home-assistant/operating-system.

[gittygitnice]

Thank you so much for taking a closer look and for your suggestions! I started with suggestion number 3 and created a new topic here: home-assistant/operating-system#3920. Cheers!

[agners]

This discussion got my attention from the discussion at https://github.com/orgs/home-assistant/discussions/441.

Granted, HAOS could eliminate all IPv4 addresses from the internal interfaces if there is no IPv4 connectivity available externally, but this is rather tricky since it would involve re-configuring Docker network interfaces, which requires reattaching all containers etc.

I wonder why the system is raising [Errno 101] Network unreachable, when there are interfaces with valid IPv4 addressing. Technically one could argue that there could be containers (add-ons) which expose services via SSDP and IPv4, so why is Linux saying Network unreachable? 🤔

I came across the same error in Python Zeroconf a while back, see python-zeroconf/python-zeroconf#1357 for more details. While this was related to IPv6 sockets, it did direct me to the following findings.

It seems the error is related on how Linux handles interface selection/routing when multicast IPv4 target addresses are used: It seems that in this particular case there is indeed no (default) route available for IPv4 multicasts:

# ip route get 239.255.255.250
RTNETLINK answers: Network is unreachable

What works though is this:

# ip route get 239.255.255.250 from 172.30.32.1
multicast 239.255.255.250 from 172.30.32.1 dev hassio rt_offload_failed uid 0 
    cache <mc>

However, from what I can tell, get_ssdp_socket actually binds to a interface and sets a source IP, in which case (and in all my testing) sending a test packet should work 🤔. I must miss some variable here.

Details

import socket
import sys

SSDP_ADDR = "239.255.255.250"
SSDP_PORT = 1900
SOURCE_IP = "172.30.32.1"  # The hassio/docker-style IP

# SSDP M-SEARCH message
payload = (
    "M-SEARCH * HTTP/1.1\r\n"
    f"HOST: {SSDP_ADDR}:{SSDP_PORT}\r\n"
    'MAN: "ssdp:discover"\r\n'
    "MX: 1\r\n"
    "ST: ssdp:all\r\n"
    "\r\n"
).encode()

# Socket creation like async_upnp_client
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

try:
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
except (AttributeError, OSError):
    pass

sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)

# Set outbound multicast interface
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton(SOURCE_IP))

# Join group (this may be unnecessary but async_upnp_client does it preemptively)
try:
    mreq = socket.inet_aton(SSDP_ADDR) + socket.inet_aton(SOURCE_IP)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
    print("Successfully joined multicast group")
except OSError as e:
    print(f"Joining group failed: {e}")

# Now bind to ("", 1900), as async_upnp_client does
sock.bind(("", SSDP_PORT))

# Try to send the packet
print(f"Sending SSDP from {SOURCE_IP} to {SSDP_ADDR}:{SSDP_PORT}")
try:
    bytes_sent = sock.sendto(payload, (SSDP_ADDR, SSDP_PORT))
    print(f"Sent {bytes_sent} bytes")
except OSError as e:
    print(f"Send failed: {e}")

[agners]

I was just was wondering, this is actually caused by SsdpSearchListener, since according to the receive error this is a random port 🤔

@StevenLooman were you able to reproduce the issue?

What I just noticed is that Yeelight integration uses SsdpSearchListener as well 🤔

@gittygitnice do you use the Yeelight integration?

[gittygitnice]

@agners Thank you so much for following up on this! No, I haven't used the Yeelight integration and the error messages in the log ("[Errno 101] Network unreachable") appear while having only the default integrations running (Mobile App, Home Assistant Supervisor, Weather Integration, Sun Integration, Radio Browser and so forth) and IPv4 beeing disabled.

[StevenLooman]

@StevenLooman were you able to reproduce the issue?

I have never tried, as I don't have this set up personally.

What I just noticed is that Yeelight integration uses SsdpSearchListener as well 🤔

Several components use the ssdp components for discovery and don't do the discovery themselves. See https://github.com/home-assistant/core/blob/160b61e0b9c57a25def6153058996c342e752a3e/homeassistant/components/ssdp/scanner.py#L275 where the listener is created, which you were already hinting at I think. Almost every Home Assistant installation uses this component, it is part of the default configuration. One could disable ssdp, but you would loose discovery of the upnp/yeelight/dlna_dmr/dlna_dms/... devices.

Edit to add: If I remember correctly the ssdp component and/or this library was changed to directly do a search, possibly triggering this error. In case that fails then initialization fails and the listener can be removed again. Otherwise it would try searching every X seconds, triggering an error each time.

It was with #255.