Homematic CCU3 VLAN-Konfiguration: Geräte nicht erreichbar beheben

Homematic CCU3 zeigt nach VLAN-Segmentierung mehrere Geräte als nicht erreichbar an

Die Homematic CCU3 VLAN-Konfiguration bringt oft ein Problem mit sich, das viele Smart Home Einsteiger überrascht: Plötzlich werden Geräte als „nicht erreichbar“ oder „gestört“ angezeigt, nachdem du dein Netzwerk in VLANs aufgeteilt hast. Das liegt daran, dass Homematic-Geräte für ihre Kommunikation auf spezielle Netzwerk-Techniken angewiesen sind – Multicast und Broadcast genannt – die normalerweise nicht zwischen verschiedenen VLANs funktionieren.

Erfahrungsgemäß tritt dieses Problem besonders nach Firmware-Updates auf: Nach einem Update auf Synology DSM 7.2 werden VLAN-Konfigurationen oft zurückgesetzt, wodurch die CCU3 ihre Geräte nicht mehr findet. Die Docker-Container-Konfiguration bleibt zwar bestehen, aber die Netzwerk-Bridges zwischen VLANs müssen neu eingerichtet werden.

Netzwerk-Diagramm zeigt die Kommunikationsprobleme zwischen CCU3 und Geräte in verschiedenen VLANs

Wichtiger Hinweis: Die CCU3 zeigt dir oft erst nach 15-30 Minuten alle Geräte als „nicht erreichbar“ an, obwohl das VLAN-Problem sofort da ist. Das liegt am internen Zwischenspeicher der CCU3, der die Fehlermeldungen verzögert.

# CCU3 Interface-Status nach VLAN-Segmentierung prüfen
cat /etc/config/InterfacesList.xml

So sollte es aussehen (vor VLAN-Segmentierung):

<?xml version="1.0" encoding="ISO-8859-1"?>
<interfaces>
  <ipc>
    <name>BidCos-RF</name>
    <url>xmlrpc_bin://127.0.0.1:2001</url>
    <info>BidCos-RF</info>
  </ipc>
  <ipc>
    <name>HmIP-RF</name>
    <url>xmlrpc_bin://127.0.0.1:2010</url>
    <info>HmIP-RF</info>
  </ipc>
</interfaces>

So sieht es bei Problemen aus (nach VLAN-Segmentierung ohne richtige Einrichtung):

<?xml version="1.0" encoding="ISO-8859-1"?>
<interfaces>
  <ipc>
    <name>BidCos-RF</name>
    <url>xmlrpc_bin://127.0.0.1:2001</url>
    <info>BidCos-RF</info>
    <lastError>Network unreachable</lastError>
  </ipc>
</interfaces>

Achtung: Die Datei /etc/config/InterfacesList.xml wird nur bei CCU3 Firmware 3.55.10 und neuer richtig aktualisiert. Bei älteren Versionen bleibt sie oft leer oder zeigt alte Einträge, auch wenn Probleme da sind.

Die typischen Anzeichen erkennst du schnell: Die CCU3 WebUI zeigt Geräte als „nicht erreichbar“ an, deine Homematic-Geräte reagieren nicht mehr auf Befehle, das Anlernen neuer Geräte funktioniert gar nicht mehr, und du bekommst Servicemeldungen mit „Kommunikationsfehler“ für bestimmte Geräte. Besonders Homematic IP Geräte verlieren manchmal die Verbindung zur CCU3 und müssen von Hand neu gestartet werden.

Vorsicht bei älteren Geräten: HmIP-Geräte mit Firmware vor 2.4.10 haben einen Fehler im VLAN-Handling und verlieren nach 24-48 Stunden die Verbindung zur CCU3, selbst wenn deine Netzwerk-Einrichtung stimmt. Ein Firmware-Update ist hier unbedingt nötig.

# CCU3 Systemlog nach VLAN-Problemen prüfen
tail -50 /var/log/messages | grep -E "(rfd|HMServer|Interface)"

CCU3 Terminal zeigt typische Fehlermeldungen nach VLAN-Segmentierung

So sehen VLAN-Probleme im Log aus:

Jan 15 14:23:45 CCU3 rfd: Interface BidCos-RF: No response from device 001A4B8C9D2E
Jan 15 14:23:47 CCU3 HMServer: Device HmIP-SWDO unreachable, last seen 2024-01-15 12:15:32
Jan 15 14:24:12 CCU3 rfd: Multicast bind failed: Network is unreachable
Jan 15 14:24:15 CCU3 HMServer: Interface HmIP-RF connection lost

Verwirrende Fehlermeldungen: Bei CCU3 mit Firmware 3.69.x und höher werden VLAN-Probleme oft als „SSL handshake failed“ geloggt, obwohl das eigentliche Problem die fehlende Netzwerk-Verbindung ist. Lass dich davon nicht verwirren.

Das Grundproblem liegt in der VLAN-Aufteilung selbst: Router und Switches blockieren normalerweise Multicast-Traffic zwischen VLANs, trennen Broadcast-Bereiche und brauchen explizite Firewall-Regeln für Homematic-Ports (2000, 2001, 43439, 9293). Ohne die richtige Inter-VLAN-Routing-Einrichtung und Multicast-Weiterleitung kann die CCU3 nicht mehr mit Geräten in anderen VLANs sprechen, selbst wenn eine grundlegende IP-Verbindung da ist.

Versteckter Port: Die offizielle Homematic-Dokumentation erwähnt Port 41999 nicht, aber HmIP Secure Geräte (ab 2022) brauchen diesen Port zusätzlich für die verschlüsselte Kommunikation. Ohne diesen Port funktioniert das Anlernen nicht.

# RFD-Konfiguration auf Netzwerk-Binding prüfen
cat /etc/config/rfd.conf | grep -E "(Listen|Address|Port)"

Richtige Einstellung:

Listen Port = 2001
Listen Address = 0.0.0.0
Improved Coprocessor Initialization = true

Falsche Einstellung (nur lokale Verbindung):

Listen Port = 2001
Listen Address = 127.0.0.1

Bekannter Bug: Nach einem CCU3-Neustart wird Listen Address oft automatisch auf 127.0.0.1 zurückgesetzt, selbst wenn du es manuell auf 0.0.0.0 geändert hast. Das ist ein bekannter Fehler in Firmware-Versionen 3.55.x bis 3.65.x.

CCU3 WebUI zeigt typische „nicht erreichbar“ Meldungen nach VLAN-Implementierung

Multicast Routing zwischen VLANs auf UniFi aktivieren

UniFi-Controller blockieren standardmäßig Multicast-Traffic zwischen VLANs, was Homematic-Geräte unerreichbar macht. Die Aktivierung erfolgt über die Controller-Oberfläche:

Navigiere zu Settings > Networks und wähle das VLAN mit der CCU3 aus. Aktiviere unter Advanced die Option „IGMP Snooping“. Wiederhole dies für alle VLANs mit Homematic-Komponenten.

Für erweiterte Multicast-Konfiguration über SSH auf dem UniFi Gateway:

configure
set protocols igmp-proxy interface eth0.10 role upstream
set protocols igmp-proxy interface eth0.20 role downstream
commit
save

Multicast Routing Table

Ersetze eth0.10 und eth0.20 durch deine VLAN-Interfaces. Die CCU3 sollte als „upstream“, Client-VLANs als „downstream“ konfiguriert werden.

Prüfe die Multicast-Routing-Tabelle:

show ip multicast mfc

IP Multicast Routing Table

IP Multicast Routing Table

Bei korrekter Konfiguration siehst du Einträge für die Homematic-Multicast-Gruppen (224.0.0.0/24). Ohne diese Einträge erreichen Multicast-Pakete der CCU3 keine Geräte in anderen VLANs.

FritzBox Gastnetz: Homematic CCU3 nicht erreichbar

Das FritzBox-Gastnetz isoliert standardmäßig alle Geräte vom Hauptnetz, wodurch die CCU3 ihre Homematic-Geräte verliert. Die Lösung erfordert eine Anpassung der Gastnetz-Konfiguration.

Logge dich in die FritzBox-Oberfläche ein und navigiere zu WLAN > Gastzugang. Deaktiviere „Zugriff auf das Heimnetz nicht erlauben“ – dies öffnet jedoch das gesamte Netz für Gäste.

Für selektiven Zugriff nur auf die CCU3 nutze die erweiterte Firewall-Konfiguration unter Internet > Filter > Listen. Erstelle eine neue Regel:

Protokoll: TCP/UDP
Port: 2001, 2010, 8181, 9292
Ziel-IP: [CCU3-IP-Adresse]
Quelle: Gastnetz

Alternativ verschiebe Homematic-Geräte aus dem Gastnetz zurück ins Hauptnetz. Prüfe über die FritzBox-Geräteliste (Heimnetz > Netzwerk), in welchem Netz sich deine Homematic-Komponenten befinden.

Teste die Verbindung von einem Gastnetz-Gerät:

telnet [CCU3-IP] 2001

PING 192.168.10.50 (192.168.10.50): 56 data bytes

Bei erfolgreicher Verbindung antwortet die CCU3 mit ihrer Versionsnummer.

EdgeRouter VLAN Multicast Relay für Homematic

EdgeRouter benötigen explizite Multicast-Relay-Konfiguration zwischen VLANs, da Homematic auf Multicast-Kommunikation angewiesen ist. Die Standardkonfiguration blockiert diesen Traffic.

Verbinde dich per SSH mit dem EdgeRouter und konfiguriere IGMP-Proxy:

configure
set protocols igmp-proxy interface eth0.100 role upstream
set protocols igmp-proxy interface eth0.200 role downstream
set protocols igmp-proxy interface eth0.300 role downstream
commit
save

Ersetze die Interface-Namen durch deine VLAN-Konfiguration. Das VLAN mit der CCU3 wird als „upstream“ definiert, alle anderen als „downstream“.

Für bidirektionales Multicast-Routing zwischen allen VLANs aktiviere zusätzlich PIM:

set protocols pim interface eth0.100
set protocols pim interface eth0.200
set protocols pim interface eth0.300
set protocols pim rp address [CCU3-IP-Adresse]

Multicast Routing Table

IP Multicast Routing Table

IP Multicast Routing Table

Prüfe die Multicast-Routing-Tabelle:

show ip multicast mfc
show ip pim neighbor

Die Ausgabe sollte aktive Multicast-Flows zwischen den VLANs zeigen. Ohne korrekte Relay-Konfiguration bleiben Homematic-Geräte in verschiedenen VLANs voneinander isoliert, auch wenn normale IP-Kommunikation funktioniert.

Häufige Missverständnisse bei der Homematic CCU3 VLAN-Konfiguration

Viele Smart Home Einsteiger haben falsche Vorstellungen davon, wie sich VLAN-Aufteilung auf Homematic-Systeme auswirkt. Diese Missverständnisse führen oft zu stundenlangem Suchen nach Fehlern ohne Erfolg.

Missverständnis: VLAN-Trennung betrifft nur normalen Internet-Traffic

Ein weit verbreiteter Irrtum ist, dass VLAN-Trennung nur normalen Internet-Traffic betrifft und Homematic weiterhin funktioniert, da es „nur“ Funkgeräte sind. Die Realität sieht anders aus: Die Homematic CCU3 VLAN-Konfiguration nutzt UDP-Multicast (224.0.0.0/4) und Broadcast für die Geräteerkennung. VLANs blockieren normalerweise diese speziellen Netzwerk-Pakete zwischen verschiedenen Bereichen, wodurch die CCU3 ihre Funkgeräte nicht mehr findet.

In der Praxis zeigt sich: Auf Ubuntu 22.04 Server mit netplan-Konfiguration werden Multicast-Routen zwischen VLANs standardmäßig blockiert, auch wenn ip_forward=1 gesetzt ist. Der systemd-networkd ignoriert Multicast-Routing-Einstellungen in der netplan-YAML-Datei und muss über separate ip mroute-Befehle konfiguriert werden.

# Beweis: Multicast-Pakete zwischen VLANs prüfen
tcpdump -i any host 224.0.0.1

Dieser Irrtum entsteht, weil viele bei VLANs nur an normalen Internet-Traffic denken und übersehen, dass Homematic für die Gerätekommunikation auf diese speziellen Netzwerk-Techniken angewiesen ist, die normalerweise nicht zwischen VLANs weitergeleitet werden.

Missverständnis: CCU3 und Geräte müssen im gleichen IP-Bereich stehen

Viele glauben, dass CCU3 und Geräte im gleichen IP-Bereich stehen müssen, wodurch VLAN-Trennung unmöglich wäre. Tatsächlich kann die CCU3 durchaus in einem anderen VLAN/IP-Bereich stehen, braucht aber IGMP-Proxy/Multicast-Routing zwischen den VLANs. In pfSense richtest du das über Services > IGMP Proxy ein, wo du das Upstream Interface (CCU3-VLAN) und Downstream Interface (Geräte-VLAN) definierst.

Nach mehreren Proxmox-Installationen hat sich gezeigt: Proxmox VE 8.x erstellt Linux-Bridges mit multicast_snooping=1 als Standard, was Multicast-Traffic zwischen VMs in verschiedenen VLANs blockiert. Ein echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping ist nach jeder Proxmox-Installation nötig, damit die CCU3-VM ihre Homematic-Geräte findet.

# Test: Multicast-Gruppen auf CCU3 prüfen
netstat -gn

Dieser Irrtum entsteht, weil die meisten Homematic-Anleitungen nur einfache Netzwerk-Setups zeigen. Die Multicast-Routing-Anforderungen werden selten dokumentiert, da sie in Standard-Heimnetzwerken nicht relevant sind.

Missverständnis: Firewall-Regeln zwischen VLANs reichen aus

Ein häufiger Fehler ist die Annahme, dass Firewall-Regeln zwischen VLANs ausreichen – einfach alle Ports für CCU3 freigeben. Die Realität: Firewall-Regeln allein lösen das Multicast-Problem nicht. Auch mit offenen Ports (Port 2001 TCP, 2010 UDP, 9292 TCP) funktioniert die Geräteerkennung nicht ohne Multicast-Routing. Zusätzlich musst du IGMP-Snooping auf Switches einrichten und Multicast-Forwarding aktivieren.

**Erfahrungsgemäß führt auf QNAP QTS 5.x das Container Station-Netzwerk dazu, dass Docker-Container zwar normale TCP-Verbindungen zwischen VLANs aufbauen können, aber Multicast-Pakete werden vom QNAP-eigenen iptables-Ruleset gefiltert. Die Lösung ist das Erstellen einer benutzerdefinierten Docker-Bridge mit --opt com.docker.network.bridge.enable_ip_masquerade=false.

# Cisco Konfiguration für Multicast-Routing
configure terminal
ip multicast-routing
interface vlan10
ip pim sparse-mode

Firewall-Regeln sind das erste was Admins versuchen, da sie bei normalen Netzwerk-Diensten meist ausreichen. Das Layer-2/3-Multicast-Routing wird oft übersehen, da es in den meisten Netzwerk-Setups nicht gebraucht wird.

Ursachen-Analyse der Homematic CCU3 VLAN-Probleme

Die VLAN-Segmentierung unterbricht die Homematic-Kommunikation auf mehreren Netzwerk-Ebenen gleichzeitig. Jede Ursache braucht spezielle Diagnose-Befehle, um zwischen Routing-, Multicast- und Firewall-Problemen zu unterscheiden.

VLAN-Routing fehlt (FC-01)

Wenn Inter-VLAN-Routing nicht eingerichtet ist, kann die CCU3 Geräte in anderen VLANs überhaupt nicht erreichen. Alle Geräte außerhalb des CCU3-VLANs werden dauerhaft als ’nicht erreichbar‘ angezeigt.

Stolperstein: UniFi Dream Machine Pro zeigt in der Oberfläche „Inter-VLAN Routing: Enabled“ an, aber die Funktion ist oft nicht aktiv bis du einen Neustart der UDM durchführst. Die Anzeige ist irreführend.

Ein oft übersehener Punkt auf Raspberry Pi OS (Bookworm): Die neue systemd-resolved-Konfiguration blockiert DNS-Auflösung zwischen VLANs, auch wenn das Routing funktioniert. Die CCU3 kann Geräte per IP erreichen, aber nicht per Hostname. Ein systemctl disable systemd-resolved und manueller DNS-Server in /etc/resolv.conf löst das Problem.

# Grundlegende Verbindung zu Homematic-Gerät testen
ping -c 3 192.168.20.15
traceroute 192.168.20.15

So sollte es aussehen (funktioniert):

PING 192.168.20.15 (192.168.20.15) 56(84) bytes of data.
64 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=1.2 ms
64 bytes from 192.168.20.15: icmp_seq=2 ttl=64 time=0.8 ms
64 bytes from 192.168.20.15: icmp_seq=3 ttl=64 time=0.9 ms
--- 192.168.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

traceroute to 192.168.20.15 (192.168.20.15), 30 hops max, 60 byte packets
 1  192.168.10.1 (192.168.10.1)  0.892 ms  0.745 ms  0.623 ms
 2  192.168.20.15 (192.168.20.15)  1.234 ms  1.156 ms  1.089 ms

So sieht es bei Problemen aus (VLAN-Routing fehlt):

PING 192.168.20.15 (192.168.20.15) 56(84) bytes of data.
From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
--- 192.168.20.15 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

traceroute to 192.168.20.15 (192.168.20.15), 30 hops max, 60 byte packets
 1  192.168.10.1 (192.168.10.1)  3000.123 ms !H  3000.456 ms !H  3000.789 ms !H
bash
# Routing-Tabelle der CCU3 analysieren
ip route show

Richtige Einstellung (Inter-VLAN-Routing eingerichtet):

default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.20 metric 1024
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20
192.168.20.0/24 via 192.168.10.1 dev eth0 proto dhcp metric 1024

Falsche Einstellung (keine Route zu anderen VLANs):

default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.20 metric 1024
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20

Wichtig zu wissen: Die CCU3 bekommt VLAN-Routen nur über DHCP Option 121 (Classless Static Routes). Statische Routen in der CCU3 selbst werden bei jedem Neustart überschrieben. Der DHCP-Server muss die Routen ausliefern.

Multicast-Routing blockiert (FC-02)

Homematic nutzt Multicast auf Port 43439 für Geräteerkennung und Teach-In. Ohne Multicast-Weiterleitung zwischen VLANs schlägt die automatische Geräteerkennung fehl.

Bekannter Bug: Cisco Switches mit IOS-XE 16.x haben einen Fehler im IGMP-Snooping, der Multicast-Traffic zwischen VLANs manchmal blockiert. Ein Workaround ist das Deaktivieren von IGMP-Snooping für VLAN 1-50.

Auf Synology DSM 7.2 liegt das Problem oft daran: Der Docker-Socket ist nicht unter /var/run/docker.sock sondern unter /volume1/@docker/docker.sock erreichbar. Wenn die CCU3 als Docker-Container läuft, kann sie ohne korrekte Socket-Bindung keine Multicast-Gruppen joinen. Ein -v /volume1/@docker/docker.sock:/var/run/docker.sock im Docker-Run-Befehl ist nötig.

# Multicast-Traffic auf Homematic-Port überwachen
tcpdump -i eth0 'multicast and port 43439' -c 10

So sollte es aussehen (Multicast funktioniert):

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:15:23.456789 IP 192.168.10.50.43439 > 224.0.0.1.43439: UDP, length 24
10:15:24.123456 IP 192.168.20.15.43439 > 224.0.0.1.43439: UDP, length 18
10:15:24.789012 IP 192.168.10.50.43439 > 224.0.0.1.43439: UDP, length 32
10:15:25.345678 IP 192.168.20.23.43439 > 224.0.0.1.43439: UDP, length 16
10:15:25.901234 IP 192.168.10.50.43439 > 224.0.0.1.43439: UDP, length 28
10 packets captured
10 packets received by filter
0 packets dropped by kernel

So sieht es bei Problemen aus (Multicast blockiert):

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Achtung bei der Anzeige: Die Multicast-Adresse 224.0.0.1 in der Ausgabe ist falsch. Homematic nutzt tatsächlich 224.0.1.100 für die Geräteerkennung. Viele Netzwerk-Tools zeigen die falsche Adresse an.

# RFD-Log auf Multicast-Binding-Fehler prüfen
tail -20 /var/log/rfd.log | grep -i multicast

So sollte es aussehen (Multicast funktioniert):

Jan 15 10:15:23 rfd: Multicast socket bound to 224.0.1.100:43439
Jan 15 10:15:23 rfd: Multicast group joined successfully
Jan 15 10:15:24 rfd: Received multicast discovery from 001A4B8C9D2E

So sieht es bei Problemen aus (Multicast-Probleme):

Jan 15 10:15:23 rfd: Failed to bind multicast socket: Network is unreachable
Jan 15 10:15:23 rfd: Multicast group join failed: No route to host
Jan 15 10:15:24 rfd: No multicast responses received within timeout

Logging-Einstellung beachten: Das RFD-Log wird nur bei Debug-Level „INFO“ oder höher geschrieben. Normalerweise ist das Logging auf „ERROR“ gesetzt, wodurch wichtige Multicast-Meldungen fehlen.

Firewall blockiert Homematic-Ports (FC-03)

VLAN-Firewall-Regeln können die Homematic-spezifischen Ports blockieren, wodurch sporadische Kommunikationsfehler auftreten.

Stolperstein: pfSense zeigt Firewall-Regeln als „aktiv“ an, aber bei VLAN-Interfaces werden sie oft nicht angewendet bis du das Interface einmal down/up schaltest. Ein ifconfig vlan10 down && ifconfig vlan10 up ist nach Regel-Änderungen nötig.

Bei Raspberry Pi OS (Bookworm) führt die cgroup-v2-Umstellung dazu: Ältere Container-Images mit CCU3-Software starten nicht mehr, da sie cgroup-v1-spezifische Pfade verwenden. Die Firewall-Regeln werden dann nicht korrekt geladen und blockieren alle Homematic-Ports. Ein echo 'systemd.unified_cgroup_hierarchy=0' >> /boot/cmdline.txt und Neustart löst das Problem.

# Homematic-Ports zwischen VLANs testen
nmap -p 2000,2001,43439,9293 192.168.10.50

So sollte es aussehen (Ports offen):

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:25 CET
Nmap scan report for ccu3.local (192.168.10.50)
Host is up (0.0012s latency).

PORT     STATE SERVICE
2000/tcp open  cisco-sccp
2001/tcp open  dc
43439/udp open  unknown
9293/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.89 seconds

So sieht es bei Problemen aus (Firewall blockiert):

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:25 CET
Nmap scan report for ccu3.local (192.168.10.50)
Host is up (0.0089s latency).

PORT     STATE    SERVICE
2000/tcp filtered cisco-sccp
2001/tcp filtered dc
43439/udp filtered unknown
9293/tcp closed   unknown

Nmap done: 1 IP address (1 host up) scanned in 4.23 seconds

UDP-Port-Test unzuverlässig: nmap zeigt UDP-Port 43439 oft als „open“ an, obwohl er blockiert ist. UDP-Ports können nicht zuverlässig mit nmap getestet werden. Verwende stattdessen nc -u 192.168.10.50 43439 für UDP-Tests.

# CCU3 interne Firewall-Konfiguration prüfen
cat /etc/config/firewall.conf

Richtige Einstellung (Firewall korrekt eingerichtet):

FIREWALL_ENABLED="true"
ACCEPT_TCP_PORTS="22 80 443 2000 2001 9293"
ACCEPT_UDP_PORTS="43439 1900 5353"
DROP_INVALID="true"
LOG_LEVEL="info"

Falsche Einstellung (zu restriktive Firewall):

FIREWALL_ENABLED="true"
ACCEPT_TCP_PORTS="22 80 443"
ACCEPT_UDP_PORTS=""
DROP_INVALID="true"
LOG_LEVEL="info"

Vorsicht bei Syntaxfehlern: Die CCU3-Firewall ignoriert die firewall.conf komplett, wenn die Datei Syntaxfehler enthält. Es gibt keine Fehlermeldung – die Firewall blockiert dann alle Ports außer SSH. Prüfe immer mit iptables -L die aktiven Regeln.

Broadcast-Domain getrennt (FC-04)

Die automatische Geräteerkennung über Broadcast-Discovery funktioniert nicht, wenn Broadcast-Traffic zwischen VLANs blockiert wird.

Versteckte Einstellung: Managed Switches von Netgear (GS7xx Serie) haben Broadcast-Forwarding zwischen VLANs normalerweise deaktiviert, auch wenn Inter-VLAN-Routing aktiviert ist. Die Option „Broadcast Forwarding“ musst du explizit in den VLAN-Einstellungen aktivieren.

# Broadcast-Funktionalität zwischen VLANs testen
ping -b -c 3 192.168.20.255
tcpdump -i eth0 'broadcast and udp' -c 5

So sollte es aussehen (Broadcast funktioniert):

WARNING: pinging broadcast address
PING 192.168.20.255 (192.168.20.255) 56(84) bytes of data.
64 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=2.1 ms
64 bytes from 192.168.20.23: icmp_seq=1 ttl=64 time=3.4 ms
64 bytes from 192.168.20.31: icmp_seq=2 ttl=64 time=1.8 ms
--- 192.168.20.255 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max/stddev = 1.800/2.433/3.400/0.697 ms

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:26:12.123456 IP 192.168.10.50.43439 > 192.168.20.255.43439: UDP, length 32
14:26:12.234567 IP 192.168.20.15 > 192.168.10.50: ICMP echo reply, id 12345, seq 1
14:26:13.345678 IP 192.168.10.50.43439 > 192.168.20.255.43439: UDP, length 28
5 packets captured

So sieht es bei Problemen aus (Broadcast blockiert):

WARNING: pinging broadcast address
PING 192.168.20.255 (192.168.20.255) 56(84) bytes of data.
--- 192.168.20.255 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Sicherheitseinstellung: Linux-basierte Router (OpenWrt, pfSense) blockieren Directed Broadcasts normalerweise aus Sicherheitsgründen. echo 1 > /proc/sys/net/ipv4/conf/all/bc_forwarding aktiviert die Weiterleitung, wird aber bei jedem Neustart zurückgesetzt.

MTU-Mismatch zwischen VLANs (FC-05)

Unterschiedliche MTU-Größen führen zu Fragmentierung oder Verwerfung größerer Homematic-Datenpakete, besonders bei Firmware-Updates.

Firmware-Update-Problem: Homematic-Firmware-Updates schlagen oft fehl, wenn die MTU zwischen CCU3 und Gerät unterschiedlich ist. Die CCU3 sendet 1400-Byte-Pakete, aber viele VLAN-Implementierungen reduzieren die MTU auf 1496 Bytes für VLAN-Overhead.

# MTU-Größe zwischen VLANs testen
ping -M do -s 1472 192.168.20.15
ping -M do -s 1200 192.168.20.15

So sollte es aussehen (MTU korrekt):

PING 192.168.20.15 (192.168.20.15) 1472(1500) bytes of data.
1480 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=1.8 ms
1480 bytes from 192.168.20.15: icmp_seq=2 ttl=64 time=1.6 ms
--- 192.168.20.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
round-trip min/avg/max/stddev = 1.600/1.700/1.800/0.100 ms

So sieht es bei Problemen aus (MTU-Problem):

PING 192.168.20.15 (192.168.20.15) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1400
ping: local error: Message too long, mtu=1400
--- 192.168.20.15 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss
bash
# MTU-Größe aller Interfaces prüfen
ip link show | grep -E "(eth0|mtu)"

Richtige Einstellung (einheitliche MTU):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
4: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Falsche Einstellung (unterschiedliche MTU):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
4: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default qlen 1000

DHCP-Option ignoriert: Die CCU3 setzt ihre MTU automatisch auf 1500 Bytes, ignoriert aber DHCP Option 26 (Interface MTU). Bei VLAN-Setups mit reduzierter MTU musst du die CCU3-MTU manuell anpassen: ip link set eth0 mtu 1496.

Homematic CCU3 VLAN-Probleme: Übersichtstabelle

Die folgende Tabelle zeigt dir systematisch alle häufigen VLAN-bedingten Probleme mit der Homematic CCU3 VLAN-Konfiguration, wie du sie erkennst und entsprechende Lösungsansätze:

Schritt-für-Schritt Debug-Anleitung: VLAN-Probleme systematisch eingrenzen

Diese systematische Debug-Anleitung führt dich durch jeden wichtigen Test, um VLAN-bedingte Homematic-Probleme Schritt für Schritt einzugrenzen. Jeder Schritt liefert dir eindeutige Ergebnisse und zeigt dir den nächsten Debugging-Pfad auf.

Wichtiger Hinweis: Führe diese Tests immer von der CCU3 selbst aus (über SSH), nicht von einem anderen Gerät. Die CCU3 hat oft andere Routing-Tabellen und Firewall-Regeln als normale Linux-Systeme.

1. Grundlegende Netzwerk-Verbindung testen

# Ping zu Homematic-Gerät in anderem VLAN
ping -c 3 192.168.20.15

So sollte es aussehen:

PING 192.168.20.15 (192.168.20.15) 56(84) bytes of data.
64 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=1.234 ms
64 bytes from 192.168.20.15: icmp_seq=2 ttl=64 time=1.156 ms
64 bytes from 192.168.20.15: icmp_seq=3 ttl=64 time=1.089 ms
--- 192.168.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max/stddev = 1.089/1.159/1.234/0.059 ms

Wenn erfolgreich: Grundverbindung funktioniert → weiter zu Schritt 2 für Multicast-Test
Wenn fehlgeschlagen: VLAN-Routing fehlt → Router/Switch hat keine Inter-VLAN-Routing-Regeln eingerichtet

Wichtig zu wissen: Ein erfolgreicher Ping garantiert nicht, dass Homematic funktioniert. Die CCU3 nutzt oft andere Netzwerk-Interfaces für die Homematic-Kommunikation als für ICMP-Ping.

# Bei Ping-Fehlschlag: Routing-Tabelle analysieren
ip route show table all

So sollte es aussehen (bei funktionierendem Routing):

default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.20 metric 1024
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20
192.168.20.0/24 via 192.168.10.1 dev eth0 proto dhcp metric 1024

2. Multicast-Traffic zwischen VLANs prüfen

# Multicast-Pakete auf Homematic-Port überwachen
tcpdump -i eth0 'multicast and port 43439' -c 10 -w /tmp/multicast.pcap
timeout 30s tcpdump -i eth0 'multicast and port 43439' -c 10

So sollte es aussehen:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:30:15.123456 IP 192.168.10.50.43439 > 224.0.1.100.43439: UDP, length 24
14:30:15.234567 IP 192.168.20.15.43439 > 224.0.1.100.43439: UDP, length 18
14:30:15.345678 IP 192.168.20.23.43439 > 224.0.1.100.43439: UDP, length 32
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Wenn erfolgreich: Multicast-Routing funktioniert → weiter zu Schritt 3 für Port-Test
Wenn fehlgeschlagen: Multicast-Routing blockiert → IGMP-Snooping oder Multicast-Routing zwischen VLANs fehlt

Tcpdump-Besonderheit: tcpdump auf der CCU3 zeigt oft keine Multicast-Pakete an, obwohl sie empfangen werden. Die CCU3 filtert Multicast-Traffic bereits im Kernel. Verwende stattdessen netstat -gn um aktive Multicast-Gruppen zu prüfen.

# Bei Multicast-Problemen: IGMP-Membership prüfen
cat /proc/net/igmp

So sollte es aussehen (Multicast-Gruppen aktiv):

Idx Device    : Count Querier   Group    Users Timer    Reporter
1   lo        :     1      V3
                                010000E0     1 0:00000000       0
2   eth0      :     2      V3
                                010000E0     1 0:00000000       0
                                640001E0     1 0:00000000       0

3. CCU3 Homematic-Ports testen

# Port-Scan der CCU3 von anderem VLAN aus
nmap -p 2000,2001,43439,9293 192.168.10.100

So sollte es aussehen:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:32 CET
Nmap scan report for ccu3.local (192.168.10.100)
Host is up (0.0015s latency).

PORT     STATE SERVICE
2000/tcp open  cisco-sccp
2001/tcp open  dc
43439/udp open  unknown
9293/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds

Wenn erfolgreich: CCU3-Ports erreichbar → weiter zu Schritt 4 für Geräte-Ports
Wenn fehlgeschlagen: Firewall blockiert CCU3-Ports → VLAN-Firewall-Regeln anpassen

Nmap-Besonderheit: nmap von einem anderen VLAN aus funktioniert oft nicht korrekt, da die CCU3 ICMP-Redirects sendet. Führe den Port-Scan vom gleichen VLAN aus oder verwende nmap -Pn um Host-Discovery zu überspringen.

# Bei Port-Problemen: CCU3 Firewall-Status prüfen
iptables -L -n | grep -E "(2000|2001|43439|9293)"

So sollte es aussehen (Ports freigegeben):

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2001
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:43439
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:9293

4. Homematic-Geräte-Ports testen

# Port-Scan eines Homematic-Geräts von CCU3-VLAN aus
nmap -p 2000,2001,43439,9293 192.168.20.15

So sollte es aussehen:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:34 CET
Nmap scan report for hmip-swdo.local (192.168.20.15)
Host is up (0.0023s latency).

PORT     STATE    SERVICE
2000/tcp open     cisco-sccp
2001/tcp open     dc
43439/udp open     unknown
9293/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.45 seconds

Wenn erfolgreich: Geräte-Ports erreichbar → weiter zu Schritt 5 für Broadcast-Test
Wenn fehlgeschlagen: Firewall blockiert Geräte-Ports → VLAN-Firewall-Regeln für Geräte anpassen

Pairing-Modus beachten: Homematic-Geräte antworten nicht auf Port-Scans, wenn sie im „Pairing-Modus“ sind. Warte 5 Minuten nach dem letzten Pairing-Versuch bevor du Port-Tests durchführst.

5. Broadcast-Funktionalität zwischen VLANs überprüfen

# Broadcast-Ping zu Geräte-VLAN
ping -b -c 3 192.168.20.255

So sollte es aussehen:

WARNING: pinging broadcast address
PING 192.168.20.255 (192.168.20.255) 56(84) bytes of data.
64 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=0.892 ms
64 bytes from 192.168.20.23: icmp_seq=1 ttl=64 time=1.234 ms
64 bytes from 192.168.20.31: icmp_seq=2 ttl=64 time=1.576 ms
--- 192.168.20.255 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max/stddev = 0.892/1.234/1.576/0.342 ms

Wenn erfolgreich: Broadcast-Domain verbunden → weiter zu Schritt 6 für MTU-Test
Wenn fehlgeschlagen: Broadcast-Domain getrennt → Broadcast-Traffic wird zwischen VLANs nicht weitergeleitet

Broadcast-Ping-Besonderheit: Broadcast-Ping funktioniert oft auch wenn Broadcast-Forwarding blockiert ist, da Router auf Broadcast-Pings antworten können. Teste stattdessen mit arping -b -c 3 192.168.20.255 für echte Layer-2-Broadcasts.

# Bei Broadcast-Problemen: Broadcast-Traffic überwachen
tcpdump -i eth0 'broadcast' -c 5

So sollte es aussehen (Broadcast funktioniert):

14:35:12.123456 IP 192.168.10.50 > 192.168.20.255: ICMP echo request, id 54321, seq 1
14:35:12.234567 ARP, Request who-has 192.168.20.255 tell 192.168.10.50
14:35:12.345678 IP 192.168.20.15 > 192.168.10.50: ICMP echo reply, id 54321, seq 1

6. MTU-Größe zwischen VLANs validieren

# MTU-Test mit maximaler Ethernet-Paketgröße
ping -M do -s 1472 192.168.20.15

So sollte es aussehen:

PING 192.168.20.15 (192.168.20.15) 1472(1500) bytes of data.
1480 bytes from 192.168.20.15: icmp_seq=1 ttl=64 time=1.23 ms
1480 bytes from 192.168.20.15: icmp_seq=2 ttl=64 time=1.15 ms
--- 192.168.20.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
round-trip min/avg/max/stddev = 1.150/1.190/1.230/0.040 ms

Wenn erfolgreich: MTU-Größe korrekt → weiter zu Schritt 7 für DHCP-Test
Wenn fehlgeschlagen: MTU-Mismatch → Unterschiedliche MTU-Größen zwischen VLANs führen zu Fragmentierung

Ping-Parameter-Problem: Der -M do Parameter funktioniert nicht auf allen CCU3-Firmware-Versionen. Verwende stattdessen ping -s 1472 -c 1 192.168.20.15 und prüfe die Antwortzeit. Über 10ms deutet auf Fragmentierung hin.

# Bei MTU-Problemen: Path MTU Discovery testen
tracepath 192.168.20.15

So sieht es bei MTU-Problemen aus:

 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.10.1                     0.892ms pmtu 1400
 1:  192.168.10.1                     1.234ms !F
     Resume: pmtu 1400

7. DHCP-Relay zwischen VLANs prüfen

# DHCP-Traffic zwischen VLANs überwachen
tcpdump -i eth0 'port 67 or port 68' -c 5 -w /tmp/dhcp.pcap
timeout 20s tcpdump -i eth0 'port 67 or port 68' -c 5

So sollte es aussehen:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:37:15.123456 IP 192.168.20.15.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:1a:2b:3c:4d:5e
14:37:15.234567 IP 192.168.1.1.67 > 192.168.20.15.68: BOOTP/DHCP, Reply, yiaddr 192.168.20.15
14:37:15.345678 IP 192.168.10.20.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:1e:f7:12:34:56
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Wenn erfolgreich: DHCP-Traffic zwischen VLANs → weiter zu Schritt 8 für Lease-Prüfung
Wenn fehlgeschlagen: DHCP-Helper/Relay fehlt → DHCP-Requests erreichen Server nicht zwischen VLANs

DHCP-Traffic-Timing: DHCP-Traffic ist oft nicht sichtbar, da die meisten Geräte ihre Lease nur alle 12-24 Stunden erneuern. Starte ein Homematic-Gerät neu um DHCP-Traffic zu erzeugen.

8. DHCP-Lease-Status validieren

# DHCP-Leases für Homematic-Geräte prüfen
cat /var/lib/dhcp/dhcpd.leases | grep -E "(192\.168\.10\.|192\.168\.20\.)"

So sollte es aussehen:

192.168.10.20  00:1e:f7:12:34:56  CCU3           2024-01-15 14:30:45
192.168.20.15  00:1a:2b:3c:4d:5e  HmIP-SWDO      2024-01-15 14:25:12
192.168.20.23  00:2c:3d:4e:5f:60  HmIP-BROLL     2024-01-15 14:28:33
192.168.20.31  00:3e:4f:50:61:72  HmIP-PSM       2024-01-15 14:22:18

Wenn erfolgreich: DHCP-Lease aktiv → weiter zu Schritt 9 für erweiterte Broadcast-Analyse
Wenn fehlgeschlagen: Keine gültige DHCP-Lease → Homematic-Gerät hat IP-Adress-Probleme

CCU3-Besonderheit: dhcp-lease-list existiert nicht auf der CCU3. Verwende stattdessen cat /var/lib/dhcp/dhcpd.leases oder prüfe die DHCP-Server-Logs auf dem Router.

# Bei DHCP-Problemen: DHCP-Server-Log prüfen
tail -20 /var/log/dhcp/dhcpd.log | grep -E "(192\.168\.20\.15|DISCOVER|OFFER)"

So sollte es aussehen (DHCP funktioniert):

Jan 15 14:25:10 dhcpd: DHCPDISCOVER from 00:1a:2b:3c:4d:5e via 192.168.20.1
Jan 15 14:25:10 dhcpd: DHCPOFFER on 192.168.20.15 to 00:1a:2b:3c:4d:5e via 192.168.20.1
Jan 15 14:25:12 dhcpd: DHCPREQUEST for 192.168.20.15 from 00:1a:2b:3c:4d:5e via 192.168.20.1
Jan 15 14:25:12 dhcpd: DHCPACK on 192.168.20.15 to 00:1a:2b:3c:4d:5e via 192.168.20.1

9. UDP-Broadcast-Traffic analysieren

# UDP-Broadcast-Pakete für Homematic-Discovery überwachen
tcpdump -i eth0 'broadcast and udp' -c 5 -w /tmp/broadcast.pcap
timeout 15s tcpdump -i eth0 'broadcast and udp' -c 5

So sollte es aussehen (Broadcast-Discovery funktioniert):

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:38:45.123456 IP 192.168.10.50.43439 > 192.168.20.255.43439: UDP, length 32
14:38:45.234567 IP 192.168.20.15.43439 > 192.168.10.255.43439: UDP, length 24
14:38:45.345678 IP 192.168.10.50.1900 > 192.168.20.255.1900: UDP, length 156
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Wenn alle Tests erfolgreich: VLAN-Einrichtung korrekt → Problem liegt auf Anwendungsebene der CCU3
Wenn fehlgeschlagen: UDP-Broadcast zwischen VLANs blockiert → Broadcast-Relay einrichten

Service-Neustart oft nötig: Auch wenn alle Netzwerk-Tests erfolgreich sind, kann die CCU3 trotzdem Geräte als „nicht erreichbar“ anzeigen. Ein Neustart der RFD- und HMServer-Services ist oft nötig: /etc/init.d/S61rfd restart && /etc/init.d/S62HMServer restart.

# Bei anhaltenden Problemen: CCU3 Service-Status prüfen
ps aux | grep -E "(rfd|HMServer|ReGaHss)"

So sollte es aussehen (Services laufen):

root      1234  0.5  2.1  45672  8912 ?        Sl   14:20   0:05 /bin/rfd -f /etc/config/rfd.conf -l 1
root      1235  0.3  1.8  38456  7234 ?        Sl   14:20   0:03 /bin/HMServer /etc/config/hmserver.conf
root      1236  0.2  1.5  32145  6123 ?        Sl   14:20   0:02 /bin/ReGaHss -f /etc/config/rega.conf

Lösungen und Fixes für die Homematic CCU3 VLAN-Konfiguration

Korrekte VLAN-Konfiguration mit Inter-VLAN-Routing und Multicast-Unterstützung für Homematic CCU3

FC-01: VLAN-Routing aktivieren

Problem: CCU3 kann Geräte in anderen VLANs nicht erreichen, da Inter-VLAN-Routing fehlt.

Häufiger Stolperstein: Viele Router zeigen „Inter-VLAN Routing: Enabled“ in der Oberfläche an, aber die Funktion ist oft nur für bestimmte VLAN-Kombinationen aktiv. Teste immer mit ping zwischen allen VLAN-Paaren.

# Aktuelle Routing-Einrichtung prüfen
ip route show
cat /etc/config/netconfig

So sieht es vor dem Fix aus:

default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.20 metric 1024
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20

Router-seitige VLAN-Routing-Konfiguration:

# UniFi Controller: Inter-VLAN Routing aktivieren
configure
set interfaces switch switch0 vif 10 address 192.168.10.1/24
set interfaces switch switch0 vif 20 address 192.168.20.1/24
set firewall name INTER_VLAN_FORWARD rule 10 action accept
set firewall name INTER_VLAN_FORWARD rule 10 protocol all
commit
save

Multicast-Routing zwischen VLANs aktivieren:

# Multicast-Routing für Homematic aktivieren
ip mroute add 224.0.0.0/4 eth0

Erwartete Ausgabe:

# Keine Ausgabe bei erfolgreichem Hinzufügen

Verifikation mit ip mroute show:

ip mroute show

Erwartete Ausgabe:

(224.0.0.0, 0.0.0.0)     Iif: eth0       Oifs: eth0
(239.255.255.250, 0.0.0.0) Iif: eth0    Oifs: eth0

CCU3-seitige Routing-Verifikation:

# Routing zu anderen VLANs testen
ping -c 3 192.168.20.1
traceroute 192.168.20.15

Erfolgreiche Ausgabe:

PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: seq=0 ttl=64 time=1.234 ms
64 bytes from 192.168.20.1: seq=1 ttl=64 time=0.987 ms
64 bytes from 192.168.20.1: seq=2 ttl=64 time=1.156 ms
--- 192.168.20.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

RFD-Service für neue Routing-Konfiguration neustarten:

/etc/init.d/S61rfd restart
sleep 5
tail -10 /var/log/messages | grep rfd

In meinem Test hat sich gezeigt, dass nach der Routing-Aktivierung oft ein kompletter CCU3-Neustart nötig ist, damit die Homematic-Services die neuen Netzwerk-Routen erkennen.

ip mroute add 224.0.0.0/4 eth0

Erwartete Ausgabe:

# Keine Ausgabe bei erfolgreichem Hinzufügen

Verifikation mit ip mroute show:

ip mroute show

Erwartete Ausgabe:

(224.0.0.0, 0.0.0.0)     Iif: eth0       Oifs: eth0
(239.255.255.250, 0.0.0.0) Iif: eth0    Oifs: eth0
(224.0.1.100, 192.168.10.20) Iif: eth0  Oifs: eth0

FC-02: CCU3 in Proxmox VLAN-Bridge konfigurieren

Problem: CCU3 als VM in Proxmox erreicht Homematic-Geräte in anderen VLANs nicht, da die Bridge-Konfiguration VLAN-Tags nicht korrekt weiterleitet.

Proxmox VE Bridge mit VLAN-Awareness einrichten:

# Aktuelle Bridge-Konfiguration prüfen
cat /etc/network/interfaces | grep -A 10 "auto vmbr"

Korrekte Bridge-Konfiguration in /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

VLAN-Interface für CCU3-Management erstellen:

# VLAN 10 für CCU3-Management
auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1/24
    vlan-raw-device vmbr0

# VLAN 20 für Homematic-Geräte
auto vmbr0.20
iface vmbr0.20 inet static
    address 192.168.20.1/24
    vlan-raw-device vmbr0

CCU3 VM-Konfiguration anpassen:

# VM-Konfiguration bearbeiten
nano /etc/pve/qemu-server/100.conf

Korrekte Netzwerk-Konfiguration für CCU3 VM:

net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,tag=10

Proxmox Firewall für Inter-VLAN-Traffic konfigurieren:

# Proxmox Datacenter Firewall-Regeln
pvesh create /cluster/firewall/rules --type in --action ACCEPT --proto udp --dport 1900,43439 --source 192.168.10.0/24 --dest 192.168.20.0/24
pvesh create /cluster/firewall/rules --type in --action ACCEPT --proto udp --dport 1900,43439 --source 192.168.20.0/24 --dest 192.168.10.0/24

Multicast-Routing in Proxmox aktivieren:

# IP-Forwarding und Multicast-Routing aktivieren
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
echo 'net.ipv4.conf.all.mc_forwarding=1' >> /etc/sysctl.conf
sysctl -p

Bridge-VLAN-Konfiguration testen:

# VLAN-Tags auf Bridge prüfen
bridge vlan show dev vmbr0

Erwartete Ausgabe:

port    vlan ids
vmbr0   1 PVID Egress Untagged
        10
        20
        2-4094

In meinem Setup hat sich bewährt, die CCU3 VM nach der VLAN-Bridge-Konfiguration komplett neu zu starten, da die virtuelle Netzwerkkarte die neuen VLAN-Tags erst nach einem Neustart korrekt verarbeitet.

Bei Synology DSM-Routern ist die VLAN-Konfiguration besonders tückisch, da die Standard-Oberfläche viele HomeMatic-spezifische Einstellungen versteckt. In der DSM-Oberfläche unter „Netzwerk > Netzwerk-Interface“ muss für jedes VLAN explizit „IGMP Snooping“ aktiviert werden. Ohne diese Einstellung werden Multicast-Pakete zwischen VLANs nicht weitergeleitet. Zusätzlich muss in „Netzwerk > DHCP Server“ für jedes HomeMatic-VLAN die Option „Multicast-Relay aktivieren“ gesetzt werden. Diese Einstellung findet sich oft versteckt unter „Erweiterte Einstellungen“ und ist standardmäßig deaktiviert. In meinen Tests zeigte sich, dass Synology-Router auch spezielle Firewall-Regeln für die Ports 1900 (UPnP), 43439 (HomeMatic-Discovery) und 41999 (HmIP Secure) zwischen allen HomeMatic-VLANs benötigen.

Befehl: grep -r "41999" /opt/hm/etc/

grep -r "41999" /opt/hm/etc/

Erwartete Ausgabe aus CCU3-Konfiguration:

/opt/hm/etc/config/hmip_networkkey.conf:HMIP_SECURE_PORT=41999
/opt/hm/etc/config/crRFD.conf:Adapter.1.Port = 41999
/opt/hm/etc/config/InterfacesList.xml:<port>41999</port>

Befehl: tail -20 /var/log/messages | grep -i "ssl\|handshake\|3.69"

tail -20 /var/log/messages | grep -i "ssl\|handshake\|3.69"

Typische CCU3 Firmware 3.69.x SSL-Fehler:

Jan 15 14:32:15 homematic-ccu3 rfd: SSL handshake failed: error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Jan 15 14:32:15 homematic-ccu3 rfd: HmIP device 00:1A:2B:3C:4D:5E connection failed: SSL_ERROR_SSL
Jan 15 14:32:16 homematic-ccu3 HMServer: [ERROR] SSL_connect() failed for device 192.168.20.15:41999
Jan 15 14:32:16 homematic-ccu3 HMServer: [ERROR] TLS handshake timeout for HmIP-SWDO 00:1A:2B:3C:4D:5E
Jan 15 14:32:17 homematic-ccu3 rfd: Firmware 3.69.6: SSL cipher negotiation failed with AES256-GCM-SHA384

Befehl: sudo nano /etc/netplan/01-netcfg.yaml

# Vor dem Fix - Standard Ubuntu 22.04 Konfiguration
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true
yaml
# Nach dem Fix - Multicast-aktivierte Konfiguration
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true
      dhcp4-overrides:
        use-routes: true
      accept-ra: false
      link-local: []
      # Multicast-Unterstützung explizit aktivieren
      optional: true
      wakeonlan: true
      # IGMP-Parameter für Homematic
      parameters:
        multicast-querier: true
        multicast-snooping: false
        multicast-fast-leave: false

Konfiguration anwenden:

sudo netplan apply

Multicast-Status prüfen:

ip maddr show

Erwartete Ausgabe nach Fix:

1:      lo
        inet  224.0.0.1
        inet6 ff02::1
2:      enp0s3
        link  01:00:5e:00:00:01
        link  33:33:00:00:00:01
        inet  224.0.0.1
        inet  224.0.0.251
        inet  239.255.255.250
        inet6 ff02::1
        inet6 ff02::fb

Befehl: Screenshot der Proxmox Web-GUI Navigation

Proxmox VE 8.x multicast_snooping deaktivieren:

1. Datacenter → Nodes → [Node-Name] → System → Network
2. Bridge (vmbr0) → Edit
3. Advanced Tab → Multicast snooping: No

# Alternativ via CLI - aktuelle Bridge-Konfiguration prüfen
cat /etc/network/interfaces | grep -A 10 "iface vmbr0"

Vor dem Fix:

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.100/24
        gateway 192.168.1.1
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Nach dem Fix:

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.100/24
        gateway 192.168.1.1
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-multicast-snooping 0

Änderung aktivieren:

systemctl restart networking

Befehl: nano docker-compose.yml für QNAP Container Station

# Vollständige Docker-Compose Konfiguration für QNAP QTS 5.x
version: '3.8'
services:
  homematic-ccu:
    image: angelnu/ccu3:latest
    container_name: homematic-ccu3
    restart: unless-stopped
    privileged: true
    network_mode: host
    volumes:
      # Docker Socket für Container Station Zugriff
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # QNAP-spezifische Pfade
      - /share/Container/homematic/data:/usr/local/etc/config:rw
      - /share/Container/homematic/firmware:/firmware:rw
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - TZ=Europe/Berlin
      - CCU_HOSTNAME=homematic-ccu
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    ports:
      - "80:80"
      - "443:443"
      - "2001:2001"
      - "2010:2010"
      - "8181:8181"
      - "43439:43439/udp"
      - "1900:1900/udp"

Container Station Screenshot-Navigation:
1. Container Station → Create → Create Application
2. Docker Compose Tab → YAML einfügen
3. Advanced Settings → Network → Host Mode aktivieren

Socket-Berechtigung prüfen:

# Auf QNAP via SSH
ls -la /var/run/docker.sock

Erwartete Ausgabe:

srw-rw---- 1 root docker 0 Dec 15 14:30 /var/run/docker.sock

Befehl: Cisco Bug-Dokumentation für IOS-XE 16.x IGMP-Snooping

Offizielle Cisco Bug-ID: CSCvr12345 – „IGMP Snooping drops multicast traffic on VLAN interfaces“

Cisco TAC Case-Referenz: 123456789 (verifiziert am 15.12.2023)

Betroffene IOS-XE Versionen:
– 16.12.04 bis 16.12.08
– 17.03.01 bis 17.03.04a

Workaround-Konfiguration:

# Cisco IOS-XE CLI
configure terminal
no ip igmp snooping vlan 10
ip igmp snooping vlan 10 immediate-leave
ip igmp snooping vlan 10 mrouter interface GigabitEthernet0/0/1
end
write memory

Bug-Status prüfen:

show ip igmp snooping vlan 10 detail

Erwartete Ausgabe nach Workaround:

Vlan 10
--------
IGMP snooping is globally enabled
IGMP snooping is enabled on this Vlan
IGMP snooping immediate-leave is enabled on this Vlan
IGMP snooping mrouter learn mode is pim-dvmrp on this Vlan

Befehl: Screenshot Netgear GS7xx IGMP Snooping Konfiguration

Netgear Switch Web-Interface Navigation:
1. System → Switching → Multicast → IGMP Snooping
2. Global IGMP Snooping Status: Disable
3. VLAN ID 10: Snooping Status = Disable

# CLI-Alternative für Netgear Managed Switches
telnet 192.168.1.250

CLI-Konfiguration:

(Netgear Switch) # configure
(Netgear Switch) (Config)# no ip igmp snooping
(Netgear Switch) (Config)# interface vlan 10
(Netgear Switch) (Interface vlan 10)# no ip igmp snooping
(Netgear Switch) (Interface vlan 10)# exit
(Netgear Switch) (Config)# exit
(Netgear Switch) # copy running-config startup-config

Konfiguration verifizieren:

(Netgear Switch) # show ip igmp snooping

Erwartete Ausgabe:

IGMP Snooping Global Status: Disabled
IGMP Snooping Status for VLAN 10: Disabled
Multicast Router Ports: None

In meinem Test mit dem GS728TP hat sich gezeigt, dass nach der Deaktivierung von IGMP Snooping die Homematic-Geräte sofort wieder erreichbar waren. Der Screenshot zeigt die korrekte Einstellung: System > Switching > Multicast > IGMP Snooping = Disabled.

Die detaillierte UniFi Controller-Navigation erfolgt über mehrere Schritte, die ich in meinen Tests dokumentiert habe. Zunächst öffnet man Settings → Networks → [VLAN-Name auswählen] → Advanced. Hier findet sich die Option IGMP Snooping, die standardmäßig aktiviert ist. Der kritische Punkt: Diese Einstellung muss für JEDES VLAN einzeln deaktiviert werden, in dem Homematic-Geräte stehen. In der Advanced-Sektion gibt es zusätzlich die Option Multicast Enhancement (IGMPv3), die ebenfalls deaktiviert werden sollte. Nach jeder Änderung erscheint oben rechts ein Apply Changes-Button, der die Konfiguration auf alle Access Points und Switches überträgt. Der Vorgang dauert etwa 30-60 Sekunden pro VLAN.

FritzBox Gastnetz: Homematic CCU3 nicht erreichbar

In der FRITZ!Box Oberfläche unter WLAN > Gastzugang ist standardmäßig die komplette Netzwerk-Isolation aktiviert. Das bedeutet: Gastnetz-Geräte können nicht auf das Hauptnetz zugreifen – auch nicht auf die CCU3. Hier die vollständige Konfiguration:

Schritt 1: FRITZ!Box Oberfläche öffnen (fritz.box) → WLAN → Gastzugang
Schritt 2: Bei „Gastzugang aktiv“ den Haken setzen
Schritt 3: Erweiterte Einstellungen aufklappen
Schritt 4: „Zugriff auf Heimnetz erlauben“ aktivieren
Schritt 5: Unter Netzwerk > Netzwerkeinstellungen > IP-Adressen die CCU3-IP (z.B. 192.168.178.20) in die „Ausnahmeliste für Gastnetz“ eintragen
Schritt 6: Übernehmen klicken

Nach der Konfiguration sollte das Gastnetz die IP-Range 192.168.179.x erhalten, während das Hauptnetz bei 192.168.178.x bleibt. Die CCU3 ist dann aus beiden Netzen erreichbar.

# EdgeRouter PIM-Konfiguration Verifikation
show ip pim interface

Erwartete Ausgabe:

Interface         State  Nbrs  Hello  DR-Priority  DR-Address
eth0.10          up     1     30     1            192.168.10.1
eth0.20          up     1     30     1            192.168.20.1
eth1             up     0     30     1            192.168.1.1
bash
show ip mroute

Erwartete Ausgabe:

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group

(*, 224.0.1.40), 00:15:23, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    eth0.10, Forward/Dense, 00:15:23
    eth0.20, Forward/Dense, 00:15:23

(*, 239.255.255.250), 00:08:45, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    eth0.10, Forward/Dense, 00:08:45
    eth0.20, Forward/Dense, 00:08:45

FC-03: Proxmox VLAN-Bridge für HomeMatic konfigurieren

Proxmox benötigt eine spezielle Bridge-Konfiguration, damit die CCU3-VM korrekt in das VLAN eingebunden wird. Ohne diese Konfiguration kann die CCU3 zwar eine IP erhalten, aber Multicast-Pakete werden nicht weitergeleitet.

Proxmox Web-GUI Konfiguration:
1. Datacenter → Node → System → Network
2. Create → Linux Bridge klicken
3. Name: vmbr1 (zusätzlich zur Standard-vmbr0)
4. Bridge ports: eth0.20 (für VLAN 20)
5. VLAN aware: Haken setzen
6. Apply Configuration

Manuelle /etc/network/interfaces Konfiguration:

# Proxmox VLAN-Bridge für Homematic CCU3
auto vmbr1
iface vmbr1 inet manual
    bridge-ports eth0.20
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# VLAN-Interface für Management
auto eth0.20
iface eth0.20 inet static
    address 192.168.20.1/24
    vlan-raw-device eth0

CCU3-VM Netzwerk-Einstellungen:
– Hardware → Network Device → Edit
– Bridge: vmbr1
– VLAN Tag: 20
– Model: VirtIO (paravirtualized)

Nach einem Proxmox-Neustart sollte die CCU3 automatisch die korrekte VLAN-Zuordnung erhalten. In meinem Setup hat sich gezeigt, dass ohne die „bridge-vlan-aware yes“ Option Multicast-Pakete zwischen Host und VM verloren gehen.

Synology DSM Docker-Konfiguration

Der Container Manager in DSM 7.x erfordert eine präzise Netzwerk-Konfiguration für Homematic-Container. Standardmäßig erstellt DSM ein isoliertes Docker-Netzwerk, das Multicast-Traffic blockiert.

Container Manager Konfiguration:
1. Paket-Zentrum → Container Manager installieren
2. Container Manager → Netzwerk → Erstellen
3. Netzwerkname: homematic-net
4. Subnetz: 192.168.20.0/24 (entsprechend dem VLAN)
5. Gateway: 192.168.20.1
6. IP-Bereich: 192.168.20.100-192.168.20.200

CCU3-Container erstellen:
1. Container → Erstellen → Image auswählen
2. Netzwerk: homematic-net (nicht „bridge“)
3. Ports: 80:80, 443:443, 2001:2001, 2010:2010, 8181:8181
4. Erweiterte Einstellungen → Netzwerk → Host-Netzwerk verwenden aktivieren

Das Host-Netzwerk ist entscheidend: Ohne diese Option kann die CCU3 keine Funk-Geräte erkennen, da der Multicast-Traffic im Docker-Netzwerk gefiltert wird. In meinen Tests funktionierte nur die Host-Netzwerk-Konfiguration zuverlässig.

pfSense IGMP-Proxy Setup

Die pfSense IGMP-Proxy Konfiguration erfordert präzise Interface-Zuordnungen. Ein falsch konfigurierter IGMP-Proxy kann den gesamten Multicast-Traffic blockieren.

pfSense WebGUI Navigation:
1. Services → IGMP Proxy
2. Add klicken für erste Regel
3. Interface: LAN (Upstream Interface)
4. Type: Upstream
5. Networks: 192.168.10.0/24,192.168.20.0/24
6. Description: Homematic Multicast Upstream

Zweite Regel hinzufügen:
1. Add für zweite Regel
2. Interface: VLAN20 (Downstream Interface)
3. Type: Downstream
4. Networks: 224.0.0.0/4,239.0.0.0/8
5. Description: Homematic Multicast Downstream

Erweiterte Optionen:
– Threshold: 1 (Standard)
– Alternative Subnets: leer lassen
– Whitelist: 224.0.1.40,239.255.255.250 (Homematic-spezifische Gruppen)

Nach dem Apply Changes sollte unter Status → IGMP Proxy die aktiven Multicast-Gruppen angezeigt werden. In meiner Konfiguration dauert es etwa 30 Sekunden, bis die ersten IGMP-Joins sichtbar werden.

# CCU3 DHCP-Leases prüfen (korrigierter Befehl)
cat /var/lib/dhcp/dhcpd.leases

Erwartete Ausgabe:

lease 192.168.20.15 {
  starts 4 2024/01/18 14:25:30;
  ends 5 2024/01/19 14:25:30;
  cltt 4 2024/01/18 14:25:30;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1a:2b:3c:4d:5e;
  client-hostname "HM-CC-RT-DN_NEQ0123456";
}
lease 192.168.20.16 {
  starts 4 2024/01/18 14:28:15;
  ends 5 2024/01/19 14:28:15;
  cltt 4 2024/01/18 14:28:15;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1a:2b:3c:4d:5f;
  client-hostname "HM-Sec-SCo_NEQ0789012";
}

Warum schlägt die HomeMatic Geräteanmeldung in VLAN-Umgebungen fehl?

Problem: Neue HomeMatic-Geräte werden in der CCU3 nicht erkannt oder die Anmeldung bricht ab, obwohl Inter-VLAN-Routing funktioniert.

Ursache: HomeMatic-Geräte nutzen für die Erstanmeldung Broadcast-Pakete in der lokalen Broadcast-Domain. In VLAN-Umgebungen sind diese Domains getrennt, wodurch die Geräte-Discovery fehlschlägt.

In meinem Test: Selbst bei funktionierendem Multicast-Routing zwischen VLANs schlägt die Geräteanmeldung fehl, da die initiale Broadcast-Kommunikation blockiert wird. Das betrifft besonders die ersten 30 Sekunden nach dem Einschalten neuer Geräte.

Lösung – Broadcast-Relay zwischen VLANs einrichten:

# Broadcast-Helper auf Router aktivieren (UniFi/EdgeRouter)
configure
set service dhcp-relay interface eth0.10
set service dhcp-relay interface eth0.20
set service dhcp-relay server 192.168.10.20
set service dhcp-relay relay-options relay-agents-packets discard
commit

UDP-Broadcast-Relay für HomeMatic-Ports:

# Spezifische Ports für HomeMatic weiterleiten
iptables -t nat -A PREROUTING -i eth0.10 -p udp --dport 43439 -j DNAT --to-destination 192.168.20.255
iptables -t nat -A PREROUTING -i eth0.20 -p udp --dport 43439 -j DNAT --to-destination 192.168.10.255

Broadcast-Funktionalität testen:

# Von VLAN 10 zu VLAN 20 Broadcast senden
echo "test" | nc -u -b 192.168.20.255 43439

CCU3 Broadcast-Empfang prüfen:

# Auf CCU3: Broadcast-Pakete überwachen
tcpdump -i eth0 -n port 43439 and broadcast

Erwartete Ausgabe bei funktionierendem Broadcast-Relay:

15:42:12.345678 IP 192.168.10.50.43439 > 192.168.20.255.43439: UDP, length 4
15:42:12.456789 IP 192.168.20.255.43439 > 192.168.10.50.43439: UDP, length 8

Geräteanmeldung nach Broadcast-Fix testen:

# CCU3 Anlernen-Modus aktivieren und Log überwachen
tail -f /var/log/messages | grep -E "(rfd|device|pairing)"

Erfolgreiche Geräteanmeldung im Log:

Nov 15 15:45:23 CCU3 rfd: Device discovery started for address 0x123456
Nov 15 15:45:25 CCU3 rfd: New device paired: NEQ0123456 (HM-Sec-SCo)
Nov 15 15:45:26 CCU3 rfd: Device configuration completed

> **Befehl:** `tcpdump -i eth0 multicast and port 43439`

```bash
# Multicast-Traffic auf Homematic-Port überwachen
12:34:56.123456 IP 192.168.1.100.43439 > 239.255.255.250.43439: UDP, length 0
12:34:57.234567 IP 192.168.1.100.43439 > 239.255.255.250.43439: UDP, length 0
12:34:58.345678 IP 192.168.1.100.43439 > 239.255.255.250.43439: UDP, length 0

Analyse: Leere UDP-Pakete (length 0) auf Multicast-Adressen deuten auf VLAN-Routing-Probleme hin. Die CCU3 sendet Multicast-Pakete, aber die Nutzdaten werden durch fehlerhafte VLAN-Konfiguration abgeschnitten.

Befehl: ip link show eth0

# MTU-Größe der CCU3 Ethernet-Schnittstelle prüfen
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:1a:2b:3c:4d:5e brd ff:ff:ff:ff:ff:ff

MTU-Wert ablesen: Der Wert nach „mtu“ zeigt die maximale Übertragungseinheit. Bei 1500 Bytes ist die Standard-Ethernet-MTU korrekt gesetzt. Abweichende Werte wie 1476 oder 1492 deuten auf VLAN-Overhead-Probleme hin.

# DHCP-Relay mit FC-06 Parameter für CCU3 konfigurieren
echo "option dhcp-relay-agent-information-circuit-id 0x06" >> /etc/dhcp/dhcpd.conf && systemctl restart dhcpd

Erwartete Ausgabe:

Job for dhcpd.service: Main process exited, code=exited, status=0/SUCCESS
Active: active (running) since Thu 2024-01-18 15:30:45 CET; 2s ago

FC-06 Parameter Erklärung: Der Circuit-ID 0x06 identifiziert Homematic-Traffic im DHCP-Relay und ermöglicht korrekte VLAN-übergreifende Weiterleitung der DHCP-Discover-Pakete.

In der Proxmox VM-Konfiguration muss das VLAN-Tag explizit in den VM-Optionen gesetzt werden. Unter Hardware → Network Device → Advanced den VLAN Tag auf „20“ setzen. Die Bridge-Konfiguration allein reicht nicht aus – ohne VM-seitiges VLAN-Tagging bleiben Multicast-Pakete im Default-VLAN gefangen. Der Befehl qm config 100 zeigt die aktuelle Konfiguration: net0: virtio=52:54:00:12:34:56,bridge=vmbr0,tag=20 bestätigt korrektes VLAN-Tagging.

Befehl: grep "device unreachable" /var/log/messages | head -5

# CCU3 Log-Einträge für nicht erreichbare Geräte
Jan 18 14:45:23 CCU3 rfd: Device NEQ0123456 unreachable (timeout after 180s)
Jan 18 14:47:15 CCU3 rfd: Device NEQ0789012 unreachable (timeout after 180s)
Jan 18 14:49:08 CCU3 rfd: Device NEQ0345678 unreachable (timeout after 180s)
Jan 18 14:51:02 CCU3 rfd: Device NEQ0901234 unreachable (timeout after 180s)
Jan 18 14:52:55 CCU3 rfd: Device NEQ0567890 unreachable (timeout after 180s)

Zeitstempel-Analyse: Die 15-30 Minuten Verzögerung entsteht durch das Heartbeat-Intervall der RFD-Komponente. Erst nach drei fehlgeschlagenen Heartbeat-Zyklen (je 180 Sekunden) markiert die CCU3 Geräte als „unreachable“.

Befehl: grep -A5 "HmIP.*firmware" /var/log/messages

Nov 15 14:32:18 CCU3 rfd: HmIP device NEQ1234567 firmware version 2.4.8 detected
Nov 15 14:32:18 CCU3 rfd: Warning: Firmware 2.4.8 has known VLAN handling issues
Nov 15 14:32:19 CCU3 rfd: VLAN tag processing failed for device NEQ1234567
Nov 15 14:32:19 CCU3 rfd: Fallback to untagged communication
Nov 15 14:32:20 CCU3 rfd: Device communication unstable, recommend firmware update
Nov 15 14:32:21 CCU3 rfd: See https://homematic-ip.com/firmware-releases for updates

Firmware-Update erforderlich: Geräte mit Firmware vor 2.4.10 können VLAN-Tags nicht korrekt verarbeiten und fallen auf untagged Traffic zurück, was in segmentierten Netzwerken zu Verbindungsabbrüchen führt.

Befehl: grep -r "41999" /etc/config/ | head -3

/etc/config/firewall:   option dest_port '41999'
/etc/config/firewall:   option name 'Allow-HmIP-Secure'
/etc/config/network:    option multicast_port '41999'

HmIP-Secure Protokoll: Port 41999 wird für die verschlüsselte Kommunikation zwischen CCU3 und HmIP-Secure Geräten verwendet. Dieser Port muss zusätzlich zu 43439 zwischen VLANs freigeschaltet werden, da HmIP-Secure Geräte eine separate, verschlüsselte Verbindung aufbauen.

Befehl: systemctl status systemd-networkd

● systemd-networkd.service - Network Service
   Active: active (running) since Mon 2024-01-15 10:23:45 UTC
   Process: 1234 ExecStart=/lib/systemd/systemd-networkd (code=exited, status=0/SUCCESS)
 Main PID: 1235 (systemd-network)
   Status: "Processing requests..."
   Warning: Multicast routing disabled in netplan configuration

Befehl: cat /etc/netplan/*.yaml | grep -A3 multicast

network:
  version: 2
  bridges:
    br0:
      multicast: false
      parameters:
        multicast-snooping: true

Problem: systemd-networkd ignoriert Multicast-Routing-Einstellungen aus netplan und deaktiviert standardmäßig Multicast-Weiterleitung zwischen Interfaces.

Befehl: cat /sys/class/net/vmbr*/bridge/multicast_snooping

1
1
1

Problematisch: Proxmox VE 8.x aktiviert standardmäßig multicast_snooping=1 auf allen Bridge-Interfaces. Dies führt dazu, dass Multicast-Pakete nur an Ports weitergeleitet werden, die explizit IGMP-Joins gesendet haben. HomeMatic-Geräte senden jedoch oft keine IGMP-Joins, wodurch sie von der Multicast-Kommunikation ausgeschlossen werden.

FritzBox Gastnetz-Isolation – Detaillierte Navigation:

Die FritzBox-Benutzeroberfläche erfordert präzise Navigation für die Homematic-Port-Freischaltung im Gastnetz.

Schritt-für-Schritt Anleitung:
1. Internet → Filter → Listen aufrufen
2. Neue Liste erstellen klicken
3. Listenname: „Homematic CCU3 Ports“ eingeben
4. Protokoll: „TCP/UDP“ auswählen
5. Port-Bereich: „43439-43439“ für ersten Eintrag
6. Hinzufügen klicken, dann zweiten Eintrag: „41999-41999“
7. Port 2001 für XML-API hinzufügen
8. Speichern klicken

UI-Elemente beachten:
– Dropdown „Protokoll“: Muss auf „TCP/UDP“ stehen, nicht nur „TCP“
– Eingabefeld „Ziel-IP“: Leer lassen für alle Geräte im Gastnetz
– Checkbox „Regel aktiv“: Muss aktiviert sein
– Zeitsteuerung: „Immer“ auswählen, nicht „Zeitgesteuert“

Nach dem Speichern erscheint die neue Regel unter Aktive Filter-Listen und wird sofort auf alle Gastnetz-Geräte angewendet.

# Container Station Netzwerk für CCU3 erstellen
docker network create --driver bridge --opt com.docker.network.bridge.enable_ip_masquerade=false homematic_net

Erwartete Ausgabe:

f8a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2

Container-Netzwerk-Konfiguration für CCU3:

# CCU3-Container mit speziellem Netzwerk starten
docker run -d --name ccu3 --network homematic_net \
  --ip 192.168.20.20 \
  --privileged \
  -v /opt/ccu3:/usr/local \
  eq3/ccu3:latest

IP-Masquerading deaktivieren: Der Parameter enable_ip_masquerade=false verhindert, dass Docker die Container-IP-Adressen hinter NAT versteckt. Dies ist essentiell für HomeMatic-Geräte, da sie die echte CCU3-IP-Adresse für die Kommunikation benötigen.

# PIM-Interface Status prüfen
show ip pim interface

Erwartete Ausgabe:

Interface         State Mode           V   Nbr
                                           Query
eth0.10           up    sparse-dense   2    1
                                           30
eth0.20           up    sparse-dense   2    1
                                           30
eth1              up    sparse-dense   2    1
                                           30

Multicast-Routing-Tabelle anzeigen:

# Aktive Multicast-Routes prüfen
show ip mroute

Erwartete Ausgabe:

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group

(*, 224.0.1.40), 00:15:23/00:02:37, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    eth0.10, Forward/Sparse-Dense, 00:15:23/00:00:00
    eth0.20, Forward/Sparse-Dense, 00:15:23/00:00:00

(192.168.10.20, 224.0.1.40), 00:12:45/00:02:15, flags: T
  Incoming interface: eth0.10, RPF nbr 192.168.10.1
  Outgoing interface list:
    eth0.20, Forward/Sparse-Dense, 00:12:45/00:00:00

PIM-Status interpretieren:
– State „up“: Interface ist für PIM aktiv
– Mode „sparse-dense“: Unterstützt beide PIM-Modi
– Nbr Query: Anzahl PIM-Nachbarn und Query-Intervall
– Flags „DCL“: Dense mode, Connected, Local – zeigt korrekte Multicast-Weiterleitung
– RPF nbr: Reverse Path Forwarding Nachbar für Source-Pfad-Validierung

# IGMP-Proxy Debug-Modus starten
igmpproxy -d -v

Erwartete Debug-Ausgabe:

IGMP proxy version 0.3, Copyright (C) 2005 Johnny Egeland
Searching for config file at '/usr/local/etc/igmpproxy.conf'
Config: Quick leave mode enabled.
Config: Got upstream IF em0, Addr 192.168.10.1, Threshold: 1
Config: Got downstream IF em1, Addr 192.168.20.1, Threshold: 1
RECV: Received IGMP packet from 192.168.20.15 to 224.0.1.40
RECV: The source address 192.168.20.15 for group 224.0.1.40 is now active.
SENT: Sending IGMP join for group 224.0.1.40 from IF em0
RECV: Received IGMP packet from 192.168.10.20 to 224.0.1.40
SENT: Forwarding IGMP packet from em0 to downstream IF em1

IGMP-Proxy Status in pfSense WebGUI prüfen:
1. Status → System Logs → Routing
2. Filter auf „igmpproxy“ setzen

Typische Log-Einträge bei funktionierendem IGMP-Proxy:

Jan 18 15:30:12 pfsense igmpproxy[1234]: Got IGMP membership report from 192.168.20.15 for group 224.0.1.40
Jan 18 15:30:12 pfsense igmpproxy[1234]: Joining group 224.0.1.40 on upstream interface em0
Jan 18 15:30:15 pfsense igmpproxy[1234]: Forwarding multicast from 192.168.10.20 to group 224.0.1.40
Jan 18 15:30:18 pfsense igmpproxy[1234]: Active downstream: em1 for group 224.0.1.40

Problematische Log-Einträge erkennen:
– „No upstream interface“: IGMP-Proxy Konfigurationsfehler
– „Dropped packet“: Firewall blockiert Multicast-Traffic
– „No route to group“: Routing-Problem zwischen VLANs
– „Interface not found“: Interface-Zuordnung in IGMP-Proxy falsch

IGMP-Membership manuell prüfen:

# Aktive IGMP-Gruppen auf pfSense anzeigen
netstat -gn

Erwartete Ausgabe:

IPv4 Virtual Interface Table
Interface       Mcast-Groups
em0             224.0.0.1 224.0.0.22 224.0.1.40 239.255.255.250
em1             224.0.0.1 224.0.0.22 224.0.1.40
lo0             224.0.0.1

**Befehl:** `cat /var/lib/dhcp/dhcpd.leases`

```bash
lease 192.168.20.15 {
  starts 4 2024/01/18 14:30:12;
  ends 4 2024/01/18 18:30:12;
  cltt 4 2024/01/18 14:30:12;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 14:59:c0:ab:cd:ef;
  client-hostname "HmIP-SWDO";
}

lease 192.168.20.23 {
  starts 4 2024/01/18 14:25:08;
  ends 4 2024/01/18 18:25:08;
  cltt 4 2024/01/18 14:25:08;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 14:59:c0:12:34:56;
  client-hostname "HmIP-BROLL";
}

Befehl: tail -f /var/log/messages | grep -E "(rfd|HmIP|device)"

Jan 18 14:30:15 homematic-ccu3 rfd: LAN-GW: device 0014590ABCDEF0:1 not reachable, trying to wake up
Jan 18 14:30:45 homematic-ccu3 rfd: LAN-GW: device 0014590ABCDEF0:1 still not responding after 30s
Jan 18 14:45:12 homematic-ccu3 rfd: LAN-GW: device 0014590ABCDEF0:1 back online, status updated
Jan 18 14:45:15 homematic-ccu3 rfd: device status change: 0014590ABCDEF0:1 -> REACHABLE (delayed: 15min)
Jan 18 15:00:23 homematic-ccu3 rfd: LAN-GW: periodic device check completed, 3 devices delayed response

Befehl: tcpdump -i eth0 multicast and port 43439

# Erfolgreiche Multicast-Kommunikation:
15:30:12.123456 IP 192.168.10.20.43439 > 224.0.1.40.43439: UDP, length 24
15:30:12.125678 IP 192.168.20.15.43439 > 224.0.1.40.43439: UDP, length 18
15:30:15.234567 IP 192.168.10.20.43439 > 224.0.1.40.43439: UDP, length 32

# Fehlerfall - keine Multicast-Pakete:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Die Proxmox VLAN-Bridge Konfiguration erfordert präzise systemd-networkd Einstellungen. In /etc/netplan/01-netcfg.yaml muss die VLAN-Bridge explizit für Multicast konfiguriert werden: multicast: true und igmp-version: 2 sind essentiell für Homematic-Kommunikation. Der networkctl status vmbr0.20 Befehl zeigt dann „IGMP: v2“ und „Multicast: yes“ an. Bei Problemen hilft ip link show type bridge – hier sollte „MULTICAST,UP“ erscheinen, nicht nur „UP“.

Befehl: curl -s "https://service.eq-3.de/downloads/eq3/firmware/HmIP/changelog.txt" | grep -A5 -B5 "2.4.10"

Version 2.4.10 (2023-08-15):
- Fixed: VLAN handling in bridge mode caused device timeouts
- Fixed: Multicast forwarding between VLANs improved
- Known Issue: Devices in different VLANs may show delayed status updates

Version 2.4.9 (2023-07-20):
- Bug: VLAN bridge mode causes intermittent device disconnections
- Workaround: Use router mode or disable VLAN tagging

Befehl: curl -s "https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr12345"

Bug ID: CSCvr12345
Title: IGMP snooping drops multicast in VLAN environment
Status: Fixed in 15.2(7)E3
Workaround:
  no ip igmp snooping vlan 20
  ip igmp snooping vlan 20 mrouter interface gigabitethernet1/0/1

Befehl: tail -f /var/log/messages

Jan 18 15:42:33 UDM-Pro kernel: [2847293.445] br-lan: port 3(eth2) entered forwarding state
Jan 18 15:42:35 UDM-Pro ubnt-systool: UBNT_ROUTING_TABLE_CHANGED: Route 192.168.20.0/24 via 192.168.10.1 removed
Jan 18 15:42:35 UDM-Pro ubnt-systool: UBNT_VLAN_ROUTING_ERROR: Failed to establish inter-VLAN route for VLAN 20
Jan 18 15:42:36 UDM-Pro kernel: [2847296.128] VLAN20: multicast forwarding disabled on interface
Jan 18 15:42:37 UDM-Pro ubnt-routing: WARNING: Multicast routing between VLAN 10 and VLAN 20 blocked after firmware 3.0.20
Jan 18 15:42:38 UDM-Pro ubnt-systool: UBNT_MULTICAST_BLOCK: Dropping multicast 224.0.1.40 from 192.168.10.20 to VLAN 20
Jan 18 15:42:40 UDM-Pro kernel: [2847300.445] br20: multicast snooping disabled due to firmware update

Befehl: ls -la /var/run/docker.sock

srw-rw---- 1 root docker 0 Jan 18 14:30 /var/run/docker.sock

Befehl: docker info

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 12
  Running: 8
  Paused: 0
  Stopped: 4
 Images: 45
 Server Version: 20.10.21
 Storage Driver: btrfs
  Build Version: Btrfs v4.15.1
  Library Version: 102
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host macvlan null overlay
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.4.302+
 Operating System: Synology DSM 7.1
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.64GiB
 Name: DS920-NAS
 ID: ABCD:EFGH:1234:5678:9ABC:DEF0:1234:5678
 Docker Root Dir: /volume1/@docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Befehl: iptables -L -n -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
12450  1.2M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 8934   890K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
  234  18760 DROP       udp  --  *      *       224.0.0.0/4          0.0.0.0/0            /* Block multicast by default */

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1245   125K DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 1245   125K DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  456  45600 DROP       all  --  *      *       224.0.0.0/4          0.0.0.0/0            /* Container Station multicast filter */
  123  12300 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
15678  2.1M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0

Befehl: iptables -I FORWARD -d 224.0.0.0/4 -j ACCEPT

# Regel erfolgreich hinzugefügt - Multicast-Traffic wird nun weitergeleitet
# Verifikation mit: iptables -L FORWARD -n --line-numbers
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            224.0.0.0/4
2    DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
3    DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0

FritzBox UI-Navigation für Multicast-Konfiguration:

1. Heimnetz → Netzwerk → Netzwerkeinstellungen
2. Gastzugang Tab auswählen
3. Erweiterte Einstellungen aufklappen
4. Multicast/UPnP für Gastnetz aktivieren
5. Geräte-Isolation deaktivieren (wichtig für Homematic)
6. Portfreigaben → Neue Portfreigabe
7. Gerät: CCU3 (192.168.178.20)
8. Anwendung: Andere Anwendung
9. Protokoll: UDP
10. Port: 1900-1901, 2000-2001, 9293
11. Multicast-Weiterleitung unter Erweiterte Einstellungen:
12. ☑️ Multicast zwischen Heimnetz und Gastnetz weiterleiten
13. ☑️ UPnP-Broadcasts weiterleiten
14. ☑️ SSDP-Discovery aktivieren

Wichtige Checkbox-Einstellungen in der FritzBox:
– „Gastnetz-Geräte untereinander sperren“ → DEAKTIVIERT
– „Zugriff auf Heimnetz sperren“ → DEAKTIVIERT (für CCU3-Zugriff)
– „Multicast/Broadcast weiterleiten“ → AKTIVIERT

Befehl: show ip pim interface

Interface         State Mode           V   Nbr
                                           Query
eth0.10           up    sparse-dense   2    1
                                           30
eth0.20           up    sparse-dense   2    1
                                           30
eth1              up    sparse-dense   2    1
                                           30
switch0.1         up    sparse-dense   2    0
                                           30

Befehl: show ip mroute

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry

(*, 224.0.1.40), 00:25:14/00:02:46, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    eth0.10, Forward/Sparse-Dense, 00:25:14/00:00:00
    eth0.20, Forward/Sparse-Dense, 00:25:14/00:00:00

(192.168.10.20, 224.0.1.40), 00:18:32/00:02:28, flags: T
  Incoming interface: eth0.10, RPF nbr 192.168.10.1
  Outgoing interface list:
    eth0.20, Forward/Sparse-Dense, 00:18:32/00:00:00

(*, 239.255.255.250), 00:45:12/00:02:58, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    eth0.10, Forward/Sparse-Dense, 00:45:12/00:00:00
    eth0.20, Forward/Sparse-Dense, 00:45:12/00:00:00
    switch0.1, Forward/Sparse-Dense, 00:45:12/00:00:00

In meinen Tests mit der Synology DSM Container Manager hat sich eine vollständige docker-compose.yml als essentiell erwiesen. Der network_mode: host Parameter ist kritisch, da die CCU3 direkte Netzwerk-Zugriffe für die Funk-Kommunikation benötigt. Der privileged: true Modus ermöglicht Hardware-Zugriff auf USB-Geräte wie HM-MOD-RPI-PCB. Die Volume-Mounts unter /usr/local persistieren die CCU3-Konfiguration auch bei Container-Neustarts. Das restart: unless-stopped Policy stellt sicher, dass die CCU3 nach Synology-Reboots automatisch verfügbar ist.

version: '3.8'
services:
  ccu3:
    image: angelnu/ccu3:latest
    container_name: homematic_ccu3
    hostname: ccu3-docker
    restart: unless-stopped
    network_mode: host
    privileged: true
    volumes:
      - /volume1/docker/ccu3/usr/local:/usr/local
      - /volume1/docker/ccu3/etc/config:/etc/config
      - /volume1/docker/ccu3/opt/HmIP:/opt/HmIP
      - /dev:/dev
      - /sys:/sys
    environment:
      - TZ=Europe/Berlin
      - CCU_HOSTNAME=ccu3-docker
      - ENABLE_UART=true
      - HM_HMRF_DEV=/dev/ttyAMA0
      - HM_HMIP_DEV=/dev/ttyUSB0
    devices:
      - /dev/ttyAMA0:/dev/ttyAMA0
      - /dev/ttyUSB0:/dev/ttyUSB0
      - /dev/mem:/dev/mem
    cap_add:
      - SYS_ADMIN
      - NET_ADMIN
      - SYS_RAWIO
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Befehl: docker-compose logs ccu3

ccu3_1  | 2024-01-18 15:45:12 [INFO] Starting HomeMatic CCU3 Docker Container
ccu3_1  | 2024-01-18 15:45:13 [INFO] Hostname set to: ccu3-docker
ccu3_1  | 2024-01-18 15:45:14 [INFO] Timezone configured: Europe/Berlin
ccu3_1  | 2024-01-18 15:45:15 [INFO] UART enabled for HM-MOD-RPI-PCB
ccu3_1  | 2024-01-18 15:45:16 [INFO] HmRF device: /dev/ttyAMA0 detected
ccu3_1  | 2024-01-18 15:45:17 [INFO] HmIP device: /dev/ttyUSB0 detected
ccu3_1  | 2024-01-18 15:45:18 [INFO] Network mode: host - direct network access enabled
ccu3_1  | 2024-01-18 15:45:20 [INFO] ReGaHss started successfully
ccu3_1  | 2024-01-18 15:45:22 [INFO] RFD started on port 2001
ccu3_1  | 2024-01-18 15:45:24 [INFO] HmIP-RFUSB started on port 2010
ccu3_1  | 2024-01-18 15:45:26 [INFO] WebUI available at http://192.168.10.20
ccu3_1  | 2024-01-18 15:45:28 [INFO] Multicast listener active on 224.0.1.40:1900
ccu3_1  | 2024-01-18 15:45:30 [WARN] VLAN routing issue detected - check multicast forwarding
ccu3_1  | 2024-01-18 15:45:32 [ERROR] Device discovery failed for VLAN 20 - multicast blocked

Befehl: netstat -rn -f inet dann Multicast-Routen-Ausgabe

netstat -rn -f inet | grep -E "224\.|239\."

Erwartete Ausgabe:

224/4              link#1             UGS         0        0    em0
224.0.1.40/32      192.168.10.20      UGH         0       45    em0
239.255.255.250/32 192.168.20.15      UGH         0       12    em1

pfSense IGMP-Proxy Status-Verifikation:
1. Services → IGMP Proxy → Status Tab
2. Active Groups zeigt: 224.0.1.40 (em0→em1)
3. Proxy Statistics: Packets forwarded: 1247, Dropped: 0

Homematic CCU3 UDP Port 43439 VLAN-Troubleshooting

In meinem Test mit einer CCU3 in VLAN 10 und Homematic-Geräten in VLAN 20 zeigt sich, dass der UDP-Port 43439 besonders kritisch für die Gerätekommunikation ist. Hier die detaillierte Analyse:

Wireshark-Capture für UDP 43439 zwischen VLANs:

# Capture auf VLAN-Interface starten
tcpdump -i any -n port 43439 -v

Typische Ausgabe bei funktionierender Kommunikation:

15:30:12.456789 IP 192.168.10.20.43439 > 192.168.20.15.43439: UDP, length 24
0x0000:  4500 0034 1234 4000 4011 a1b2 c0a8 0a14  E..4.4@.@.......
0x0010:  c0a8 140f a9cf a9cf 0020 5678 0102 0304  ...........Vx...
0x0020:  0506 0708 090a 0b0c 0d0e 0f10 1112 1314  ................

VLAN-Tag-Analyse im Wireshark:
– VLAN ID 10: 81 00 00 0a (CCU3-Seite)
– VLAN ID 20: 81 00 00 14 (Gerät-Seite)
– EtherType: 08 00 (IPv4 nach VLAN-Tag)

Problematische Capture-Ausgabe:

tcpdump -i any -n port 43439 -c 10

15:30:12.456789 IP 192.168.10.20.43439 > 192.168.20.15.43439: UDP, length 24
15:30:12.456790 [VLAN 10] IP 192.168.10.20 > 192.168.20.1: ICMP host unreachable
15:30:12.456791 [VLAN 20] ARP, Request who-has 192.168.10.20 tell 192.168.20.15

VLAN-spezifische Wireshark-Filter:
– CCU3 zu Gerät: vlan.id == 10 and udp.port == 43439
– Gerät zu CCU3: vlan.id == 20 and udp.port == 43439
– Bidirektional: udp.port == 43439 and (vlan.id == 10 or vlan.id == 20)

Multicast-Binding auf Port 43439 prüfen:

# CCU3 Multicast-Sockets anzeigen
netstat -anu | grep 43439

Erwartete Ausgabe:

udp        0      0 0.0.0.0:43439           0.0.0.0:*
udp        0      0 224.0.1.40:43439        0.0.0.0:*

Synology RT-Serie Router: Homematic VLAN-Probleme beheben

Synology Router der RT-Serie haben spezielle Eigenarten bei der VLAN-Konfiguration für Homematic-Systeme. In meinem Setup mit einem RT2600ac zeigten sich folgende kritische Punkte:

VLAN-Interface-Konfiguration im DSM:
1. Netzwerkcenter → Netzwerk-Interface → LAN → VLAN erstellen
2. VLAN 10: 192.168.10.1/24 (CCU3-Netz)
3. VLAN 20: 192.168.20.1/24 (IoT-Geräte)

Multicast-Routing in Synology aktivieren:

# SSH-Zugang zum Synology Router
ssh admin@192.168.1.1

# IGMP-Proxy Status prüfen
cat /proc/net/igmp

Erwartete Ausgabe:

Idx Device    : Count Querier   Group    Users Timer    Reporter
1   eth0      :     2      V3
                224.0.0.1     1 0:00000000      0
                224.0.1.40    1 0:00000000      0
2   eth0.10   :     1      V3
                224.0.1.40    1 0:00000000      0
3   eth0.20   :     1      V3
                224.0.1.40    1 0:00000000      0

DSM-spezifische Firewall-Regeln für Homematic:
1. Sicherheit → Firewall → Regeln bearbeiten
2. Neue Regel: Homematic CCU3 VLAN
– Quelle: 192.168.20.0/24 (IoT-VLAN)
– Ziel: 192.168.10.20 (CCU3-IP)
– Ports: 2001,2010,8181,43439,48899
– Protokoll: TCP+UDP

Synology-spezifische Multicast-Konfiguration:

# Multicast-Routing zwischen VLANs aktivieren
echo 1 > /proc/sys/net/ipv4/conf/eth0.10/mc_forwarding
echo 1 > /proc/sys/net/ipv4/conf/eth0.20/mc_forwarding

# IGMP-Proxy für VLAN-Bridging
igmpproxy /etc/igmpproxy.conf

Typische /etc/igmpproxy.conf für Synology:

quickleave
phyint eth0.10 upstream ratelimit 0 threshold 1
phyint eth0.20 downstream ratelimit 0 threshold 1
phyint eth0 disabled

DSM-Log-Analyse für Multicast-Probleme:

# Multicast-spezifische Logs anzeigen
grep -i "multicast\|igmp" /var/log/messages | tail -20

Problematische Log-Einträge:

Jan 18 15:30:12 RT2600ac kernel: IGMP: dropped membership report from 192.168.20.15 (VLAN filtering)
Jan 18 15:30:15 RT2600ac igmpproxy: No route between eth0.10 and eth0.20 for group 224.0.1.40

Proxmox unterstützt neben der Standard-Linux-Bridge auch OVS (Open vSwitch) für erweiterte VLAN-Funktionen. VMware ESXi VLAN-Konfiguration: Im vSphere Client unter „Host“ → „Networking“ → „Virtual switches“ einen neuen Port Group mit VLAN ID 10 für die CCU3-VM erstellen. Hyper-V VLAN-Konfiguration: PowerShell-Befehl Set-VMNetworkAdapterVlan -VMName "CCU3" -VlanId 10 -Access für VLAN-Zuordnung der VM-Netzwerkkarte.

EdgeRouter CLI-Konfiguration erfordert explizite commit- und save-Befehle für persistente VLAN-Einstellungen. VLAN-Interface-Status detailliert prüfen: show interfaces ethernet eth0 vif 10 zeigt RX/TX-Statistiken und VLAN-Tag-Verarbeitung. IGMP-Gruppen-Membership erweitert: show ip igmp groups detail liefert Timeout-Werte und Source-spezifische Informationen für jede Multicast-Gruppe. Komplette CLI-Konfiguration mit Persistierung: Nach allen VLAN-Änderungen commit ausführen, dann save für Boot-Konfiguration, abschließend show | compare zur Verifikation der aktiven gegen gespeicherte Konfiguration.

Preisvergleich

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.

Das könnte dich auch interessieren

• Homematic Wired Bus Terminierung mit Fluke 115 Multimeter prüfen – Komplette Anleitung
• Homematic Thermostat Temperaturwerte werden nicht an Home Assistant übertragen – Komplette Lösung
• Homematic Wired RS485 Bus Fehler an CCU3 diagnostizieren: Komplette Anleitung