UPNP: External IP and Wan status unavailable after some time

[bigon]

The problem

Hello,

The external IP and Wan status is becoming unavailable after some time for my ISP router

The data is present after router an HA reboot, but disappear after time. I don't see anything particular in the logs

What version of Home Assistant Core has the issue?

core-2023.1.7

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

upnp

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Router is the sagem Proximus bbox

external IP is: sensor.sagem_internet_gateway_device_external_ip WAN status is: binary_sensor.sagem_internet_gateway_device_wan_status

Additional information

No response

[home-assistant[bot]]

Hey there @stevenlooman, mind taking a look at this issue as it has been labeled with an integration (upnp) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `upnp` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign upnp` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

upnp documentation upnp source _{^{(message by IssueLinks)}}

[StevenLooman]

Hi @bigon , thank you for this issue.

Can you enable debug-logging as described at https://www.home-assistant.io/integrations/upnp/#debugging-integration ? Hopefully, this will give any clues about what is happening.

[bigon]

Hello,

I've enabled the logs and here is the capture

Note that at this time, HA shows "unavailable" for the external IP

[StevenLooman]

Thank you for the logs. I don't see any requests failing, only successful ones, such as:

2023-01-30 21:18:25.069 DEBUG (MainThread) [homeassistant.components.upnp] Getting data for device: IGD Device: Sagem Internet Gateway Device/uuid:75802409-bccb-40e7-8e6c-fa095ecce13e::urn:schemas-upnp-org:device:InternetGatewayDevice:1
2023-01-30 21:18:25.251 DEBUG (MainThread) [homeassistant.components.upnp] Finished fetching Sagem Internet Gateway Device data in 0.183 seconds (success: True)

Can you provide logs from where it starts failing?

[bigon]

I'll try, but note that sensor.sagem_internet_gateway_device_kib_s_received and sensor.sagem_internet_gateway_device_kib_s_sent are still showing with proper data.

So it's not completely broken.

[bigon]

Doing some more trouble shooting, I see that it work when the integration is initially added, but it HA is restarted it becomes unavailable.

Moreover, in the logs I send you I see: 2023-01-30 21:15:46.263 DEBUG (MainThread) [async_upnp_client.description_cache] Error fetching http://192.168.1.1:1990/64ee411d-ac52-4193-b943-d0e0d274145d/WFADevice.xml: ("UpnpConnectionTimeoutError('TimeoutError()', None)", None)

And indeed I see that the router is advertising that something should be found at that URL but the port is not opened (and even takes a few seconds to timeout), could that be the cause?

[AndrewMiterev]

I have a similar problem (The symptoms are 100% the same).

[StevenLooman]

Moreover, in the logs I send you I see: 2023-01-30 21:15:46.263 DEBUG (MainThread) [async_upnp_client.description_cache] Error fetching http://192.168.1.1:1990/64ee411d-ac52-4193-b943-d0e0d274145d/WFADevice.xml: ("UpnpConnectionTimeoutError('TimeoutError()', None)", None)

And indeed I see that the router is advertising that something should be found at that URL but the port is not opened (and even takes a few seconds to timeout), could that be the cause?

Thank you for investigating your own setup. Is the advertised URL exactly the same, or are there minor differences such as a different port or a different UUID (i.e., 64ee411d-ac52-4193-b943-d0e0d274145d in the URL)?

[m0wlheld]

Facing the same issue, unfortunately two possible causes happened in between working state and non-working, current state:

1. HA updated to 2023.2.4 (from 2023.2.3)
2. Unifi Dream Machine Pro (WAN Router) updated OS from 1.12.38 to 2.4.27

Since then the Unifi Network Integration discovers the UDM Pro upon restart every time, using it's internal IPv6 address. Maybe this issue is related?

I have debug logging enabled, but no errors are present. All URLs advertised are accessible and return XML.

[lucaobermaier]

Update my UDMP to 2.4.27 yesterday. WAN status is not available for me any longer.

[avataru]

Same, it worked perfectly before updating HA from 2022.12.x (not sure what the exact version was but it was from December last year) to 2023.2.5. UniFi OS was already on 2.4.27 so the issue seems to be with HA's UPnP integration.

[philmale]

Same here - running HA 2023.3.1, unifiOS 2.4.27, network 7.2.97 Traffic tx/rx sensors are working, but the binary_sensor.unifi_dream_machine_wan_status, sensor.unifi_dream_machine_external_ip, sensor.unifi_dream_machine_wan_status all no longer being provided by the integration. Logs added but can't see any errors, it looks like the sensors just not being collected or created. home-assistant_upnp_2023-03-05T14-12-10.486Z.log

[bytemgmt]

I am seeing similar issues with packets/sec, publicIP, connection status. Days up still seems to work but there are some errors logged. Attaching filter logs for async_upnp. These were working in December as well. archerAX-1800.log

I just removed and reinstalled the device - no change in functionality.

Thanks for your support!

[ausfestivus]

If you're affected by this issue, please do give a 👍 on the original issue report above. This will help the maintainers recognise the rising impact of this issue and hopefully resolve it sooner.

[StevenLooman]

Same here - running HA 2023.3.1, unifiOS 2.4.27, network 7.2.97 Traffic tx/rx sensors are working, but the binary_sensor.unifi_dream_machine_wan_status, sensor.unifi_dream_machine_external_ip, sensor.unifi_dream_machine_wan_status all no longer being provided by the integration. Logs added but can't see any errors, it looks like the sensors just not being collected or created. home-assistant_upnp_2023-03-05T14-12-10.486Z.log

I'll need the debug logging from the home assistant upnp component (and preferably ssdp) as well, otherwise I don't know what I'm looking for.

[StevenLooman]

I am seeing similar issues with packets/sec, publicIP, connection status. Days up still seems to work but there are some errors logged. Attaching filter logs for async_upnp. These were working in December as well. archerAX-1800.log

I just removed and reinstalled the device - no change in functionality.

Thanks for your support!

See the previous reply. I'll need the home assistant debug logging for the upnp component (and preferably ssdp) as well.

I do see some things which are not normal though:

    Line 2048: 2023-03-04 07:41:25.774 DEBUG (MainThread) [async_upnp_client.advertisement] Received advertisement, _remote_addr: ('fe80::1e61:b4ff:fe7d:9d8c', 39169, 0, 2), USN: uuid:f8b054a8-6172-4a78-8530-974e8740576e::urn:schemas-upnp-org:service:WANPPPConnection:1, location: http://[::1]:1900/kmgkw/rootDesc.xml
    Line 2049: 2023-03-04 07:41:25.774 DEBUG (MainThread) [async_upnp_client.ssdp_listener] Received invalid advertisement headers: {'HOST': '[FF02::C]:1900', 'CACHE-CONTROL': 'max-age=60', 'LOCATION': 'http://[::1]:1900/kmgkw/rootDesc.xml', 'SERVER': 'TP-LINK/TP-LINK UPnP/1.1 MiniUPnPd/1.8', 'NT': 'urn:schemas-upnp-org:service:WANPPPConnection:1', 'USN': 'uuid:f8b054a8-6172-4a78-8530-974e8740576e::urn:schemas-upnp-org:service:WANPPPConnection:1', 'NTS': 'ssdp:alive', 'OPT': '"http://schemas.upnp.org/upnp/1/0/"; ns=01', '01-NLS': '1', 'BOOTID.UPNP.ORG': '1', 'CONFIGID.UPNP.ORG': '1337', '_timestamp': datetime.datetime(2023, 3, 4, 7, 41, 25, 774469), '_host': 'fe80::1e61:b4ff:fe7d:9d8c%2', '_port': 39169, '_local_addr': ('::', 1900, 0, 0), '_remote_addr': ('fe80::1e61:b4ff:fe7d:9d8c', 39169, 0, 2), '_udn': 'uuid:f8b054a8-6172-4a78-8530-974e8740576e', '_location_original': 'http://[::1]:1900/kmgkw/rootDesc.xml', 'location': 'http://[::1]:1900/kmgkw/rootDesc.xml', '_source': <SsdpSource.ADVERTISEMENT: 'advertisement'>}

The router says its "device description" can be downloaded at http://[::1]:1900/kmgkw/rootDesc.xml. This is an IPv6 address, but ::1 is localhost for IPv6. This won't work of course, as home assistant will now try to connect to localhost instead of the router... This is a bug in the router.

Still, the next line states that this advertisement is ignored. The router does seem to advertise properly on IPv4. But to know what is going on in home assistant itself, I need that logging as well.

[StevenLooman]

If you're affected by this issue, please do give a 👍 on the original issue report above. This will help the maintainers recognise the rising impact of this issue and hopefully resolve it sooner.

That's not really how it works, at least for me. But I like your enthusiasm. If you really want to help, please provide logging. Or even better, provide logging and examine it where you see it failing.

[StevenLooman]

@bytemgmt, any luck with the additional logging?

[bytemgmt]

It was in my earlier post: https://github.com/home-assistant/core/files/10889061/archerAX-1800.log What am I missing?

[bytemgmt]

Actually - I just turn the monitors back on and its working now. B

[andynash]

I'm having the same problem - log attached. I'm afraid I cannot say when these sensors (e.g. wan_status) disappeared, but they certainly used to exist. Sensors like kib_s_received work fine.

Hope I'm providing the right parts of the log - I turned on debugging as per https://www.home-assistant.io/integrations/upnp/, and removed seemingly irrelevant lines (upnp activity connected with e.g. Sonos devices etc).

upnp_log.txt

I've had a look myself, and the only thing I found which looked out of place was this:

<presentationURL>http://10.5.0.1/</presentationURL>

within http://10.0.0.1:37759/rootDesc.xml.

For me, the link is valid, but 10.5.0.1 is the address of the router on a separate VLAN from the primary network, so this should be 10.0.0.1. This looks like a Unifi bug, however Home Assistant can also access this address so I suspect this is unrelated.

[StevenLooman]

Thank you for your logs (and waiting), @andynash. The interesting lines from the logs are:

2023-04-10 15:07:07.558 DEBUG (MainThread) [homeassistant.components.upnp] Setting up config entry: 2c956b7d1aac183ad548cc321c447a39
2023-04-10 15:07:07.571 DEBUG (MainThread) [homeassistant.components.upnp] Device discovered: uuid:3d315e00-6a61-4a43-a3a1-f8f0cbf04797::urn:schemas-upnp-org:device:InternetGatewayDevice:2, at: http://10.0.0.1:37759/rootDesc.xml
2023-04-10 15:07:07.572 DEBUG (MainThread) [async_upnp_client.client_factory] Creating device, description_url: http://10.0.0.1:37759/rootDesc.xml
2023-04-10 15:07:19.383 DEBUG (MainThread) [homeassistant.components.upnp] Found device using connections: {('upnp', 'uuid:3d315e00-6a61-4a43-a3a1-f8f0cbf04797'), ('mac', 'e2:63:da:5a:f3:96')}, device_entry: DeviceEntry(area_id='data_centre', config_entries={'c24785c1f5c8500eee9d5af28c00acac', '2c956b7d1aac183ad548cc321c447a39'}, configuration_url=None, connections={('mac', 'e2:63:da:5a:f3:96')}, disabled_by=None, entry_type=None, hw_version=None, id='871c160b9fbda9354ae6dd066d9adbe8', identifiers={('upnp', 'uuid:3d315e00-6a61-4a43-a3a1-f8f0cbf04797::urn:schemas-upnp-org:device:InternetGatewayDevice:2'), ('upnp_serial_number', 'e0:63:da:5a:f3:95'), ('upnp_host', '10.0.0.1')}, manufacturer='', model=None, name_by_user='Gendarme', name='', suggested_area=None, sw_version=None, via_device_id=None, is_new=False)

2023-04-10 15:07:19.383 DEBUG (MainThread) [homeassistant.components.upnp] Getting data for device: IGD Device: UniFi Dream Machine/uuid:3d315e00-6a61-4a43-a3a1-f8f0cbf04797::urn:schemas-upnp-org:device:InternetGatewayDevice:2
2023-04-10 15:07:20.928 DEBUG (MainThread) [homeassistant.components.upnp] Finished fetching UniFi Dream Machine data in 1.545 seconds (success: True)

2023-04-10 15:07:41.180 DEBUG (MainThread) [homeassistant.components.upnp] Adding binary_sensor entities: []
2023-04-10 15:07:41.186 DEBUG (MainThread) [homeassistant.components.upnp] Adding sensor entities: [<Entity UniFi Dream Machine B received>, <Entity UniFi Dream Machine B sent>, <Entity UniFi Dream Machine packets received>, <Entity UniFi Dream Machine packets sent>, <Entity UniFi Dream Machine KiB/s received>, <Entity UniFi Dream Machine KiB/s sent>, <Entity UniFi Dream Machine packets/s received>, <Entity UniFi Dream Machine packets/s sent>]

The parts are:

1. Setting up the upnp component
2. Doing the initial poll - used to determine if the device is up and which sensors are available
3. Adding the sensors

Something is happening during the 2nd stage, causing sensors not being created at the 3rd stage. Unfortunately, the logging in its current form does report what parts of the initial poll was successful, just that the device responded.

To further investigate, we either need to enable the logging of the actual traffic to and from the router. This can be done by enabling the upnp traffic logger:

logger:
  default: info
  logs:
    homeassistant.components.upnp: debug
    async_upnp_client: debug
    async_upnp_client.traffic: error
    async_upnp_client.traffic.upnp: debug

Be sure to note that this will cause a lot of additional logging, but will give us the information whether the initial poll succeeds. I think it does not, causing the sensors not to be added. The question is why this fails - but an error message should be in the traffic-logs. Hopefully this will be a clear message and not a generic one.

A second option is to use the upnp-client command to get the wan status manually. This command can be found within the async-upnp-client package. You can do this by running:

$ upnp-client call-action http://10.0.0.1:37759/rootDesc.xml WANIPC/GetStatusInfo
{"timestamp": 1684680116.7499819, "service_id": "urn:upnp-org:serviceId:WANIPConn1", "service_type": "urn:schemas-upnp-org:service:WANIPConnection:1", "action": "GetStatusInfo", "in_parameters": {}, "out_parameters": {"NewConnectionStatus": "Connected", "NewLastConnectionError": "ERROR_NONE", "NewUptime": 3295543}}

The output below the upnp-client command is an example , so you know what it should look like.

I am uncertain if you are able to run any custom commands. If you are not used to doing python development and/or installing python applications, this might not be the route for you.

Another option is to wait a bit longer. I've added more logging when doing the polls. This will be included with the next release of async-upnp-client. I am waiting for another change (optimization) that is currently being worked on, before I'll create the new release. Hopefully, this will be finished soon. If this is added, you can create new logs which will include the needed information.

So, if you can, please try option 2 or 1. If not, option 3 will be the way to go.

Regarding the presentationURL, the router is most likely leaking information here: the (primary?) IP from one subnet to another. As you've already stated, this seems to be a Unifi bug. Home Assistant does not use the presentationURL though, so this should not be a problem.

[m0wlheld]

Running upnp-client command from HA 2023.5.3 container against a UDM Pro, running UniFi OS 3.0.20:

$ upnp-client call-action http://192.168.30.1:43149/rootDesc.xml WANIPC/GetStatusInfo

returns (formatted):

{
 "timestamp": 1684735914.0331736, 
 "service_id": "urn:upnp-org:serviceId:WANIPConn1", 
 "service_type": "urn:schemas-upnp-org:service:WANIPConnection:2", 
 "action": "GetStatusInfo", 
 "in_parameters": {}, 
 "out_parameters": {
   "NewConnectionStatus": "Connected", 
   "NewLastConnectionError": "ERROR_NONE", 
   "NewUptime": 1713189
 }
}

The UDM Pro is connected to the world via WAN1, maybe "urn:schemas-upnp-org:service:WANIPConnection:2" is wrong?

[StevenLooman]

I expected the call to fail, but I guess it does not. Well, at least one things can be crossed off the list of things to investigate.

The service_id/service_type are not relevant in this case, as far as I can see.

Hopefully the added logging will provide more information. Fortunately, the change should be included with 2023.5.4 and I expect a release in the next few days.

[StevenLooman]

2023.5.4 has been released. Can you upgrade, enable the logging, restart home assistant, and provide the logs again (same thing like before)? This time more logging should be included.

[fireheadman]

also noticed this same behavior...

type: vertical-stack
cards:
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-entity-card
        entity: binary_sensor.unifi_dream_machine_wan_status
        name: UDM WAN Status
      - type: custom:mushroom-entity-card
        entity: sensor.unifi_dream_machine_external_ip
        name: UDM Ext IP Addr

[StevenLooman]

Any success regarding the logging? The same logging options/configuration should be used. The logging should simply include more information.

[ellerar]

I have the same issue with an Altice GR241AG running 2023.6.2

[maceddy]

I have the same issue with Zyxel VMG8825-T50. When I reboot the router it works again for a while.

2023-06-27 10:07:36.199 WARNING (MainThread) [homeassistant.config_entries] Config entry 'VMG8825-T50' for upnp integration not ready yet: Error connecting to device at location: http://10.0.1.1:38400/description.xml, err: ("ServerDisconnectedError('Server disconnected')", None); Retrying in background

[andynash]

2023.5.4 has been released. Can you upgrade, enable the logging, restart home assistant, and provide the logs again (same thing like before)? This time more logging should be included.

Hi Steven, I've finally had time to have another look at this, and I've emailed the logging to you.

I received a similar response to @m0wlheld when trying the upnp-client command, so hopefully the logging you've added will tell you something useful.

Thanks!

[StevenLooman]

Hi @andynash. Thank you for the logs. Unfortunately, the logs do not contains the information needed. Can you create new logs, as per instructions sent by mail? The instructions are the same as on the upnp integration page.

[Hyedryn]

Hi @StevenLooman, did you receive the required logs ? If not I can send you my logs

[StevenLooman]

Hi @Hyedryn. I don't think I have received received your logs. Can you send them again? Thank you!

[avlemos]

it's odd, but with a tp-link, I also have the IPV6 issue (for :::1)

2023-11-15 13:17:23.750 DEBUG (MainThread) [async_upnp_client.ssdp_listener] Received invalid advertisement headers: {'HOST': '[FF02::C]:1900', 'CACHE-CONTROL': 'max-age=60', 'LOCATION': 'http://[::1]:1900/mcrpb/rootDesc.xml', 'SERVER': 'TP-LINK/TP-LINK UPnP/1.1 MiniUPnPd/1.8', 'NT': 'urn:schemas-upnp-org:service:Layer3Forwarding:1', 'USN': 'uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d::urn:schemas-upnp-org:service:Layer3Forwarding:1', 'NTS': 'ssdp:alive', 'OPT': '"http://schemas.upnp.org/upnp/1/0/"; ns=01', '01-NLS': '1', 'BOOTID.UPNP.ORG': '1', 'CONFIGID.UPNP.ORG': '1337', '_host': 'fe80::2a87:baff:feab:c0b0%2', '_udn': 'uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d', '_location_original': 'http://[::1]:1900/mcrpb/rootDesc.xml', 'location': 'http://[::1]:1900/mcrpb/rootDesc.xml', '_timestamp': datetime.datetime(2023, 11, 15, 13, 17, 23, 749988), '_remote_addr': ('fe80::2a87:baff:feab:c0b0', 38312, 0, 2), '_port': 38312, '_local_addr': ('::', 1900, 0, 0), '_source': <SsdpSource.ADVERTISEMENT: 'advertisement'>}

but I also see the IPV4 going around:

2023-11-15 13:16:29.969 DEBUG (MainThread) [async_upnp_client.search] Received search response, _remote_addr: ('192.168.1.1', 1900), USN: uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d::upnp:rootdevice, location: http://192.168.1.1:1900/mcrpb/rootDesc.xml
2023-11-15 13:16:29.969 DEBUG (MainThread) [async_upnp_client.ssdp_listener] See new device: <SsdpDevice(uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d)>
2023-11-15 13:16:29.970 DEBUG (MainThread) [async_upnp_client.ssdp_listener] See new service: <SsdpDevice(uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d)>, type: upnp:rootdevice
2023-11-15 13:16:29.970 DEBUG (MainThread) [async_upnp_client.traffic.upnp] Sending request:
GET http://192.168.1.1:1900/mcrpb/rootDesc.xml

<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType>
<friendlyName>Archer AX55</friendlyName>
<manufacturer>TP-Link</manufacturer>
<manufacturerURL>http://www.tp-link.com/</manufacturerURL>
<modelDescription>Archer AX55</modelDescription>
<modelName>Archer AX55</modelName>
<modelNumber>1</modelNumber>
<modelURL>http://www.tp-link.com/</modelURL>
<serialNumber>00000000</serialNumber>
<UDN>uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d</UDN>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:Layer3Forwarding:1</serviceType>
<serviceId>urn:upnp-org:serviceId:Layer3Forwarding1</serviceId>
<controlURL>/mcrpb/ctl/L3F</controlURL>
<eventSubURL>/mcrpb/evt/L3F</eventSubURL>
<SCPDURL>/mcrpb/L3F.xml</SCPDURL>
</service>
</serviceList>
<deviceList>
<device>
<deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType>
<friendlyName>WANDevice</friendlyName>
<manufacturer>MiniUPnP</manufacturer>
<manufacturerURL>http://miniupnp.free.fr/</manufacturerURL>
<modelDescription>WAN Device</modelDescription>
<modelName>WAN Device</modelName>
<modelNumber>20230428</modelNumber>
<modelURL>http://miniupnp.free.fr/</modelURL>
<serialNumber>00000000</serialNumber>
<UDN>uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d</UDN>
<UPC>000000000000</UPC>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANCommonIFC1</serviceId>
<controlURL>/mcrpb/ctl/CmnIfCfg</controlURL>
<eventSubURL>/mcrpb/evt/CmnIfCfg</eventSubURL>
<SCPDURL>/mcrpb/WANCfg.xml</SCPDURL>
</service>
</serviceList>
<deviceList>
<device>
<deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType>
<friendlyName>WANConnectionDevice</friendlyName>
<manufacturer>MiniUPnP</manufacturer>
<manufacturerURL>http://miniupnp.free.fr/</manufacturerURL>
<modelDescription>MiniUPnP daemon</modelDescription>
<modelName>MiniUPnPd</modelName>
<modelNumber>20230428</modelNumber>
<modelURL>http://miniupnp.free.fr/</modelURL>
<serialNumber>00000000</serialNumber>
<UDN>uuid:47a269e2-9e58-4215-9dfd-339c11a77c7d</UDN>
<UPC>000000000000</UPC>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId>
<controlURL>/mcrpb/ctl/IPConn</controlURL>
<eventSubURL>/mcrpb/evt/IPConn</eventSubURL>
<SCPDURL>/mcrpb/WANIPCn.xml</SCPDURL>
</service>
</serviceList>
</device>
</deviceList>
</device>
</deviceList>
<presentationURL>http://192.168.1.1/</presentationURL>
</device>
</root>

[avlemos]

just noticed https://github.com/home-assistant/core/pull/103792 will it help? :)

[fireheadman]

realize this is closed... but wanted to comment for others that may check this. I recently upgrade my HA Host to Debian 12 (Bookworm). I noticed this is working again... so if you haven't upgrade, give it a shot and make sure to backup first.

[StevenLooman]

just noticed #103792 will it help? :)

Hopefully so, please let me know! I expect it to land in 2023.12.

[StevenLooman]

realize this is closed... but wanted to comment for others that may check this. I recently upgrade my HA Host to Debian 12 (Bookworm). I noticed this is working again... so if you haven't upgrade, give it a shot and make sure to backup first.

Perhaps IPv6 is disabled by default? (Hard to imagine though!)

As @avlemos noticed already. In the next version of Home Assistant IPv4 is preferred over IPv6. Hopefully this will fix this issue. Please let me know.

[avlemos]

it's pretty wild, but it has been working lately (without that change).

[StevenLooman]

it's pretty wild, but it has been working lately (without that change).

Great!

Can anybody else who was having the same problem reply if this problem is solved, perhaps @bigon or @andynash?

[andynash]

it's pretty wild, but it has been working lately (without that change).

Great!

Can anybody else who was having the same problem reply if this problem is solved, perhaps @bigon or @andynash?

Yep, can confirm, I hadn't realised but it is back up and running, thanks Steven!

[StevenLooman]

Then I'll close this issue. Thank you for reporting this back to me, @andynash!