IPv6-Problem mit Matter in einer VLAN-Umgebung

    Hallo swag,

    ich verstehe die von dir erläuterte Problematik und will auch nicht ausschließen, dass ich deshalb letztendlich bei meinem Workaround bleibe.

    Inzwischen geht es mir aber darum, IPV6 besser zu verstehen und das gewünschte Setup prinzipiell zum Laufen zu bringen. Ich sehe auch keinen technischen Grund, der das verhindern sollte. Es liegt also an meiner IPV6 Konfig oder an Einschränkungen im Unifi Netzwerk oder an Einschränkunegn (Bugs?) in der eingestzten (Matter-)Software.

    Und das gilt es zu identifizieren.

    Das finde ich auch super.

    Ich bin bei Dir und sehe folgende Themen.

    # IPv6:

    ##Ziel

    Verteilung unterschiedlicher unicast IPc6 Adressen entsprechen der zugeteilten Prefixe einzelner Netzte und kommonikation zwischen Geräten der Netzte.

    ggf erreichbarkeit ins Internet aus einem reinen ipv6 Netz

    ## Varianten:

    - Entwerder Public Prefix (Bevorzugt oder Local FD..)

    - Kommunkikation innerhalb einer Unifi Zone

    - Kommunkikation zwischen zwei Unifi Zones


    hier hatte ich den Eindruck das Du das für local bereits hinbekommen hast.

    ## Test:_ Pink zwischen zwei Geräten

    ## offene Punkte

    Unifi sollte sich ein öffentlichen z.B./ 62 prefix abholen.

    =====

    # IPv6 DNS

    ## Ziel

    IPv6 DNS Service sollten bereitstehen. Klarheit über die Konfiguration.

    (Ist optional da DNS Server die über IPv4 erreichbar sind liefern auch ipv6 AAAA record. Bei einen Netzwerk mit ipv4 und ipv6 eigentlich nicht beides benötigt wird, Kann aber verwirrung stiften)

    ## Varianten

    - öffentliches DNS für ip Connects die ins Internet gehen.

    - locale Namen für local angemeldete Server.

    - IPv6 DNS Server.

    ## Test

    dig -t aaaa +short google.de @resolver1.opendns.com

    2a00:1450:4016:809::2003

    ====

    # mDNS - Multicast über IPv6

    übergreifenden Multicast und Multicast DNS (mDNS) Datenkomunikation zwischen IPv6 Netzten

    (Ist unabhängig zur grundlegenden unicast IPv6 kommunikation und keine spezielle Eigenschaft von IPv6)

    (Ist Teil der ZeroConfig Methodik und für IOT relevant )

    ## Varianten

    - Unifi mCast Datentransfer

    - mDNS Reflektor wie Avahi

    - UDP Port 5353

    ## Tools

    - Windows

    - Get-NetUDPEndpoint -LocalPort 5353

    - Linux

    - mdns-scan

    - MacOS

    - dns-sd. z.B. (dns-sd -B _services._dns-sd._udp)<br>

    ## Test mDNS records von Comissioners sollten findbar sein.

    8119342D78A87D8A-23802BDBA1A2B688._matter._tcp.local

    Beispiel für ipv4

    dns-sd -Z _matter._tcp | grep local

    E7A94582A8A591DF-000000000001B669._matter._tcp SRV 0 0 34576 BC5936453B250000.local. ; Replace with unicast FQDN of target host

    F9AEE81E8AE61A3D-00000000EC94E491._matter._tcp SRV 0 0 5540 FCB4673555E0.local. ; Replace with unicast FQDN of target host

    3B5F4C0C96FD6249-00000000499FAAB9._matter._tcp SRV 0 0 5540 FCB4673555E0.local. ; Replace with unicast FQDN of target host

    9CBE73C2338D741D-0197AB2FF8805871._matter._tcp SRV 0 0 5541 E72C2444E89A.local. ; Replace with unicast FQDN of target host

    9CBE73C2338D741D-01BACB2C6C106A81._matter._tcp SRV 0 0 5541 FE94E04DCAE8.local. ; Replace with unicast FQDN of target host

    D1F6E82F69683DFB-01BBF25BD588EC31._matter._tcp SRV 0 0 5541 31DA6221AAC6.local. ; Replace with unicast FQDN of target host

    3B5F4C0C96FD6249-00000000F70C7105._matter._tcp SRV 0 0 5540 FCB467368E44.local. ; Replace with unicast FQDN of target host

    F9AEE81E8AE61A3D-00000000971C8B76._matter._tcp SRV 0 0 5540 FCB467368E44.local. ; Replace with unicast FQDN of target host

    mein HA Server (ich benutzte HA nur aus interesse)

    ping BC5936453B250000.local.

    PING bc5936453b250000.local (192.168.38.74): 56 data bytes

    64 bytes from 192.168.38.74: icmp_seq=0 ttl=64 time=2,606 ms

    ping6 BC5936453B250000.local.

    PING bc5936453b250000.local (fe80::21c9:c974:a27e:9854%en0): 56 data bytes

    (default nicht erreichbar)


    mein Tasmota Powerwwitch mit Matter

    ping FCB4673555E0.local

    PING fcb4673555e0.local (192.168.14.76): 56 data bytes

    64 bytes from 192.168.14.76: icmp_seq=0 ttl=254 time=76,761 ms

    Ich nehme es gleich vorweg: es läuft!

    Ich habe in den beiden Test-VLANs folgende IPV6 Konfig vorgenommen:

    - Interface Type Static.

    - VLAN 10: fd00:0:0:a::/64

    - VLAN 11: fd00:0:0:b::/64

    - DHCPV6 (war versehentlich von vorigen Versuchen eingestellt :-) )

    - Allow SLAAC

    Der HA-Server mit der Matter Bridge ist in VLAN 11. Der Hub (Google Hiome Mini) und das Android Handy in VLAN 10.

    Ob es mit reinem SLAAC geht werde ich noch testen. Aber der jetzige Erfolg stimmt mich optimistisch.

    Wen es interessiert: ich habe zwei Logfiles der Matter Bridge angehängt. Eines mit allen Devices im gleichen VLAN, eines mit den og. zwei VLANs. Das Device mit der Adresse fd00::b:bd0e:89f2:a944:329a ist der Google HIme Mini, der sich als Hub mit der Bridge connectet.

    gleiches Subnetz.txt

    Verschiedene Subnetze.txt

    2025-03-03 17:25:38.738 DEBUG MdnsScanner Added 4 IPs for operational device 645D8D7FFA6E6919-00000000B691F9C3._matter._tcp.local to cache (interface end0): type: udp ip: fd00::a:0:0:0:175 port: 5540 type: udp ip: fd00::a:b06f:7155:ffba:1dd1 port: 5540 type: udp ip: fe80::4cf4:1e27:6a7f:6f16%end0 port: 5540 type: udp ip: 192.168.100.68 port: 5540

    sieht mir so aus als wenn der HA auch die IPv4 anmeldet :)

    2025-03-03 17:26:19.905 DEBUG MessageExchange New exchange channel: udp://[fd00::b:bd0e:89f2:a944:329a]:5540 on session insecure/11132387312110261309 protocol: 0 exId: 35192 sess: insecure/11132387312110261309 peerSess: 0 SAT: 4000 SAI: 300 SII: 500 maxTrans: 5 MRP

    werden dort dann alle angemeldeten devices automatisch ausgetauscht, (in beide Richtungen) oder muss jedes einzeln freigeschaltet werden?

    Prima dann scheint ja auch der mdns transport per ipv6 zu funktionieren.

    Quote

    2025-03-03 17:25:38.738 DEBUG MdnsScanner Added 4 IPs for operational device 645D8D7FFA6E6919-00000000B691F9C3._matter._tcp.local to cache (interface end0): type: udp ip: fd00::a:0:0:0:175 port: 5540 type: udp ip: fd00::a:b06f:7155:ffba:1dd1 port: 5540 type: udp ip: fe80::4cf4:1e27:6a7f:6f16%end0 port: 5540 type: udp ip: 192.168.100.68 port: 5540

    sieht mir so aus als wenn der HA auch die IPv4 anmeldet :smiling_face:

    Ja, sehe ich auch so. Allerdings kommt der Pairing request aus dem anderen VLAN alleine mit der IPV6 Adresse.

    Quote

    werden dort dann alle angemeldeten devices automatisch ausgetauscht, (in beide Richtungen) oder muss jedes einzeln freigeschaltet werden?

    Es gibt in meinem Setup nur zwei Matter-Devices - die Bridge im HA und der Hub in der Google Home Welt.

    Mit dieser - scheinbar sinnlosen - Verbindung wird erreicht, dass ich alle in HA vorhandenen Datenpunkte / Devices (hauptsächlich KNX aber auch z.B. ein Pelletofen) in die Google Home Welt bringe, ohne über die Cloud zu gehen. Es gibt zwar eine offizielle Google Home Anbindung des HA, die erfordert aber, dass der HA von außen erreichbar ist.

    Ich klink mich mal in das Thema, da ich ebenfalls Matter Probleme habe in meinem Unifi Netz.

    Ich nutze HomePod Mini's als Thread Border Router.
    Aktuell versuche ich tado X Heizkörperthermostate einzubinden, das funktioniert soweit in der tado App aber nach dem Connecten bekommt diese keine Rückmeldung das es erfolgreich war.
    Die Geräte sind jedoch in der App trotzdem verfügbar.
    Was nicht funktioniert ist das Matter Linking zu HomeKit, klick ich darauf kommt eine Fehlermeldung in der tado App.

    Kann mir jemand Tipps geben was ich im Unifi Netz prüfen sollte bzw. anpassen muss?
    Merkwürdigerweise hat das alles vor 1 Jahr funktioniert, da ich so alle tado X in die tado App + HomeKit einbinden konnte.

    Ich habe im WAN IPv6 SLAAC aktiviert und alle VLANs haben eine /64 Adresse erhalten.
    Auch die Clients haben IPv6 Adressen erhalten.
    Irgendwo muss noch was unstimmig sein.

    Wenn ich einen connect des Tado direkt in HomeKit versuche sehe ich matter Pakete im Netzwerk fließen...

    Code
    user@MacPro ~ % dns-sd -B _matter._tcp local.
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
[...]
11:41:14.721  Add        2  26 local.               _matter._tcp.        A0B38588C0D050EA-00000000D849F36D
11:43:28.088  Rmv        0  26 local.               _matter._tcp.        C63DADBE5C7852D9-00000000FF273B15
11:48:17.451  Rmv        1  26 local.               _matter._tcp.        C63DADBE5C7852D9-0000000036FC898C
11:48:17.451  Rmv        0  26 local.               _matter._tcp.        A0B38588C0D050EA-00000000D849F36D


    edit:
    habe testweise mit einer alten Fritzbox ein eigenes Netz aufgebaut und dort einen HomePod Mini hinterlegt.
    Auch damit die gleichen Fehler.
    Aktuell ist die Vermutung das es wohl am neuen iOS 26 liegt, da dazu auch einige Problemmeldungen zu finden sind.


    Edit2:

    Liegt eindeutig an iOS 26, man kann neue Geräte mit HomeKit nur pairen, wenn man das iPhone neustartet und es dann direkt anstößt.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login