Unable to connect to main repeater over IPv6

[dcode]

My RadioRA3 main repeater sits on a dual-stack IPv4/IPv6 subnet. The mDNS advertisement for _lutron._tcp is published on both IPv6 and IPv4, where IPv6 seems to take priority. I can manually add the integration for the IPv4 address that I know, but it's maybe not so straightforward for all users and there may be cases where a user doesn't have IPv4. In either case, it's an unnecessary limitation.

I think the only issue is the hard-coded family specification of socket.AF_INET. I recommend using socket.getaddrinfo(), which will yield potentially resolutions for both IPv4 and IPv6, but you get the family constant in the response.

[mdonoughe]

Are you using Home Assistant? I have dual-stack and I have not had any problems like this.

[mdonoughe]

This might fix it, but it may be a problem with your configuration: mdonoughe@7ec0b3d

If you're using the hostname and have a working mDNS name resolver, this should work, even if your bridge does not support IPv6. If you're using some software that detects the device and then tries to connect by IPv6 address, that will probably not work:

1. With Caséta, even if you have routable IPv6 addresses on your network, the bridge selects a link-local IPv6 address. The address returned from mDNS service discovery must have a link name/number appended to it to be usable.
2. With Caséta, the bridge configures IPv6 and advertises its IPv6 address via mDNS but does not accept connections over IPv6.

However, I think the old code should have also worked if your mDNS resolver is working correctly. It should connect to the IPv4 address associated with the provided name.

[dcode]

I've got RA3. It advertises on both IPv4 and IPv6 (checked with avahi-browse on Fedora 37). My Home Assistant Yellow node seemingly sees the same, but upon resolution it prefers the global IPv6 route (linked to the Hurricane Electric provided subnet, provided by UDM Pro gateway) to the bridge. Since the `connect` call hard codes the family to `AF_INET`, this fails to allocate a socket to the IPv6 address. If the config flow step provided a name and that was used for the host, that might work? Not sure how that gets handled.

…

On Fri, Mar 10, 2023, 20:25 Matthew Donoughe ***@***.***> wrote: This might fix it, but it may be a problem with your configuration: ***@***.*** <mdonoughe@7ec0b3d> If you're using the hostname and have a working mDNS name resolver, this should work, even if your bridge does not support IPv6. If you're using some software that detects the device and then tries to connect by IPv6 address, that will probably not work: 1. With Caséta, even if you have routable IPv6 addresses on your network, the bridge selects a link-local IPv6 address. The address returned from mDNS service discovery must have a link name/number appended to it to be usable. 2. With Caséta, the bridge configures IPv6 and advertises its IPv6 address via mDNS but does not accept connections over IPv6. However, I think the old code should have also worked if your mDNS resolver is working correctly. It should connect to the IPv4 address associated with the provided name. — Reply to this email directly, view it on GitHub <#139 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJ4NTQBN7REGPCQEEL75DW3PWCNANCNFSM6AAAAAAVUAZAVY> . You are receiving this because you authored the thread.Message ID: ***@***.***>