Google Home: Can't Find Device

HeyItsJono commented 3 days ago

Hi there, I'm trying to pair my Matter Hub setup to the Google Home app, but I keep getting an error saying it Can't Find my device. I'm on the latest release of matter hub, running via docker compose on the same RPi running my Home assistant set up. It successfully finds my HA devices. I have a Nest Hub Gen 2 on my same wifi network, already added to Google Home. The wifi network all my devices are on is 2.4GHz. I've attached the logs with output level silly below. Any help you could offer would be much appreciated!

Screenshot_20241130-094942

hub.log

t0bst4r commented 2 days ago

The log does not include any commissioning request. I'd think there is something network related blocking the access.

Starting with the obvious questions: Do you have any special network setup? Firewall? VLAN? Did you use network: host mode for the docker container?

HeyItsJono commented 2 days ago

The log does not include any commissioning request. I'd think there is something network related blocking the access.

Starting with the obvious questions: Do you have any special network setup? Firewall? VLAN? Did you use network: host mode for the docker container?

Nothing particularly special; I did use network: host for the container (and the HA docker container is also in host mode). My Pi running Matter Hub and HA is connected by ethernet (eth0 interface) to the router, the Nest and my phone (with Google Home app) are both connected to the same router via a 2.4GHz Wifi AP. They're all on the same subnet and can all ping each other. The phone can visit the Matter Hub web interface.

The Pi's wlan0 interface is connected to a different subnet/SSID and had its own iptables rules applied specifically to that interface to block access to certain ports, however none of those ports overlap with any that Matter Hub is using, and that's a completely diff. subnet and SSID to the one any of the relevant devices in this situation are connecting to, so I don't see how it would affect things.

t0bst4r commented 2 days ago

In addition to the http port and the port of the bridge, the matter protocol needs port 5353 for mDNS, too - Just saying. To reduce noise you can also specify the mDNS-interface to eth0 via env or cli arg.

HeyItsJono commented 2 days ago

My compose fwiw:

In addition to the http port and the port of the bridge, the matter protocol needs port 5353 for mDNS, too - Just saying. To reduce noise you can also specify the mDNS-interface to eth0 via env or cli arg.

Neither ports 5353, 8482, or 5540 are blocked by my iptables rules on wlan0, but I'll try to limit mDNS to eth0 and try connecting wlan to the same 2.4GHz SSID when I get home :) I'm just conscious we're probably in different timezones, any other thoughts/suggestions for me to try whilst you're online?

t0bst4r commented 2 days ago

To be honest, I am not an expert of that protocol as well. I am just "using" it 😀 Maybe @Apollon77 could give some hint.

HeyItsJono commented 2 days ago

To be honest, I am not an expert of that protocol as well. I am just "using" it 😀 Maybe @Apollon77 could give some hint.

Hmm no luck with the following different tries:

Specified eth0
Specified wlan0 and connected Pi to the 2.4GHz Wifi my phone and nest are on
Got rid of interface specification and connected Pi to the 2.4GHz Wifi my phone and nest are on

Apollon77 commented 2 days ago

In fact the most important info is missing: IPv6 enabled in the network and on the host the bridge runs on? So all. Rework info are missing or I am blind ;-)) and especially Google will NOT work without proper IPv6. So let's start there ...

HeyItsJono commented 2 days ago

In fact the most important info is missing: IPv6 enabled in the network and on the host the bridge runs on? So all. Rework info are missing or I am blind ;-)) and especially Google will NOT work without proper IPv6. So let's start there ...

Good point! So, to get IPv6 with my docker compose setup I followed this guide.

My daemon.json file:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64",
  "experimental": true,
  "ip6tables": true,
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 },
    { "base": "fde9:28d5::/104", "size": 112 }
  ]
}

My docker-compose.yaml file:

networks:
  default:
    enable_ipv6: true

# Most services don't have a network defined, except for those with network_mode: host

My Pi 4B is on Debian bookworm and uses Network Manager. The output of nmcli:

eth0: connected to Wired connection 1
        "eth0"
        ethernet (bcmgenet), DC:A6:32:E1:06:DC, hw, mtu 1500
        ip4 default
        inet4 192.168.0.77/24
        route4 192.168.0.0/24 metric 100
        route4 default via 192.168.0.1 metric 100
        inet6 fd8d:381f:345f:c96c:8f8:dbe1:3e2f:1c4a/64
        inet6 fd2a:351b:79a7:0:e598:78bd:d609:993d/64
        inet6 fe80::6ead:73ad:c0ea:b81f/64
        route6 fd44:d1e3:7645:1::/64 via fe80::8e90:6c1d:a834:7c0d metric 100
        route6 fd8d:381f:345f:c96c::/64 metric 100
        route6 fe80::/64 metric 1024
        route6 fd2a:351b:79a7::/64 metric 100
        route6 fd2a:351b:79a7::/48 via fe80::d635:1dff:fe82:5e07 metric 100

wlan0: connected to IOT
        "Broadcom BCM43438 combo and Bluetooth Low Energy"
        wifi (brcmfmac), DC:A6:32:E1:06:DF, hw, mtu 1500
        inet4 192.168.1.77/24
        route4 192.168.1.0/24 metric 600
        route4 default via 192.168.1.1 metric 600
        inet6 fd2a:351b:79a7:1:d283:dd19:1b60:76c7/64
        inet6 fe80::9543:1d96:2ad7:649/64
        route6 fe80::/64 metric 1024
        route6 fd2a:351b:79a7:1::/64 metric 600
        route6 fd2a:351b:79a7::/48 via fe80::d635:1dff:fe82:5e08 metric 600

My devices are all able to ping each other via their link-local IPV6 addresses on my LAN: NAS -> Pi

🌐 NAS in ~ took 2s
λ sudo ping6 fe80::6ead:73ad:c0ea:b81f%eth0
PING fe80::6ead:73ad:c0ea:b81f%eth0(fe80::6ead:73ad:c0ea:b81f%eth0) 56 data bytes
64 bytes from fe80::6ead:73ad:c0ea:b81f%eth0: icmp_seq=1 ttl=64 time=0.280 ms
64 bytes from fe80::6ead:73ad:c0ea:b81f%eth0: icmp_seq=2 ttl=64 time=0.256 ms

Pi -> NAS

🌐 Pi in ~ took 4s
λ ping6 fe80::211:32ff:fe1b:d829%eth0
PING fe80::211:32ff:fe1b:d829%eth0(fe80::211:32ff:fe1b:d829%eth0) 56 data bytes
64 bytes from fe80::211:32ff:fe1b:d829%eth0: icmp_seq=1 ttl=64 time=1.32 ms
64 bytes from fe80::211:32ff:fe1b:d829%eth0: icmp_seq=2 ttl=64 time=0.222 ms
64 bytes from fe80::211:32ff:fe1b:d829%eth0: icmp_seq=3 ttl=64 time=0.242 ms

And I can curl ports on my Pi via its IPv6 link-local address successfully from other devices:

🌐 NAS in ~
λ curl -g -6 'http://[fe80::6ead:73ad:c0ea:b81f%eth0]:8123/'
<!DOCTYPE html><html><head><title>Home Assistant</title>**SNIP**

HeyItsJono commented 1 day ago

Also, stupid question, but I presume I don't need to manually expose ports 5353 and 5540 via my docker compose?

t0bst4r commented 1 day ago

No, since we are using host mode for networking, no exposing is needed

HeyItsJono commented 1 day ago

No, since we are using host mode for networking, no exposing is needed

I thought as much! And fwiw my devices are all able to curl Matter Hub's web interface from the Pi's IPv6 address. However, I did see this in the logs:

matterhub  | [ 2024-12-02T06:45:33.163Z ] [ DEBUG ] [ Matter / Transaction                               ]: Transaction offline#31 committed and unlocked 2 resources
matterhub  | [ 2024-12-02T06:45:33.182Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: 0.0.0.0:5353
matterhub  | [ 2024-12-02T06:45:33.182Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.183Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: 0.0.0.0:5353
matterhub  | [ 2024-12-02T06:45:33.184Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.185Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: 0.0.0.0:5353
matterhub  | [ 2024-12-02T06:45:33.186Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.187Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: 0.0.0.0:5353
matterhub  | [ 2024-12-02T06:45:33.188Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.189Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.190Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.191Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.192Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.192Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.193Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.194Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.195Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.196Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.196Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.197Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.198Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.199Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.200Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.201Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.201Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.202Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.203Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.204Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.205Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.205Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Socket created and bound remoteAddress: undefined:5353 localAddress: :::5353
matterhub  | [ 2024-12-02T06:45:33.207Z ] [ INFO  ] [ WebApi                                             ]: HTTP server (API & Web App) listening on port 8482
matterhub  | [ 2024-12-02T06:45:33.211Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: 192.168.0.77:5353 interface: eth0 type: udp4
matterhub  | [ 2024-12-02T06:45:33.213Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: ::%eth0:5353 interface: eth0 type: udp6
matterhub  | [ 2024-12-02T06:45:33.215Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: 192.168.1.77:5353 interface: wlan0 type: udp4
matterhub  | [ 2024-12-02T06:45:33.217Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: ::%wlan0:5353 interface: wlan0 type: udp6
matterhub  | [ 2024-12-02T06:45:33.220Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: 172.19.0.1:5353 interface: br-e40f2f6cdadd type: udp4
matterhub  | [ 2024-12-02T06:45:33.221Z ] [ DEBUG ] [ Matter / UdpChannelNode                            ]: Initialize multicast address: ::%br-e40f2f6cdadd:5353 interface: br-e40f2f6cdadd type: udp6

When it initialises multicast for the IPV4 address, it specifically intialises with my Pi's LAN IPV4 address 192.168.0.77. However, when it initialises for the IPV6 address, it does so for localhost ::%eth0:5353. Should it be trying to initialise the Pi's local-link IPV6 address here?

Further, when I try looking at what's listening to 5353 on my Pi:

λ sudo netstat --udp  --listening --programs --numeric | grep 5353
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           69690/node
udp        0      0 192.168.0.77:5353       0.0.0.0:*                           7126/python3
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           581/avahi-daemon: r
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                69690/node
udp6       0      0 :::5353                 :::*                                581/avahi-daemon: r
udp6       0      0 :::5353                 :::*                                7126/python3
udp6       0      0 fd2a:351b:79a7:0:e:5353 :::*                                7126/python3

I believe 7126/python3 is homeassistant. I can see it's correctly listening to fd2a:351b:79a7:0:e:5353 which is my Pi's global IPV6 address on both the wlan0 and eth0 interface. It's also listening on 192.168.0.77:5353 for IPV4.

In contrast 69690/node, which I believe is likely Matter Hub, only appears to be listening on :::5353 for IPV6 and 0.0.0.0:5353 for IPV4.

It's the same when I look at the bridge's port (5540):

λ sudo netstat --udp  --listening --programs --numeric | grep 5540
udp        0      0 0.0.0.0:5540            0.0.0.0:*                           69690/node
udp6       0      0 :::5540                 :::*                                69690/node

I don't know if this matters/is part of the reason I can't connect to it?

HeyItsJono commented 11 hours ago

After days of trying it's finally working and I have literally no idea why. Nothing meaningful changed. Just restarted the container as I had many many times before, and it suddenly worked. But it is running, for now...

t0bst4r / home-assistant-matter-hub

Google Home: Can't Find Device #221