WLAN und CAPsMAN

5-GHz-Kanalprüfung

Ein Channel-Availability-Check kann ein 5-GHz-Radio vorübergehend vom Netz nehmen. Das ist während der Prüfung erwartbar und kein unmittelbarer Hardwarefehler.

Produktiver Stand, geprüft am 1. September 2026.

Aktueller Aufbau

Das WLAN wird zentral vom MikroTik hAP ax2 (10.10.10.1) über die RouterOS-7-WLAN-CAPsMAN-Implementierung verwaltet.

Gerät	Rolle	Management-IP	RouterOS
hAP ax2	Router, CAPsMAN-Manager und Access Point	10.10.10.1	7.24.1 (stable)
hAP ax S – AP2	Access Point Wohnzimmer	10.10.10.2	7.24.1 (stable)
hAP ax S – AP3	Access Point Treppenhaus	10.10.10.3	7.24.1 (stable)

Alle drei Geräte senden die zentral provisionierten WLANs.

WLANs und VLANs

SSID	Konfiguration	VLAN	Zweck
DieBrocks.home	cfg-dev-*	20	private und vertrauenswürdige Geräte
IoT@DieBrocks.home	cfg-iot	30	IoT-Geräte
Gast@DieBrocks.home	cfg-guest	40	Gäste, nur Internet
MGMT@DieBrocks.home	cfg-mgmt	10	verstecktes, nur temporär provisioniertes Management-WLAN für Matter-Commissioning

Die internen Namen mit dev stammen aus der Einrichtungsphase. Für die Funktion ist keine Umbenennung erforderlich.

MGMT@DieBrocks.home ist bewusst nicht dauerhaft aktiv. Es wird nur bei Bedarf auf AP1 2,4 GHz zugeschaltet und danach wieder entfernt.

Temporäres MGMT-WLAN für Matter

Für Matter-over-Thread-Commissioning vom iPhone wurde ein separates Management-WLAN eingerichtet:

• SSID: MGMT@DieBrocks.home
• versteckt
• VLAN 10
• nur AP1 HWR, 2,4 GHz
• Konfiguration: cfg-mgmt
• im Normalbetrieb nicht provisioniert

Hintergrund: Pairing aus VLAN 30 scheiterte trotz IPv6-Unicast-Routing, während Pairing aus VLAN 10 zuverlässig funktionierte. Der RouterOS-mDNS-Repeater spiegelt nur IPv4-mDNS und deckt damit den für Matter relevanten IPv6-mDNS-Pfad nicht vollständig ab.

RouterOS-Skripte

Auf dem Router existieren:

• MGMT_WLAN_Ein
• MGMT_WLAN_Aus

MGMT_WLAN_Ein setzt auf AP1 2,4 GHz:

slave-configurations=cfg-iot,cfg-guest,cfg-mgmt

und provisioniert das Radio neu.

MGMT_WLAN_Aus setzt wieder:

slave-configurations=cfg-iot,cfg-guest

und provisioniert AP1 2,4 GHz erneut.

Die MikroTik-Extended-Integration kann RouterOS-Skripte mit der Option Skript-Schalter in Home Assistant als ausführbare Entitäten bereitstellen.

VLAN-Trunks

Die physische Verkabelung der Access Points einschließlich Patchfeld-Ports und Hausverkabelung ist unter Patchfeld und Verkabelung dokumentiert.

Auf den Uplinks gilt:

• VLAN 10 untagged/native für Management;
• VLAN 20 tagged für Home;
• VLAN 30 tagged für IoT;
• VLAN 40 tagged für Gäste.

AP2

Port	Funktion
ether1	Uplink zum hAP ax2
ether5	Trunk zu AP3
ether2, ether3	als Home-VLAN-Access-Ports vorbereitet, wegen beobachteter PHY-/Clientprobleme nicht produktiv genutzt
ether4	ungenutzt

AP3

Port	Funktion
ether1	Uplink von AP2
ether5	für einen möglichen nachgelagerten AP vorbereitet, aktuell ohne Link
ether2, ether3	als Home-VLAN-Access-Ports vorbereitet, nicht produktiv genutzt
ether4	ungenutzt

Management der Access Points

Auf beiden hAP ax S existiert das VLAN-Interface mgmt auf bridgeLocal. Der DHCP-Client läuft auf diesem Interface und erhält die feste Reservierung im VLAN 10.

AP	DHCP-Adresse	CAPsMAN-Manager	Device Mode
AP2	10.10.10.2	10.10.10.1	advanced
AP3	10.10.10.3	10.10.10.1	advanced

AP3 wurde am 1. September 2026 vom RouterOS-Device-Mode home auf advanced umgestellt. Damit ist dort unter anderem der Scheduler freigegeben. AP2 lief bereits im advanced-Modus.

Zeitsynchronisation

AP1 synchronisiert seine Uhr per NTP mit den PTB-Zeitservern und stellt selbst einen NTP-Server im Management-Netz bereit.

AP2 und AP3 verwenden AP1 unter 10.10.10.1 als dynamisch gelernte NTP-Quelle. Der NTP-Client muss auf beiden Access Points aktiviert sein:

/system ntp client set enabled=yes

Kontrolle:

/system ntp client print
/system clock print

Sollzustand auf AP2 und AP3:

• status=synchronized
• synced-server=10.10.10.1
• synced-stratum=2

Am 5. Oktober 2026 waren die NTP-Clients auf AP2 und AP3 deaktiviert. Dadurch liefen beide Uhren ungefähr fünf Minuten vor. Nach Aktivierung synchronisierten sich beide Geräte wieder mit AP1 und lagen nur noch wenige Millisekunden daneben.

CAP-Modus auf beiden Geräten:

enabled: yes
discovery-interfaces: bridgeLocal
slaves-datapath: capdp
current-caps-man-address: 10.10.10.1

Kanalplan

2,4 GHz

Alle 2,4-GHz-Radios laufen mit 20 MHz und sind fest auf die klassischen nicht überlappenden Kanäle verteilt:

AP	Kanal	Frequenz	Channel-Profil	Master-Konfiguration
AP2 Wohnzimmer	1	2412 MHz	ch-2g-ap2	cfg-dev-ap2-2g
AP3 Treppenhaus	6	2437 MHz	ch-2g-ap3	cfg-dev-ap3-2g
AP1 HWR	11	2462 MHz	ch-2g-ap1	cfg-dev-ap1-2g

Der frühere Zustand mit AP2 und AP3 gleichzeitig auf Kanal 1 wurde am 10. August 2026 bereinigt.

5 GHz

Alle drei 5-GHz-Radios laufen mit 80 MHz und sind fest verteilt (Stand 23. Oktober 2026):

AP	Primärkanal	Frequenz	80-MHz-Block	DFS	Channel-Profil
AP2 Wohnzimmer	36	5180 MHz	36–48	nein	ch-5g-ap2
AP3 Treppenhaus	100	5500 MHz	100–112	ja	ch-5g-ap3
AP1 HWR	52	5260 MHz	52–64	ja	ch-5g-ap1

Damit überlappen die drei 80-MHz-Blöcke nicht.

Bis 23. Oktober 2026 lag AP3 auf 5260 MHz (52–64) und AP1 auf 5500 MHz (100–112). AP3 sendete dort mit dem hAP ax S nur 14 dBm, und alle beobachteten 5-GHz-Abbrüche (z. B. not responding, connection lost bei −55 bis −69 dBm) traten an AP3-5G auf. Nach dem Tausch sendet AP3 mit 17 dBm wie die anderen beiden 5-GHz-Radios.

Bei 80 MHz ist in Deutschland nur ein DFS-freier Block (36–48) verfügbar. Ein Betrieb aller drei APs ohne DFS ginge nur mit 20 oder 40 MHz. Der Block 116–128 enthält den Wetterradarbereich (10 Minuten Kanalprüfung) und wird nicht genutzt; 132–140 reicht nicht für 80 MHz.

Nachbar-Scan vom 23. Oktober 2026 im 5-GHz-Band: nur SimmannsHome (160 MHz, 36–64, −87 bis −93 dBm) und Buschmann-GF (160 MHz, 100–128, −88 bis −94 dBm). Beide sind für unsere Funkzellen praktisch ohne Bedeutung.

Sendeleistung

Stand 23. Oktober 2026 (geprüft mit /interface/wifi/monitor):

Radio	Kanal	tx-power	Einstellung
AP1-HWR-2G	11	15 dBm	automatisch
AP1-HWR-5G	52	17 dBm	fest in cfg-dev-ap1-5g (tx-power=17)
AP2-Wohnzimmer-2G	1	14 dBm	automatisch
AP2-Wohnzimmer-5G	36	17 dBm	automatisch
AP3-Treppenhaus-2G	6	14 dBm	automatisch
AP3-Treppenhaus-5G	100	17 dBm	fest in cfg-dev-ap3-5g (tx-power=17)

Hintergrund: Ohne feste Vorgabe nutzt RouterOS das jeweils zulässige Maximum, das je nach Gerät und Kanal stark abweicht. Beobachtete automatische Werte:

• hAP ax2 (AP1) auf Kanal 100: 25 dBm; auf Kanal 52: 25 dBm
• hAP ax S (AP3) auf Kanal 52: 14 dBm
• hAP ax S (AP2) auf Kanal 36: 17 dBm

Bis 14. Oktober 2026 sendete AP1-HWR-5G deshalb mit 25 dBm. Clients hörten AP1 dadurch auch im Wohnzimmer lauter als AP2 und verbanden sich mit AP1, obwohl ihr eigenes Signal dort schwach ankam (asymmetrische Verbindung). Beispiel aus dem Log vom 14. Oktober 2026: Ein Smartphone wechselte von AP2-Wohnzimmer-5G (−49 dBm) zu AP1-HWR-5G (−66 dBm). Seitdem ist AP1-HWR-5G fest auf 17 dBm begrenzt.

Seit dem Kanaltausch vom 23. Oktober 2026 ist auch AP3-Treppenhaus-5G fest auf 17 dBm gesetzt. Damit senden alle drei 5-GHz-Radios gleich stark. Die IoT- und Gast-Slaves auf demselben Radio übernehmen den Wert des Master-Interfaces.

/interface/wifi/configuration/set [find name="cfg-dev-ap1-5g"] tx-power=17
/interface/wifi/configuration/set [find name="cfg-dev-ap3-5g"] tx-power=17

Wichtig: Wird tx-power bei AP1 entfernt, sendet AP1 wieder mit 25 dBm.

Provisioning-Konfiguration

Die bekannten Radios haben eigene Master-Konfigurationen, damit Kanal und Name dauerhaft stabil bleiben.

2,4 GHz

• AP2 → cfg-dev-ap2-2g
• AP3 → cfg-dev-ap3-2g
• AP1 → cfg-dev-ap1-2g
• generischer 2,4-GHz-Fallback → cfg-dev-2g

5 GHz

• AP2 → cfg-dev-ap2-5g
• AP3 → cfg-dev-ap3-5g
• AP1 → cfg-dev-ap1-5g
• generischer 5-GHz-Fallback → cfg-dev

cfg-iot und cfg-guest werden dauerhaft als virtuelle Slave-Konfigurationen bereitgestellt. cfg-mgmt wird nur temporär als zusätzlicher Slave auf AP1 2,4 GHz hinzugefügt.

Die Datenverarbeitung findet auf dem jeweiligen CAP statt.

Interface-Namen

Die produktiven Master-Interfaces heißen:

• AP1-HWR-2G
• AP1-HWR-5G
• AP2-Wohnzimmer-2G
• AP2-Wohnzimmer-5G
• AP3-Treppenhaus-2G
• AP3-Treppenhaus-5G

Die virtuellen Slave-Interfaces werden aktuell automatisch mit -virtual und -virtual2 benannt. Dabei ist der erste Slave IoT und der zweite Gast. Bei aktiviertem MGMT-WLAN kommt auf AP1 2,4 GHz ein dritter virtueller Slave hinzu.

Roaming

Für das Home-WLAN sind aktiviert:

• WPA2-PSK und WPA3-PSK;
• 802.11r Fast Transition;
• Fast Transition over DS;
• 802.11k Radio Resource Management;
• 802.11v Wireless Network Management.

Steering-Werte (Stand 23. Oktober 2026):

Parameter	DieBrocks.home (cfg-dev*)	IoT und Gast (cfg-iot, cfg-guest)
transition-threshold	−65	−70
transition-threshold-time	10s	10s
transition-request-period	10s	10s
transition-request-count	3	3
transition-time	unlimited	unlimited

Liegt das Signal eines Clients 10 Sekunden lang unter der Schwelle, schickt der AP über 802.11v eine Wechselaufforderung mit den Nachbar-APs. Der Client entscheidet selbst, ob er wechselt; getrennt wird er dadurch nicht.

Die Schwelle für DieBrocks.home wurde am 23. Oktober 2026 von −70 auf −65 dBm angehoben. Anlass: Geräte (z. B. Google Nest Minis) verbanden sich nach einer Trennung mit einem deutlich schwächeren AP (−68 bis −79 dBm), obwohl ein AP mit −53 bis −56 dBm verfügbar war. Bei −70 dBm erhielten sie keine Wechselaufforderung. Die Änderung wirkte ohne Neustart der Radios und ohne Trennung von Clients. IoT und Gast bleiben bewusst bei −70 dBm.

/interface/wifi/configuration/set [find where ssid="DieBrocks.home"] steering.transition-threshold=-65

Rückgängig machen:

/interface/wifi/configuration/set [find where ssid="DieBrocks.home"] steering.transition-threshold=-70

Es existiert bewusst keine harte globale RSSI-Disconnect-Regel, da entfernte IoT-Geräte sonst unnötig getrennt werden könnten.

Zugriffsliste (Access-List)

Die Zugriffsliste liegt auf dem CAPsMAN-Manager (10.10.10.1) unter /interface/wifi/access-list. Die Regeln werden von oben nach unten ausgewertet; die erste passende Regel gilt.

Gerät	MAC	Regel	Zustand
Anker SolarBank3	F4:9D:8A:B6:1B:17	accept ab −70 dBm, reject darunter	deaktiviert
Katzen Kamera	EC:71:DB:D0:43:CB	accept an AP2-Wohnzimmer-5G-virtual	aktiv
Katzen Kamera	EC:71:DB:D0:43:CB	accept an AP2-Wohnzimmer-2G-virtual	aktiv
Katzen Kamera	EC:71:DB:D0:43:CB	reject an allen anderen Interfaces	aktiv
Navimow i105e	44:87:63:95:65:B6	accept an AP2-Wohnzimmer-2G-virtual	aktiv
Navimow i105e	44:87:63:95:65:B6	reject an allen anderen Interfaces	aktiv

Gerätebezogene Regeln sind nur als Notlösung gedacht; generelle Lösungen über Kanalplan, Sendeleistung und Steering haben Vorrang.

Die Katzen Kamera ist seit 20. Oktober 2026 an AP2 gebunden. Hintergrund: Sie wechselte mehrfach von AP2 (um −41 dBm) zu AP1-HWR (−54 bis −60 dBm) und verlor dort die Verbindung. An AP2 ist die Versorgung gut.

Der Mähroboter Navimow i105e (IoT, 10.10.30.85) ist seit 23. Oktober 2026 an AP2 2,4 GHz gebunden. Hintergrund: Er wechselte auch in der Ladestation, also ohne Bewegung, im Abstand von Sekunden bis Minuten zwischen AP2 (um −58 dBm), AP3 (um −69 dBm) und AP1 (um −80 dBm) und verlor dabei regelmäßig die Verbindung. Die Wechsel gingen vom Mäher selbst aus. AP2 ist sowohl an der Ladestation als auch im Mähbereich des Gartens der nächstgelegene AP. Der Mäher arbeitet gegen 11 Uhr etwa 30 Minuten. Nach der Bindung sank die Zahl der Abbrüche von etwa einem alle 2–10 Minuten auf drei am restlichen Tag; während der Mähfahrt gab es keinen.

Beim Ändern der Zugriffsliste trennt RouterOS betroffene Clients kurz (disconnected, access-list changed); sie verbinden sich danach neu.

Kontrolle:

/interface/wifi/access-list/print detail
/interface/wifi/registration-table/print stats where mac-address=EC:71:DB:D0:43:CB
/interface/wifi/registration-table/print stats where mac-address=44:87:63:95:65:B6

LEDs

AP2 und AP3 verwenden:

/system/leds/settings/set all-leds-off=after-1min

Nach einem Neustart sind die LEDs ungefähr eine Minute sichtbar und werden danach abgeschaltet. Der Router im HWR verwendet weiterhin die normale LED-Anzeige.

Automatischer RouterOS-Update-Check

Auf allen drei MikroTik-Geräten ist der Scheduler routeros-update-check eingerichtet.

Gerät	IP	Zeit	Intervall	Aktion
hAP ax2 Router / AP1	10.10.10.1	03:15 Uhr	täglich	/system package update check-for-updates
hAP ax S – AP2	10.10.10.2	03:15 Uhr	täglich	/system package update check-for-updates
hAP ax S – AP3	10.10.10.3	03:15 Uhr	täglich	/system package update check-for-updates

Der Scheduler prüft ausschließlich, ob eine neue RouterOS-Version verfügbar ist. Es werden keine Updates automatisch installiert und kein Gerät automatisch neu gestartet.

Wichtig: Der Scheduler benötigt die Policy policy. Der korrekte Sollzustand lautet:

policy=read,write,policy,test

Ohne policy wird der Scheduler zwar ausgelöst und der run-count erhöht, der eigentliche Update-Check scheitert jedoch mit:

not enough permissions (9)
/system/package/update/check-for-updates

Das wurde am 5. Oktober 2026 auf AP3 nachvollzogen. Nach Ergänzung von policy lief der Scheduler erfolgreich, RouterOS setzte latest-version, und Home Assistant erkannte das verfügbare RouterOS-Update unmittelbar danach. Die Home-Assistant-Integration stößt selbst keinen Update-Check an, sondern liest den von RouterOS gespeicherten Status.

Stand 5. Oktober 2026 laufen alle drei Geräte mit RouterOS 7.24.2; AP1 und AP3 verwenden den Kanal stable.

Prüfung des Schedulers:

/system/scheduler/print detail where name="routeros-update-check"

Manueller Update-Check:

/system/package/update/check-for-updates

RouterBOARD-Firmware wird dadurch nicht automatisch aktualisiert.

Automatischer RouterBOOT-Abschluss nach RouterOS-Updates

Auf allen drei MikroTik-Geräten ist auto-upgrade=yes gesetzt. Zusätzlich existieren als admin:

• Script routerboard-boot-check
• Startup-Scheduler routerboard-auto-reboot

Der Ablauf nach einem RouterOS-Update ist damit:

1. RouterOS wird installiert und das Gerät startet neu.
2. RouterBOOT wird durch auto-upgrade=yes auf die zum neuen RouterOS gehörende Version vorbereitet.
3. Beim Start führt routerboard-auto-reboot das Script routerboard-boot-check aus.
4. Das Script wartet fünf Sekunden und vergleicht current-firmware mit upgrade-firmware.
5. Sind beide gleich, erfolgt nur ein Logeintrag RouterBOOT aktuell: <Version>.
6. Sind sie unterschiedlich, wird einmalig ein zweiter Neustart ausgelöst, damit die neue RouterBOOT-Version aktiv wird.
7. Die bereits versuchte Zielversion wird im Scheduler-Kommentar gespeichert. Dadurch entsteht bei einem fehlgeschlagenen RouterBOOT-Upgrade keine Reboot-Schleife.

Benötigte Script- und Scheduler-Policies:

reboot,read,write,policy,test

Das Script und der Startup-Scheduler müssen deshalb mit einem Benutzer angelegt werden, der reboot und policy besitzt. Der eingeschränkte MCP-Benutzer auf AP2 und AP3 reicht dafür nicht aus.

Stand 5. Oktober 2026:

• AP1, AP2 und AP3: RouterOS 7.24.5
• AP1, AP2 und AP3: current-firmware=7.24.5
• AP1, AP2 und AP3: upgrade-firmware=7.24.5
• AP1, AP2 und AP3: auto-upgrade=yes

Prüfung:

/system/routerboard/print
/system/routerboard/settings/print
/system/script/print detail where name="routerboard-boot-check"
/system/scheduler/print detail where name="routerboard-auto-reboot"
/log/print where message~"RouterBOOT"

Wiederaufbau eines hAP ax S

1. Gerät vorbereiten

1. RouterOS auf dieselbe Stable-Version wie den Manager bringen.
2. Uplink zunächst an ether1 anschließen.
3. Gerätenamen passend zu AP2 oder AP3 setzen.
4. Device Mode advanced verwenden, damit die für den Betrieb benötigten RouterOS-Funktionen einschließlich Scheduler verfügbar sind.
5. CAP-Modus aktivieren.

2. Management-VLAN anlegen

/interface/vlan/add interface=bridgeLocal vlan-id=10 name=mgmt
/ip/dhcp-client/set [find] interface=mgmt

3. Port-PVIDs setzen

/interface/bridge/port/set [find interface=ether1] pvid=10
/interface/bridge/port/set [find interface=ether2] pvid=20
/interface/bridge/port/set [find interface=ether3] pvid=20
/interface/bridge/port/set [find interface=ether5] pvid=10

4. VLAN-Tabelle setzen

/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=10 tagged=bridgeLocal untagged=ether1,ether5
/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=20 tagged=ether1,ether5 untagged=ether2,ether3
/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=30 tagged=ether1,ether5
/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=40 tagged=ether1,ether5

5. VLAN-Filtering zuletzt aktivieren

/interface/bridge/set bridgeLocal vlan-filtering=yes

Dieser Schritt muss zuletzt erfolgen.

6. CAPsMAN-Verbindung prüfen

/interface/wifi/cap/print
/interface/wifi/print detail

7. Kanalprofile wiederherstellen

2,4 GHz:
AP2 = 2412 MHz / Kanal 1 / 20 MHz
AP3 = 2437 MHz / Kanal 6 / 20 MHz
AP1 = 2462 MHz / Kanal 11 / 20 MHz

5 GHz:
AP2 = 5180 MHz / Kanal 36 / 80 MHz
AP3 = 5500 MHz / Kanal 100 / 80 MHz
AP1 = 5260 MHz / Kanal 52 / 80 MHz

Die festen Sendeleistungen von AP1-HWR-5G und AP3-Treppenhaus-5G (tx-power=17 in cfg-dev-ap1-5g bzw. cfg-dev-ap3-5g) und die Steering-Werte liegen auf dem Manager und müssen beim Wiederaufbau eines hAP ax S nicht gesetzt werden.

Kontrolle und Diagnose

Auf dem Router:

/interface/wifi/registration-table/print stats detail
/interface/wifi/configuration/print detail
/interface/wifi/channel/print detail
/interface/wifi/provisioning/print detail
/interface/wifi/monitor AP3-Treppenhaus-5G once
/system/script/print detail where name~"MGMT_WLAN"

WLAN-Scan unterbricht den Betrieb

/interface/wifi/scan stoppt das betroffene Radio für die Dauer des Scans vollständig. Alle Clients dieses Radios werden getrennt. Auf DFS-Kanälen folgt danach zusätzlich eine erneute Kanalprüfung von etwa einer Minute. Beim Scan am 23. Oktober 2026 waren dadurch alle 5-GHz-Radios für ein bis drei Minuten nicht verfügbar, und die Clients wichen auf 2,4 GHz aus. Scans nur bewusst und möglichst zu ruhigen Zeiten durchführen. Mit save-file=<name> wird das Ergebnis als Datei auf dem Router abgelegt.

Logging auf dem Router

WLAN-Ereignisse der CAPs (Verbinden, Trennen, Roaming) werden im Log des CAPsMAN-Managers (10.10.10.1) protokolliert. Der Log liegt im RAM und geht bei einem Neustart verloren. Ein externer Syslog-Empfänger existiert nicht; die Aktion remote ist nicht konfiguriert.

Die Log-Aktion memory ist seit 23. Oktober 2026 auf memory-lines=20000 gesetzt (vorher Standard 1000). Der Speicherbedarf ist gering (wenige MB bei rund 580 MiB freiem RAM).

/system/logging/action/set [find name=memory] memory-lines=20000

Regel	Topics	Aktion	Zustand
0	info	memory	aktiv (Standard)
1	error	memory	aktiv (Standard)
2	warning	memory	aktiv (Standard)
3	critical	echo	aktiv (Standard)
4	dhcp	memory	deaktiviert
5	wireless	memory	aktiv (inkl. Debug-Meldungen wie associated)

Die Regel dhcp wurde am 22. Oktober 2026 deaktiviert. Sie schrieb zusätzlich alle DHCP-Debug- und Paketzeilen in den Log; diese belegten rund 94 % des Puffers, sodass WLAN-Ereignisse nach etwa zehn Minuten überschrieben waren. Normale DHCP-Meldungen erscheinen weiterhin über die Regel info.

Bis zur Bindung an AP2 (siehe Zugriffsliste) war der Mähroboter Navimow i105e der größte Verursacher von WLAN-Logzeilen; am Morgen des 23. Oktober 2026 stammten rund 80 % der WLAN-Zeilen von ihm.

Für eine DHCP-Fehlersuche vorübergehend wieder einschalten:

/system/logging/enable [find where topics="dhcp" and action=memory]

Danach wieder deaktivieren:

/system/logging/disable [find where topics="dhcp" and action=memory]

Bekannte Probleme und Hinweise

Matter-Commissioning über VLAN-Grenzen

Matter-over-Thread-Commissioning vom iPhone aus dem IoT-VLAN funktioniert aktuell nicht zuverlässig. IPv6-Unicast-Routen sind vorhanden, aber das Commissioning erreicht den Matter Server aus VLAN 30 nicht. Der Workaround ist das temporäre Management-WLAN in VLAN 10. Details stehen unter home-assistant/matter-thread.md.

DFS

Nach dem Provisionieren eines 5-GHz-Radios kann ein Channel-Availability-Check stattfinden. Währenddessen sendet das Radio kurzzeitig nicht. Das ist kein Fehler.

Stationäre Clients

Einzelne Geräte bleiben trotz schwächerem Signal an einem Access Point, wenn sie Steering-Anfragen nicht oder nur eingeschränkt unterstützen.

Google-Lautsprecher

Am 23. Oktober 2026 verbanden sich Google Nest Minis nach einer Trennung innerhalb einer Sekunde neu, teils mit einem deutlich schwächeren AP (z. B. AP1-HWR-2G mit −79 dBm statt AP3 mit −56 dBm, oder AP2-5G mit −84 dBm). Liegt das Signal danach über der Steering-Schwelle, schickt der AP keine Wechselaufforderung, und das Gerät bleibt dort. Deshalb wurde die Schwelle für DieBrocks.home auf −65 dBm angehoben (siehe Roaming).

Am 23. Oktober 2026 zwischen 19:45 und 19:50 Uhr verloren alle acht Google-Geräte fast gleichzeitig an allen drei APs die Verbindung. Auf Router und APs gab es zu dieser Zeit kein Ereignis (kein Neustart, kein Radar, kein Kanalwechsel). Die Ursache lag vermutlich bei den Geräten selbst (z. B. Update oder Neustart), ist aber nicht belegt.

Bevorzugung von AP1 auf 5 GHz

Bis 14. Oktober 2026 verbanden sich Clients im Wohnzimmer häufig mit AP1-HWR-5G statt AP2, weil AP1 mit 25 dBm deutlich lauter sendete. Ursache und Korrektur siehe Abschnitt Sendeleistung.

Hängende Clients mit 6 Mbit/s

Am 19. Oktober 2026 war die Katzen Kamera an AP2 angemeldet (−41 bis −46 dBm), aber kaum erreichbar (80 % Paketverlust). Die Senderate des AP zur Kamera stand dauerhaft bei 6 Mbit/s und erholte sich nicht. Ein Rauswurf aus dem WLAN behob das sofort:

/interface/wifi/registration-table/remove [find mac-address=EC:71:DB:D0:43:CB]

Ein ähnliches Bild gab es zuvor bei einem iPhone an AP3. Die Ursache ist nicht geklärt; ein Problem im wifi-qcom-Treiber bzw. der Ratensteuerung ist möglich, aber nicht belegt. Hinweis: 6 Mbit/s allein ist bei Leerlauf normal, auffällig ist nur die Kombination mit Paketverlust.