HA - Core and the ultimate IPv6 thread

Tamas.Toth.ebola · April 11, 2023, 9:51am

Hi!

As it seems that I’m in an endless loop with again-and-again appeared new problems I have to ask you and just hope there are some ‘network experts’ because I’m not.

TL;DR

Almost 2 months ago my (wired) ISP (Vodafone in Hungary) changed my/their modem’s software and give me IP6 address (it seems to a /56 subnet/prefix) with the drop of the IP4 - NAT possibility (with its bridge mode) so from that point I had 2 directions to configure my LAN and reach my HA externally:

Ask my ISP to change me back to the previous state (without IP6 but with IP4 - NAT),
or stay with IP6 and acclimate with it, start knowing to handle it.

As I’m usually enough progressive, I had chosen the 2. one. And also as I did not know basically anything about IP6 it was more than a bit tricky but I hoped that with enough ambitions I can jump it (and where was just one of the extra additional challenges when I realised that Android can use only SLAAC IP6 adresses instead of statefull DHCP6 allocated, and just another that on my mobile Vodafone net I do not get IP6 address, therefore I have to search for a ‘virtual bridge’ to solve this problem, what could be the Google Home/Google Assistant integration of HA).

The current state and the environment

I have a modem from my ISP,
I have an own router on it,
I have an RPi4 for Home Assistant (Core) through Docker with ‘ipvlan’ network config to use a discrete IP6 address for it (instead of the default Docker bridge and port forwards)
I have my own, paid and manually configured global domain (with only one AAAA - DNS record) for the HA container with an also properly configured SSL certificate.
and I’m also using my RPi for DHCP4; DHCP6 and DNS4*; DNS6 relay purposes with ‘dnsmasq’.
The OS on the RPi is the latest stable Ubuntu - Server (22.10) with Netplan for network management.
All my devices are on DHCP except of the modem, the router and the RPi. (See the details later.)

My problems (deeply detailed later)

From HA - Docker container I can not ‘ping6’ the host (while the host can ping6 the container) but can ping6 all others. Ping4 works fine in every directions. (See the details later.)
Our Android phones - it seems - lose the preferred DNS-es some random minutes after their WiFi connections.
- It is even more strange that my Chromecast with Google TV (with Android) has not this problem, but it is true that it is on wired connection without regular reconnections.
- The situation is more than strange as after the problem appears I can reach every global domain except of my HA global domain and also can not reach my local domains.
- (See the details later.)
I can not configure Google Home/Google Assistant to handle HA - and which worked perfectly for years before ‘my new IP6 era’.

Details

My first ‘stable’ state detailed ‘briefly’ here, with some important problems which I tried to solve:

So in the last some weeks I made some changes to clear the problems, but sadly without (total) success, so here are the details:

(I call the ISP’s modem/router as modem, and my own router as router)

As one of my problems was the always changing DNS-es (to the modem’s primary or secondary DNS6) I tried to minimize all the not required DHCP-s (which offer DNS advertisements). While the modem defines its 192.168.0.0 IP4 subnet, and my router defines its 192.16.1.0 IP4 subnet, from this aspect they are independent of each other, but for a clear result, I disabled the modem’s DHCP4 and configure my router with static IP4 - WAN address. The result was fine but of course it did not change anything about my problems. (The routers DNS4 config is the manually defined internal RPi).
While I can not disable the stateless DHCP6 of the modem, I also configured my router with static IP6 - WAN address (with the same preferences as the auto-config did before) to the consistency (and because I did not know how DHCP6-s work (how them correlate to IP6 subnets), thus avoid any DNS advertisements from the modem). The modem defined subnet is <'/56 prefix'>00::/64, the router defined is <'/56 prefix'>71::/64 The result was also fine and from that point I could avoid my automatic DNS changes to the modem’s advertised (‘almost’ - see Android phone problems later). (The routers DNS6 config is the manually defined internal RPi).
I reconfigured the ‘dnsmasq’ with DHCP4 + SLAAC + statefull DHCP6, therefore my Android devices get DHCP4 based IP4 + SLAAC based IP6 addresses, while all the others get DHCP4 based IP4 + statefull DHCP6 based IP6 addresses.
- (The RPi’s (the host behind the ‘dnsmasq’ and the HA - Docker) network config: Static IP4 + IP6 addresses in the same subnet as the router’s LAN side, with the router as GW4 + GW6 defined, and the RPi itself as DNS4 + DNS6.)
I also reconfigured my HA - Docker config (from its default bridge + port forward config) to manually defined ‘ipvlan’ network with the same subnet as the router’s. The are no collisions, the given range is a range which “dnsmasq’s” does not use with its DHCP4/DHCP6 IP allocations. From this point I could reach my HA through its very own IP6 address, so I point onto it the corresponding global domain. It seems fine (almost).
- The ‘ipvlan’ network config on the RPi:
  - ```
  ip link add home_assistant link wlan0 type ipvlan mode l2
  ip address add 192.168.1.<'ipvlan network/gateway address'>/32 dev home_assistant
  ip address add <'/56 prefix'>71::<'ipvlan network/gateway address'>/128 dev home_assistant
  ip link set home_assistant up
  ip route add 192.168.1.<'ipvlan range'>/28 dev home_assistant
  ip route add <'/56 prefix'>71::<'ipvlan range'>/124 dev home_assistant
```
- As I wrote ‘almost fine’, it seems almost fine:
  - From HA container the RPi ping4 works, but the ping6 does not, therefore the DNS6 resolution is also broken with the RPi’s offered ‘dnsmasq’ which is on the Docker’s host.
  - Interestingly I can ping4 and also ping6 the HA container from the host (RPi), and for which the proper ‘ipvlan’ config is responsible. So I can ping6 into the container (from the host), but can not ping6 out from the container (to the host).
  - Apart from the ‘host - ping6’ problem both the IP4 and IP6 network work in the HA container as it can ping any other devices besides its host.
As the result of all the above, on desktop, the network seems fine (at least now I do not get the modem’s DNS-es as before so local domains are fine - on desktops), but sadly on Android phones the originally mentioned problem still alive (while on Chromecast with Google TV Android device is not?!). Some minutes after their WiFi connections I can not reach my HA with its global domain, and which directly offers just an AAAA record. After the problem appears I can reach my HA through its own IP6 address so the Android phones still have working IP6 networks, but interestingly I can not reach local domains nor my HA through its global domain. WTF?! (In the first some minutes I can reach both HA and local domains.)
And as the last problem I simply can not config Google Home/Google Assistant to work with HA as the ‘last step’ immediately after its configuration tells that it ‘can not reach’ the service. The problem is the very same which appears ‘a lot of times’ in HA forum, as…
- Can no longer link Google Assistant - #19 by Omnipius
- OK Google (Could not reach [test])
- Google Home: Could not reach [test] myapp. Please try again - #4 by blairy
- …etc…
- But I gave the required new parameters to the Google - Action without success, and also made a very new Google - Action without success. In the configuration flow I can do all the required steps, but after giving the auth. data I get the ‘well-known’ error message.
- (The best part of it is that earlier I was the one who tried to help the others who had lost in Google Home/Google Assistant config: Unable to link Home Assistant to Google Assistant - #54 by Tamas.Toth.ebola)
- If this problem is not the result of the ‘ping6’ problem I simply do not know where search for it further, but this easily could be the situation as on my experiments I never got it to work (at any of my configurations states). How can I debug it? When I checked last time the GCP logs I did not find them so helpful, but maybe ‘nowadays’ already the situation is different.
- And I have to tell, that I really need it as this could be the bridge on my mobile IP4 network to reach my directly IP6 addressed HA (Docker container).

Could anybody please drive me into the right direction, where I make mistakes or so? (as I’m still not sure that I really understand how IP6 works)

Please do not hesitate to ask me if you need any further configs!

Tamas.Toth.ebola · April 11, 2023, 10:13am

An interesting expansion of my detailed post is that at one point I was wrong:

I really can not ping6 from HA container its host ‘which is’ the DNS of the container, and therefore the domain name resolution also does not work with that DNS, but… without explicitly defined DNS the domain name resolution works in the container, which could be IP4 based.

I mean:

host -a google.com give me proper result,
host -a google.com 192.168.1.<'RPi'> give me proper result,
host -a google.com <'/56 prefix'>71::<'RPi'> does not give me proper result.

Therefore the HA container for first sight seems to working fine, with a latent problem, but in theory every latent problem can generate further problems and interestingly - what I did not write yet - the usually working ping4 from the container can disrupted sometimes:

The containers resolv.conf is the following:

docker exec -it Home_Assistant /bin/sh
...
/config # cat /etc/resolv.conf 
nameserver 127.0.0.11
nameserver <'/56 prefix'>71::<'RPi'>
options ndots:0

FloatingBoater · April 11, 2023, 1:16pm

Hi,
My router and (almost) all of my clients use dual-stack IPv4 + IPv6 EXCEPT devices using MQTT due to an issue report I filed back in 2022:

Note the GitHub issue comment (which could be out of date now):

github.com/home-assistant/core

Mosquitto MQTT broker integration works with IPv4, fails with IPv6

opened 06:15PM - 16 Apr 22 UTC

closed 11:13AM - 04 May 22 UTC

FloatingBoater

integration: mqtt

### The problem HASS Mosquitto only works with IPv4, with IPv6 connections cont…inually reporting `Socket error on client <unknown>, disconnecting.` in the logs, and connections rejected. Forcing clients to connect via IPv4 works immediately (e.g. not auth, MQTT, nor integration settings). Expect label `integration: mqtt` ### What version of Home Assistant Core has the issue? core-2022.4.4 ### 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 Mosquitto MQTT broker add-in ### Link to integration documentation on our website https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md ### Diagnostics information # HASS MQTT Mosquitto HASS Mosquitto only works with IPv4, with IPv6 connections continually reporting `Socket error on client <unknown>, disconnecting.` in the logs, and connections rejected. Forcing IPv4 works immediately (e.g. not auth, MQTT, nor integration settings). ## Environment * BT VDSL router serving DHCP, DNS with `*.local` internal domain names. * The router offers both IPv4 and IPv6 addresses, with a preference for IPv6. * HASS running on a RPi3: * Core core-2022.4.4 * Mosquitto add-in v6.0.1 * Tasmota integration * MQTT integration * Several devices running Tasmota 11, migrating from `Set Option 19 1` to `Set Option 19 0` to move from MQTT Discovery, to the dedicated Tasmota add-in. (As temperature sensors discovered via MQTT lack the additional `state_class:` config, which prevents long-term graphing. The Tasmota integration works). * A test laptop running Fedora 35, `mosquitto_pub`, with both IPv4 and IPv6 stacks. ## Steps to reproduce ### IPv6 fails - `Socket error` * Connect from a test laptop to HASS running mosquitto. * The initial config used a hostname for the HASS server, which the router DNS resolved to an IPv6 record. * Socket error in the Mosquitto log, no connection on the client ``` # Fails mosquitto_sub -d -i "monitor" -h homeassistant.home --username 'tasmota' --pw 'secret' -v -t '#' # Server log: 1650115240: New connection from 192.168.1.10 on port 1883. 1650115240: Socket error on client <unknown>, disconnecting. 1650115240: New connection from 192.168.1.20 on port 1883. 1650115240: Socket error on client <unknown>, disconnecting. ``` ### IPv4 works * Change the `mosquitto_sub` command line from a hostname to the explicit IPv4 address of the HASS server. * `mosquitto_sub` connects immediately without issue. ``` # works mosquitto_sub -d -i "monitor" -h 192.168.1.50 --username 'tasmota' --pw 'secret' -v -t '#' Client monitor sending CONNECT Client monitor received CONNACK (0) Client monitor sending SUBSCRIBE (Mid: 1, Topic: #, QoS: 0, Options: 0x00) Client monitor received SUBACK Subscribed (mid: 1): 0 # Server log: New connection from x - not captured properly. ``` ## Network diagnostic test ### Telnet IPv6 test - FAILS Does not connect: ``` $ telnet homeassistant.home 1883 Trying 2a00:[IPv6 address]... ^C ``` #### Telnet IPv4 Test - WORKS Connects immediately: ``` $ telnet -4 homeassistant.home 1883 Trying 192.168.1.50... Connected to homeassistant.home. Escape character is '^]'. ``` ### Example YAML snippet _No response_ ### Anything in the logs that might be useful for us? ```txt See the Diagnostics information for environment, and steps to reproduce. All IP addresses and hostnames have been sanitised - no useful data should have been removed. * 192.168.1.10 - Sonoff with DS18B20, Tasmota 11. * 192.168.1.20 - Fedora 35 laptop with mosquitto client * 192.168.1.50 - HASS on a RPi3b, hostname `homeassistant.home` (assigned by a BT VDSL hub running DHCP and DNS - hence not `*.local` and a preference for IPv6 AAAA) ``` ### Additional information I found the issue trying to fix MQTT whilst switching from MQTT Discovery, to the dedicated Tasmota add-in. The config (Tasmota clients and HASS Mosquitto) worked fine, until re-installing the Mosquitto add-in triggered a config change. Note: Tasmota temperature sensors discovered via MQTT lack the additional `state_class:` config, which prevents long-term graphing. The Tasmota integration works great and adds in the metadata. Installing the extra integration and migrating Tasmota 11 from `Set Option 19 1` to `Set Option 19 0` to use Tasmota add-in now works very well.

I’ve not tested IPv6 with HASS since, although almost all of my Fedora Fedora devices talk between themselves using IPv6.

My HASS setup is a Yellow running supervised with Android devices so I might be able to help with some testing.
TTFN,

James

trurl101 · August 12, 2024, 10:40am

I had the problem that after I removed HA from Google Assistant and wanted to connect it again, it would not work.

I asked in the HA discord forum, and someone gave the tipp to reduce exposed devices for Google Assistant in HA. So I removed all exposed devices (had been 50+) and now Google could connect, after that you can add all devices for the Assistant again. Only in the initial connection too many devices are a problem.