Open dcode opened 1 year ago
Are you using Home Assistant? I have dual-stack and I have not had any problems like this.
This might fix it, but it may be a problem with your configuration: https://github.com/mdonoughe/pylutron-caseta/commit/7ec0b3d8b6594628c89dffa8cd395e0fc2ec8ef8
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:
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.
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: @.*** https://github.com/mdonoughe/pylutron-caseta/commit/7ec0b3d8b6594628c89dffa8cd395e0fc2ec8ef8
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:
- 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.
- 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 https://github.com/gurumitts/pylutron-caseta/issues/139#issuecomment-1464810394, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJ4NTQBN7REGPCQEEL75DW3PWCNANCNFSM6AAAAAAVUAZAVY . You are receiving this because you authored the thread.Message ID: @.***>
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 usingsocket.getaddrinfo()
, which will yield potentially resolutions for both IPv4 and IPv6, but you get the family constant in the response.