TP16 -- Ursache war NICHT das erwartete QUIC-Flap: die beiden
macmini-Connectoren standen auf Exited(0), beide finishedAt auf
derselben Sekunde 2026-07-21T13:00:53, bei korrektem
restart=unless-stopped und http2. Also ein docker stop / compose down.
Fix = docker start. Abnahme: alle drei bf-Tunnel je 2 Connectoren /
8 conns, 36 Anfragen ueber 6 FQDNs beider Tunnel mit 530er=0.
- Datierung korrigiert: degradiert seit 07-21, nicht seit 08-16
(der 08-16 war der Tag der Entdeckung) -- vier Wochen unbemerkt
- Nachweisluecke festgehalten: 1 von 2 Connectoren meldet healthy,
nur die Connector-ANZAHL zeigt die Degradation -> Check nach TP11
- openclaw-Warnung korrigiert: welcher Tunnel einen Hostname bedient,
entscheidet das DNS; kein CNAME zeigt auf die vier toten Tunnel,
n8n zeigt korrekt auf bf-mm. Loeschen bleibt richtig als Hygiene
- Doku-Drift: bf-nas ist live 220c9958, nicht 70d6a4cf
- cf-tunnel-mapping.md Paragraph 15 als As-Built
TP25 -- 5-GHz-Umfeldscan am Manager: je EIN Fremdnetz pro AP, -86 bzw
-89 dBm. Band leer, Bloecke ueberlappungsfrei => beide ueblichen Gruende
fuer 20 MHz treffen nicht zu. Empfehlung: 20/40 behalten; der echte
Ausloeser ist die AP-Zahl (Band A = genau 2x40 MHz, mit zwei APs voll),
dann lautet die Wahl 20 MHz flottenweit gegen DFS akzeptieren.
TP30 -- neues Leak-Ereignis dokumentiert: list_wifi_interfaces gibt alle
Passphrasen im Klartext aus, damit sind fuenf WLAN-PSKs exponiert.
Als Falle aufgenommen. TP17.2-Stub entfernt (Verweise erklaeren den
Merge, ein Wegweiser ist nicht mehr noetig).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph Emsenhuber
da199be925