Issue with add-on switching from ipv4 to ipv6 after setup

[jtenniswood]

First off, thanks for this add on, it's great!

I have a minor/odd bug, when I give it my IPv4 address (192.168.1.41) the add-on sets up perfectly. Later on it shows this message, and it's switched to an IPv6 address (which I don't use). No idea why.

I've just reset it up again, using discovery (which I didn't realise it did before), so maybe this will just fix the issue, but I wanted to share in case it's a edge case bug.

Thanks again

[uvjim]

I assume you've updated the device to firmware release 20221023 or later.

I haven't done that yet and I don't have IPv6 either. I'm not seeing that behaviour with the current firmware that I'm on. I have a test device (older model but can still be updated to the latest firmwares) so I may update that and see what happens.

[jtenniswood]

Yes it’s on the latest firmware, I’m hoping the discovery path with fix the issue, I don’t want you to spend time chasing ghosts!

[uvjim]

I've just upgraded the older one so will see what happens. If the device is found via SSDP it'll attempt to update the IP based on what is in the SSDP discovery info. It may just be that I need to change the field I'm looking in with the newer firmware.

[uvjim]

Hmm... I've upgraded. Add to my test HASS instance and rebooted that multiple times (would kick a discovery into life) but I get no IPv6 address trying to take over.

If it happens to you again (or you see a pattern as to when it happens) could you enable debug logging please so I can see what's happening in the log?

[Davrosx]

I'm having the same issue. Can replicate it everytime just by restarting. I have latest firmware on the HDHomerun along with latest integration version and HA. I have to delete the instance and add it again using my ipv4 address. I have ipv6 set as disabled within HA's network settings so don't use it. I have grabbed screenshots and tried set the integration log level to debug. Link to the debug file below. From looking it seems to start connecting to my ipv4 address but at some stage in loading reverts to ipv6.

Debug log file

[uvjim]

I've requested access to the debug log to see if anything is shown in there. I'm still not seeing this issue in my test environment. However, I literally have no IPv6 at all in my environment. The router is allowed to do stuff with it but my DHCP server doesn't dish out any addresses for it at all. My guess on what is happening is this...

Device fires up and is discovered with an IPv4 address. HASS sees this. You add the integration and all is good. Sometime later, the device is rediscovered with an IPv6 address and the integration says, ooooo the IP address has changed, I'll update to use the new one. However, the new on is IPv6 so causes the issue.

Now, when you manually add the device using IPv4 it actually follows the same process if the device is discovered later using SSDP. This bit I can rectify by only allowing updates to the address if the integration was added using the config flow rather than SDDP discovery.

However, what I'd prefer to do, is work out of discovery distinguishes between IPv4 and IPv6 so that I can either give the option or just ignore IPv6 (I don't have it here so no testing will be done against it).

The other possibility is that there's a bug in the HDHomeRun firmware, but I'm currently ruling that out because I'm not seeing the issue. I suppose one thing to check would be the system log on the device (http:///log.html) to see if that holds any clues as to where the IPv6 address is coming from.

[Davrosx]

I've requested access to the debug log to see if anything is shown in there. I'm still not seeing this issue in my test environment. However, I literally have no IPv6 at all in my environment. The router is allowed to do stuff with it but my DHCP server doesn't dish out any addresses for it at all. My guess on what is happening is this...

Device fires up and is discovered with an IPv4 address. HASS sees this. You add the integration and all is good. Sometime later, the device is rediscovered with an IPv6 address and the integration says, ooooo the IP address has changed, I'll update to use the new one. However, the new on is IPv6 so causes the issue.

Now, when you manually add the device using IPv4 it actually follows the same process if the device is discovered later using SSDP. This bit I can rectify by only allowing updates to the address if the integration was added using the config flow rather than SDDP discovery.

However, what I'd prefer to do, is work out of discovery distinguishes between IPv4 and IPv6 so that I can either give the option or just ignore IPv6 (I don't have it here so no testing will be done against it).

The other possibility is that there's a bug in the HDHomeRun firmware, but I'm currently ruling that out because I'm not seeing the issue. I suppose one thing to check would be the system log on the device (http:///log.html) to see if that holds any clues as to where the IPv6 address is coming from.

I should have changed access rights to that file. My bad I forgot to make it a more public link.

Link to hdhomerun log below Hdhomerun log

My understanding from ccna courses of that type of ipv6 starting fe80 is that any ipv6 enabled device can essentially self generate those without any requirement for dhcp or supporting network infrastructure.

My router isn't ipv6 enabled as I had issues with lack of ipv6 firewall in the firmware so had to disable it or risk exposing all my devices using ipv6. I have re-enabled HA's ipv6 network settings but that didn't seem to help.

If there are any other tests or logs you want I can try various things.

[uvjim]

OK. So that's the log from the device itself. Are you able to get a debug log from HA as well please?

The device is showing that it receives a valid IPv4 address and a link-local address for IPv6. It then goes to an APIPA address on IPv4 which may explain why it is advertising the IPv6 address.

A debug log from HA is likely to tell me what HA is seeing and why I'm using IPv6 and if I could tweak to use IPv4.

[Davrosx]

OK. So that's the log from the device itself. Are you able to get a debug log from HA as well please?

The device is showing that it receives a valid IPv4 address and a link-local address for IPv6. It then goes to an APIPA address on IPv4 which may explain why it is advertising the IPv6 address.

A debug log from HA is likely to tell me what HA is seeing and why I'm using IPv6 and if I could tweak to use IPv4.

The originally linked file that you asked for access to but that should now be publicly shared was a debug log from HA.

https://drive.google.com/file/d/1ZT7o8aiqzSVGURxQAJQ6bpEJHpeGdkUr/view?usp=drivesdk

[uvjim]

D'oh. I'll have a look at that one then.

[jtenniswood]

I can confirm restarting HA does trigger the issue (through either manual setup or first time discovery setup)

[jtenniswood]

I don't have IPv6 enabled on my network either, but the HA add-on seems to think it does.

[jtenniswood]

It does however seem that the HD Homerun has made it's own IPv6 address out of nowhere. Odd!

Is it possible to have a setting in the HD add-on to enable/disable IPv6 discovery?

[uvjim]

Looking at the log it's as I thought then. The SSDP discovery packet is coming in and has all IPv6 stuff in it. The integration sees this and decides the address has changed so it'll update itself to use that. The good news is, I can mitigate that...

How does this sound?

• Only update the address if the existing configured instance was created using the SSDP discovery
• If the configured instance was configured using the config flow for using an IP or UDP discovery then ignore anything coming in from SSDP discovery.

If I have that right it should mean that you can avoid this issue by using the full config flow rather than relying on HA discovery. This would still affect those people, but it doesn't take a lot for them to reconfigure and I have no way of knowing whether they want to use IPv6 or not.

I think the overall problem here is that the HDHomeRun device (in both of your cases) is creating an IPv6 address and prioritising that over the IPv6 one. I can't stop that from happening and I'm not seeing that here - interestingly enough I think I have the same devices here as both of you on this thread which leads me to believe it is something environmental on the network.

I should be able to get a fix using the two points above (assuming you're OK with those thoughts) in today at some point if you'd want to test the beta that'd be great.

[jtenniswood]

On looking at other devices, it seems IPv6 is very much on (if not actually configured to work properly), er thanks Unifi! So I guess one fix could be to actually figure out how to set it up so it's not broken, or find out how to disable it more than it already is in Unifi

[uvjim]

For posterity, here's the device that I upgraded and am not seeing the issue on...

You'll notice it doesn't receive an IPv6 at all. However, it does also assign an APIPA address but that doesn't seem to get used by anything as the assigned local subnet is still used happily.

[jtenniswood]

I agree, I think this is a network issue not a device or add-on issue. The add-on seems to be taking the top address (which is the IPv6 one), which isn't configured correctly, so everything going sideways.

I like your suggestion about the setup. Thanks

[uvjim]

If you look at the log from @Davrosx higher up, you'll spot the packet come in from SSDP discovery. It's all IPv6 so that is what the HDHomeRun device is prioritising when it advertises (which I suppose sorta makes sense, maybe - it should possibly advertise both but, meh).

I'll work on only updating the integration instance if it was created using the SSDP discovery in the first place. What it'll mean for the two of you is: -

• removing the existing instance
• adding a new instance using either the IP or UDP discovery

You should then be good to go. It's only a change in a single file, so I'll try and get it done today to stop this nuisance happening for you.

[uvjim]

I've just released a beta which should use the rules mentioned in this thread. I'd be grateful if you could give it a try.

[Davrosx]

I've just release a beta which should use the rules mentioned in this thread. I'd be grateful if you could give it a try.

I've installed 2022.11.1b0 and confirm that after several reboots the integration remains connected without issues. It was guaranteed with the previous version that my connection would be lost after each reboot so as far as I'm concerned that seems to have fixed my issue. Thanks for the quick response. I would support the change that would ignore any post setup auto discovery when a manual setting was provided during initial setup.

[uvjim]

Brilliant. The change for when to update the host is what fixed the issue this time.

I've got no other changes to make at the moment so I'll probably push a proper release in the next day or so just in case anyone else finds a problem.

[uvjim]

Also... be careful as you may run into this as well...

https://github.com/home-assistant/frontend/issues/14288#issue-1436196937

[Berserkir-Wolf]

I can confirm the beta version has fixed the issue in my instance as well.

Interestingly, the IPv6 address is prioritised even if IPv6 is disabled on the HAss host machine, which is definitely strange behaviour.

[uvjim]

I don't think that HA cares if I'm honest. My assumption is that it just listens for SSDP advertisements and makes them available.

I'll have to have a look at the details in the log provided earlier to see if there's anything else I can use to narrow down the ones that the integration sees. The difficulty is that it is valid just not routable it would seem.

The good news is it looks like I've mitigated it for now.

[Davrosx]

I was doing some experimenting with the ipv6 issue and suspect it isn't the fault of your integration but a networking issue with the firmware of the HDHomerun and it's ipv6 implementation. Port scans on ipv4 shows 4 open ports (80,554, 5004 & 65001) but on ipv6 no ports show as open. Despite it advertising the ipv6 address and port 65001. It does respond to ipv6 imcp echo requests (ping) so there is a network path. Tried adding the integration via the ipv6 address but it just gives a "device not found" error. I would suggest that until hdhomerun fix the issues with ipv6 you build the integration with a mind to ignoring ipv6 to avoid issues. Keep up the good work with the integration. Thanks again for your help.

[Berserkir-Wolf]

Maybe don't ignore IPv6 - I know a few of us are working on making our home networks fully IPv6 compliant, and going dual-stack.

Potentially a retry in the setup to test all the addresses if the v6 one doesn't respond?

[uvjim]

I don't do anything with IPv6 at all. The integration only works with what it is given.

Based on my knowledge of how stuff works for the devices, they'll respond to a discovery request using the same mechanism that made the request. So if I use IPv4 UDP to send the discovery packet, it'll respond with addresses all in IPv4 format and the subnet that made the request.

If the request is made using IPv6 then it'll respond accordingly.

The cloud discovery mechanism is due to be removed by the end of 2022, so I'll probably end up removing that code (although it should make difference). IIRC devices that use IPv4 will be available one URL and those using IPv6 on a different one.

This shouldn't affect the integration though because if you use UDP discovery, it'll gather the devices, check against the cloud discovery and then try the discover.json on the device itself. If it gets that far it'll class it as being able to use full HTTP comms with the device, using the BaseURL that the device responded with.

If everything goes well, but the device reports itself as "legacy" then there'll be some entities that won't be created or it'll fallback to using the TCP control protocol for them if it can.

The issue here, seems to be that the devices were either manually added using an IPv4 address or discovered by SSDP and added. Then, when the new firmware came out supporting IPv6 was installed, the SSDP discovery part of HA found the device but it consisted of all IPv6 information. For that reason the integration just blindly updated the configured instance to use the newly provided information (DeviceID is used as a unique ID so it knew it was the same device).

The change I put in today keeps everything working as before, except the host information is only updated if the integration instance was configured using SSDP information in the first place. That means you can manually add the device or use UDP discovery and nothing will get updated.

Hopefully that helps understand the process a bit better. I should also add that the UDP search defaults to using IPv4 but I could override that at some point if there's a need to. I have absolutely no IPv6 here at all so would have no way of testing it even if I did override it.

[Berserkir-Wolf]

Yeah, that makes sense. HA trying to be helpful.

[uvjim]

Well, we can't blame HA. I put the code there to do the update. 🤣. I've now just guarded it so it only updates if the instance was configured using SSDP in the first place.

[uvjim]

It does however seem that the HD Homerun has made it's own IPv6 address out of nowhere. Odd!

Is it possible to have a setting in the HD add-on to enable/disable IPv6 discovery?

Sorry just saw the question at the end of this one. It's possible. It would take a bit of work and require me checking if HA exposes what network addresses are available and on which interfaces etc. The underlying library should be able to cope with it.

I think the fix in the beta released yesterday should suffice for now. Am happy to revisit it at some point though if need be.

[the-jeffski]

Came here as I had applied the firmware update and now see the errors like above with the IPv6 discovery. I tried removing, restarting and then adding back via IP as suggested but it subsequently on the next restart finds the V6 again and throws the error. Anything I can provide to help debug this more?

[uvjim]

Do the comments earlier in this thread not help? Specifically this linked one: https://github.com/uvjim/hass_hdhomerun/issues/78#issuecomment-1307936618

[the-jeffski]

Interestingly since posting I deleted all the files and re-downloaded the addon then added back and so far it seems to have held. Maybe something was cached somewhere despite it having updated to the new version number.