HomeKit integration available on wrong network

Hi,

I am running HomeAssistant from a docker container (–net=host enabled) on a RPi.
The RPi is connected to two subnets: WiFi with IOT devices only, Eth0 “normal” network inkl mobile phones, etc.

Everything is working quite well, except that the connection to the HomeKit integration is only made available on the WiFi network, not the Eth0 network. If I switch my iPhone to the IOT network for debugging purposes everything works well, in the “normal” network, I cannot reach the HomeKit integration. I have tried both, GUI installation as well as yaml configuration with corresponding IP provision.

Now I am running out of ideas how to tell the integration which network to use. :frowning:
Any help appreciated!

tbh… If you want a more qualified answer you need to provide more infos^^

  1. which subnets
  2. routing tables

If you directly join that “network” - sure you can reach it, and if there is no other routing instance, for sure you cannot reach it…

Check your routes…

Sorry for the lack of information. I was hoping there is some configuration option that I missed, that tells the integration which network device or subnet to use.

Here is more information:

ifconfig:

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:55:13:dd:9e  txqueuelen 0  (Ethernet)
        RX packets 21383  bytes 881686 (861.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28787  bytes 2222662 (2.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.6.6  netmask 255.255.255.0  broadcast 192.168.6.255
        ether b8:27:eb:c7:7f:6e  txqueuelen 1000  (Ethernet)
        RX packets 190288  bytes 39349384 (37.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 129713  bytes 27553748 (26.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 39114  bytes 14869721 (14.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 39114  bytes 14869721 (14.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vetha4a0b76: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether aa:75:94:60:44:8e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 84 (84.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethc2838e6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 56:e3:84:31:5e:29  txqueuelen 0  (Ethernet)
        RX packets 21383  bytes 1181048 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28786  bytes 2222620 (2.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethd2ed0f7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether e6:d9:a8:1b:25:76  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 84 (84.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.7.6  netmask 255.255.255.0  broadcast 192.168.7.255
        ether b8:27:eb:92:2a:3b  txqueuelen 1000  (Ethernet)
        RX packets 772611  bytes 764723189 (729.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 760779  bytes 80138379 (76.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

You can see that the raspberry with home assistant is part of two subnetworks, 192.168.6.0 (eth0) and 192.168.7.0 (wifi). Everything works fine, in principle. The web interface is made available on both networks. All IOT devices are on the 192.168.7.0 and are accessible by home assistant. All smartphone, etc are on 192.168.6.0 and can access home assistant as well (e.g. through the corresponding app).
The HomeKit integration however, is only made available on 192.168.7.0, and thus the smartphone cannot connect to it.

I simply do not understand why the integration is on the one subnet, but not on the other (or both). And perfectly I would not only understand why that is the case, but also be able to change it :slight_smile:

HomeKit integration is currently configured by

homekit:
  - name: XYZ        
    ip_adress: 192.168.6.6
    advertise_ip: 192.168.6.6
    save_mode: true

Thanks a lot in advance!

Hi @dodger,

so basicially you have two networks. Actually I don’t use this Integration at all. But by now it seems like a network issues to me.

LAN/WIFI: Network: 192.168.6.0/24 gw: 192.168.6.1?
WIFI: 192.168.7.0/24 gw: 192.168.7.1?

Do those networks run on the same Router? Or is the PI spanning that iOT Network itself? If they are not connected to the same router, that would mean that the default route would be taken for the .6.0/24 network. And this way it would be never possible to reach that network without setting a correct route.

  1. Can you reach other devices from .6.0/24 → .7.0/24? I assume the GateWays(gw’s) are for both networks .6.1/24 and .7.1/24?

  2. Can you provide the output of “sudo netstat -tulpena” on the PI and the output of “sudo ip route” or “sudo route -n”

  3. Are you famliar with the usage of tcpdump and wireshark for tshoot? That means you try step by step to reach the devices and analyze the output in wireshark. e.g check ping.
    ping from .6.0/24 network the Pi LAN IP 192.168.6.6, then ping from the .6.0/24 network the PI WIFI 192.168.7.6 IP. Does this work? Ping another device from .6.0/24 in .7.0/24. Ping the gateways…

kr

fb

Hi,

yes, I have two networks, both are established by seperate routers. The Raspberry is conencted to both (with Eth0 and WIFI). The gateways indeed are 192.168.X.1, on both. The raspberry is 192.168.X.6 on both. So my naive assumtpion was that the raspberry can provide the HomeKit integration ‘on .6.0’ / ‘through Eth0’, and that was it :slight_smile:

  1. From .6.0/24 nothing on .7.0/24 can be reached. This is how I inteded it, to seperate the IOT devices from the rest. Also, that is why the raspberry is connected to both networks, so while it does not serve as a bridge for traffic, it can communicate with devices on both networks. Besides the HomKit stuff, this works well.

  2. sudo netstat -tulpena

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 0.0.0.0:9001            0.0.0.0:*               LISTEN      0          16090      1019/docker-proxy   
tcp        0      0 192.168.7.6:6666        0.0.0.0:*               LISTEN      0          27784      1735/python3        
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN      0          17910      975/docker-proxy    
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      0          8536       1/init              
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          20485      1308/deCONZ         
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          14798      482/sshd            
tcp        0      0 0.0.0.0:8123            0.0.0.0:*               LISTEN      0          23118      1735/python3        
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          19425      1308/deCONZ         
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      0          18871      1126/docker-proxy   
tcp        0      0 192.168.6.6:443         192.168.6.6:51708       ESTABLISHED 0          25226      1308/deCONZ         
tcp        0      0 192.168.7.6:42004       192.168.7.8:443         ESTABLISHED 0          378956     1735/python3        
tcp        0      0 192.168.6.6:8123        192.168.6.6:39472       ESTABLISHED 0          23141      1735/python3        
tcp        0      0 192.168.6.6:39472       192.168.6.6:8123        ESTABLISHED 0          23941      1521/python3.6      
tcp        0      0 127.0.0.1:38385         127.0.0.1:32782         ESTABLISHED 0          21438      1735/python3        
tcp        0      0 192.168.6.6:8123        192.168.6.60:56130      ESTABLISHED 0          517253     1735/python3        
tcp        0      0 192.168.7.6:53430       104.17.2.69:443         ESTABLISHED 0          520094     1735/python3        
tcp        0      0 192.168.6.6:51708       192.168.6.6:443         ESTABLISHED 0          25225      1735/python3        
tcp       25      0 192.168.7.6:47322       104.17.113.66:443       CLOSE_WAIT  0          21435      1735/python3        
tcp        0      0 192.168.6.6:46434       192.168.6.50:9090       ESTABLISHED 0          25219      1735/python3        
tcp        0      0 192.168.7.6:41210       192.168.7.8:443         ESTABLISHED 0          358179     1735/python3        
tcp       25      0 192.168.7.6:47320       104.17.113.66:443       CLOSE_WAIT  0          24361      1735/python3        
tcp        0    220 192.168.6.6:22          192.168.6.60:56192      ESTABLISHED 0          520664     8526/sshd: dietpi [ 
tcp        1      0 192.168.6.6:59278       192.168.6.1:49000       CLOSE_WAIT  0          27080      1735/python3        
tcp        0      0 192.168.6.6:46022       192.168.6.1:49000       ESTABLISHED 0          350865     1735/python3        
tcp        1      0 192.168.7.6:56536       142.250.186.78:443      CLOSE_WAIT  0          26206      1735/python3        
tcp        0      0 192.168.7.6:45978       65.9.84.26:443          TIME_WAIT   0          0          -                   
tcp        0      0 192.168.6.6:59242       192.168.6.1:49000       ESTABLISHED 0          26946      1735/python3        
tcp        0      0 192.168.6.6:59296       192.168.6.1:49000       ESTABLISHED 0          27155      1735/python3        
tcp        0      0 192.168.7.6:49120       104.17.3.69:443         ESTABLISHED 0          520128     1735/python3        
tcp        0      0 192.168.6.6:22          192.168.6.66:64133      ESTABLISHED 0          417422     26653/sshd: dietpi  
tcp        0      0 192.168.7.6:44002       192.168.7.8:443         ESTABLISHED 0          412331     1735/python3        
tcp        0      0 192.168.6.6:59912       192.168.6.1:49000       ESTABLISHED 0          37542      1735/python3        
tcp        1      0 192.168.6.6:53518       192.168.6.10:8080       CLOSE_WAIT  0          523090     1735/python3        
tcp        0      0 192.168.7.6:54317       192.168.7.6:1883        ESTABLISHED 0          21439      1735/python3        
tcp        0      0 127.0.0.1:32782         127.0.0.1:38385         ESTABLISHED 0          21437      1735/python3        
tcp        0      0 192.168.7.6:52234       13.224.193.41:443       TIME_WAIT   0          0          -                   
tcp        0      0 192.168.7.6:47446       65.9.84.7:443           ESTABLISHED 0          524723     1735/python3        
tcp6       0      0 :::9001                 :::*                    LISTEN      0          17950      1030/docker-proxy   
tcp6       0      0 :::9999                 :::*                    LISTEN      0          17916      982/docker-proxy    
tcp6       0      0 :::111                  :::*                    LISTEN      0          11273      1/init              
tcp6       0      0 :::22                   :::*                    LISTEN      0          14800      482/sshd            
tcp6       0      0 :::8123                 :::*                    LISTEN      0          23117      1735/python3        
tcp6       0      0 :::1883                 :::*                    LISTEN      0          18878      1146/docker-proxy   
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           0          22505      1735/python3        
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           0          20678      1308/deCONZ         
udp        0    704 0.0.0.0:1987            0.0.0.0:*                           0          23430      1735/python3        
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          12005      355/dhclient        
udp        0      0 0.0.0.0:111             0.0.0.0:*                           0          10250      1/init              
udp6       0      0 :::111                  :::*                                0          8539       1/init            
  1. sudo ip route
default via 192.168.7.1 dev wlan0 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.6.0/24 dev eth0 proto kernel scope link src 192.168.6.6 
192.168.7.0/24 dev wlan0 proto kernel scope link src 192.168.7.6 

Aaaah, the default might give a hint! I can see that already…

Unfortunately, I am not familiar with it at all.

However, I will already check if I progress on the “default” issue.

Update:
being not completely helpless but definately a novice when it is about network configuration, indeed the issue was the default gateway being set to the the router in the “wrong” subnet.
Fixing that, fixed the problem.

Thanks for pointing me to the right direction with your questions!

You’re welcome. :wink:
I work in this field, therefore I had the assumption the error is related to that.

But keep in mind, that the RPi should have a default route 0.0.0.0 to your normal router which is connected to the internet. Coze I guess your IOT Network has no internet connection?
Or well it depends on what you want to do. In my case my iOT Network has no internet at all. Also it is isolated from my other subnets.

The thing with your setup is/was, that the router .6.1 has no idea about the network .7.0/24. That means you have to add a static route on your router (.6.1) point to the RPI(6.6) and tell the router something like this ( 192.168.7.0 255.255.255.0 via 192.168.6.6) Additionaly you MUST add ip4 forwarding on the RPi.

You can check if the forwarding is already enabled via “cat /proc/sys/net/ipv4/ip_forward”
A 0 indicates its disabled, a 1 tells you its enabled. You can find plenty howtos how to set this permanetely.

BUT, if you want to have your IOT Network isolated, you should think about iptables (firewall) on the RPI to only allow flows from LAN → IOT Network for very good reasons! Especially when the RPi will be the gw for the IOT Network.
Do not break your isolated network if you have one with faulty configuration.
Feel free to ask.

cheers

fb