From 548d73d84aa319f9890a5d3a2cad013d39db8017 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 14 Sep 2026 20:16:20 +0200 Subject: [PATCH] TP25: ap2-In-situ widerlegt (Terrasse), Hebel-A-Machbarkeitspruefung negativ; TP30 #9 GITEA_ACCESS_TOKEN - Handoff 2026-09-14: iPhone-Flapping auf der Terrasse = 5-GHz-Zellkante (-76..-81) plus client-getriebene Band-Wechsel in der Uberlappungszone -70..-77; vor ap2 (1-2 m) -49..-51 dBm, >2 min stabil => HW-Verdacht (23:02-Befund 2 m/-80) in situ widerlegt, kein Tausch begruendet. - Hebel "Access-List-Band-Boden < -76 auf 5G" nicht sauber ausdrueckbar: kein band-Property, Interface-Scoping bricht am cap-wifiN-Rejoin, SSID-/MAC-Scope trae fen 2,4 GHz mit (Lockout-Risiko). Nicht umgesetzt. - TP30: Posten #9 vorgemerkt -- GITEA_ACCESS_TOKEN am 09-14 ueber einen Fehlerpfad (URL-Konstruktion -> ValueError-Traceback) ins Transkript geraten; sechster Vorfall der Leak-Familie, neue Unterklasse. - Gitea: TP25-Issue #17 Kommentar 217, TP30-Issue #20 Kommentar 218. Co-Authored-By: Claude Fable 5 --- ...doff-20260914-tp25-ap2-insitu-terrassse.md | 111 ++++++++++++++++++ docs/teilprojekte.md | 33 +++++- 2 files changed, 143 insertions(+), 1 deletion(-) create mode 100644 docs/handoff-20260914-tp25-ap2-insitu-terrassse.md diff --git a/docs/handoff-20260914-tp25-ap2-insitu-terrassse.md b/docs/handoff-20260914-tp25-ap2-insitu-terrassse.md new file mode 100644 index 0000000..83a8f84 --- /dev/null +++ b/docs/handoff-20260914-tp25-ap2-insitu-terrassse.md @@ -0,0 +1,111 @@ +# Handoff 2026-09-14 — TP25: ap2-In-situ-Messung (Terrasse), Hebel-A-Machbarkeitsprüfung + +**Anlass:** Christoph beobachtete 19:18 auf der Terrasse springende WLAN-Balken (1→2→3 binnen +Sekunden) und zwei Anruf-Aussetzer; danach Umstellung des Telefons auf 5G-Zellular. Verdacht: +Das Telefon probe die APs ab und falle dabei hinaus. + +**Beteiligte:** iPhone `F2:62:4C:E1:AF:09` (das bekannte Fund-E-Gerät), Manager `crs326-core`. +Alle Reads am Manager; **kein einziger Geräte-Write** in dieser Session. + +## cap-wifi-Karte (verifiziert live 19:22, vor jeder Auswertung gelesen) + +`cap-wifi1` = ap2 5G (5300/ax/Ce/DI, tx-power 18) · `cap-wifi6` = ap2 2,4G (2462, tx-power 15) · +`cap-wifi2` = ap3 5G (5180) · `cap-wifi4` = ap3 2,4G · `cap-wifi3`/`cap-wifi5` = ap1 (5G 5280/2,4G). +⚠️ Das CLAUDE.md sagt „ap1 FUNKSTILL seit 08-30" — **überholt**: seit dem 09-04-Kanalplan-Commit +hat ap1 wieder eine Provisioning-Zeile und dient live (heute 16:51:53 sogar ein Radar-Event auf +5280 mit sauberem Kanalwechsel auf 5260/5280-Liste). Doku-Drift, hier vermerkt. + +## Befund 1 — das Flapping ist echt und überwiegend band-intern an ap2 + +Kollektor-Log 18:53–19:18: **~30 Roams**, fast alle `cap-wifi1 ↔ cap-wifi6` = **ap2 5G ↔ ap2 2,4G** +(derselbe AP), Feldstärke −68…−81 dBm. Drei echte Abwürfe `disconnected, not responding` +(19:01:29, 19:12:10, 19:47:51 — der letzte tötete den Anruf). Ein Ausflug zu ap1-5G (19:35:45, +**−64**) und ap3 (−78…−82). + +## Befund 2 — In-situ vor ap2: Hardware-Verdacht WIDERLEGT + +Christoph stellte sich 1–2 m vor ap2. Registration-Table live (3 Stichproben + Log): + +| Position | Interface | Signal | Verhalten | +|---|---|---|---| +| 1–2 m vor ap2 | cap-wifi1 (5G) | **−49…−51** | **>2 min stabil, 0 Roams** | +| Rückweg (Weg) | cap-wifi1 → cap-wifi6 | −76…−78 | 2 Roams binnen 26 s | +| Terrassenplatz | cap-wifi6 (2,4G) | **−65…−73** | 36 s im 1-s-Takt, 0 Roams, ±4 dB | + +⇒ Der offene TP25-Unterpunkt „**ap2 unterperformt (2 m/−80, 23:02-Befund)**" ist **in situ +widerlegt**: ap2 sendet auf 2 m mit −49…−51 dBm und bleibt dort stabil. Der 23:02-Befund +reproduziert sich nicht — plausibel, weil seitdem der 09-04-Kanalplan (5220→5300/5320, +Band-B-Liste) committed ist; alternativ war die damalige Position/Attribution anders. +**ap2 RF/Antenne/HW: sauber. Kein Hardware-Tausch begründet.** + +## Befund 3 — Ursache-Modell Terrasse: 5-GHz-Zellkante + client-getriebene Band-Aggressivität + +- Terrassenplatz: 5 GHz **−76…−81** (Zellkante), 2,4 GHz **−65…−73** — die ~7 dB sind normale + Bandspreizung plus Wand. Link-Budget, kein Defekt. +- Das iPhone **bleibt**, sobald ein Band klar gewinnt (am Platz: 2,4 GHz, minutenlang ruhig). + Das Thrash passiert ausschließlich in der **Überlappungszone −70…−77**, wo beide Bänder + gleichauf liegen und 5 GHz ständig um die iOS-Aufgabeschwelle (~−75) pendelt. +- Client-Aggressivität als Second Layer: 19:44:21 stand das Telefon bei **−52 auf ap2-5G** und + floh 13 s später auf 2,4 (−77) — dasselbe Muster wie im Archiv-Fund E („Abbruch bei −47"). + Steering-Objekte `st-main`/`st-guest` haben **keine Schwellen** (nur rrm/wnm) — der AP + drängt nichts aktiv per BTM, die Entscheidungen trifft das iPhone. +- Mit `ft=no` (Dauerzustand seit 09-04) ist jeder Roam eine Voll-Reassoziation in Sekundenhöhe + ⇒ genau darin sterben Anrufe. + +## Hebel-A-Machbarkeitsprüfung (Dry-Run, kein Write) + +**Ziel:** 5-GHz-Boden für `dirtyvader-main` (reject unter ~−76), damit das Telefon an der +Zellkante sofort endgültig auf 2,4 GHz committet statt zu thrashen. + +Live + MikroTik-Doku verifiziert: +- `signal-range` wird **kontinuierlich** geprüft (Grace über `allow-signal-out-of-range`, + Default 0s) — der Mechanismus trägt grundsätzlich. +- ABER: `/interface/wifi/access-list` hat **kein `band`-Property**. Band-Scoping nur über + `interface=` möglich — und die `cap-wifiN`-Namen wechseln bei jedem CAP-Rejoin (Gotcha + 2026-08-31): die Regel würde stillschweigend auf ein falsches Radio zeigen (im Worst Case + ein 2,4-Master ⇒ Lockout-Schatten). Alternativen fallen alle durch: + - **Nur SSID scope** (ohne Band): trifft auch 2,4 GHz — Schlafzimmer-Gegenmessung 08-22 + (−84 dBm am Counter-AP) ⇒ Lockout, exakt das 08-22-Gegenargument. + - **Nur MAC scope** (iPhone): trifft beide Bänder — das iPhone saß heute selbst bei −89 auf + 2,4 GHz (19:01) ⇒ WiFi-Verlust in schwachen Räumen. +- **Fazit: Der Band-Boden ist in der aktuellen wifi-qcom-Access-List nicht sauber ausdrückbar. + Nicht umgesetzt; Dry-Run-Preview des Kandidaten gefahren, kein Apply.** + +Kandidat (NICHT angewendet, nur als Referenz wie er *heute* aussehen würde): + +``` +/interface wifi access-list add interface=cap-wifi1 ssid-regexp=dirtyvader-main \ + signal-range=-120..-76 action=reject comment="TP25-hebel-a-5g-boden" +``` +(× cap-wifi1/2/3 — die drei 5G-Master — bricht bei jedem CAP-Rejoin) + +**Verbleibende Hebel:** +1. **`ft=yes` uniform auf `sec-main`** — macht Roams nahtlos ⇒ Anrufe überleben das (verbleibende) + Springen. Bewusste Aufweichung der 09-04-Entscheidung (`ft=no`), Fund-E-Ursache (7.24.1) ist + längst behoben, FT-Flotte uniform. Ein Config-Weg: Template + Compliance + Transaktion. +2. **Deckungsfix (TP25 Variante 3)** — der eigentliche Hebel: ein AP muss an der Terrasse + eindeutig stärker sein als alle anderen. Bemerkenswert: ap1-5G erreichte die Terrasse heute + mit −64 (besser als ap2-5G mit −78) — ap1 sitzt bereits auf der Band-B-Liste 5260/5280. +3. Monitoring: wireless-Logging läuft persistent; das Flapping ist damit künftig rückwirkend + diagnostizierbar. + +## Nachweise + +- Live-Log am Manager: 43 + 18 + 8 Zeilen `wireless,info` zu `F2:62:4C:E1:AF:09`, 18:53–19:56. +- 1-s-Sampling: zwei 18-Sekunden-Loops (`:for` am Manager, Registration-Table), 20:01:44–20:02:26. +- Monitor-Reads: `cap-wifi1` → `5300/ax/Ce/DI tx-power 18`; `cap-wifi6` → `2462/ax tx-power 15`. +- Doku-Verifikation Access-List: help.mikrotik.com/docs/display/ROS/Wifi (signal-range kontinuierlich, + kein band-Property, first-match-wins, kein impliziter Reject). + +## Offen / nächste Schritte + +1. Entscheidung Christoph: `ft=yes` ja/nein (Hebel 1 oben) — ich lege dazu auf Go den + GC-ConfigPlan als Dry-Run vor. +2. Deckungsfix-Terminierung (Variante 3 / ap1-Endausbau) — TP25 bleibt offen. +3. CLAUDE.md-Drift „ap1 FUNKSTILL" beim nächsten CLAUDE.md-Edit korrigieren (nur Vermerk hier, + kein stiller Fix). +4. Gitea-TP25-Issue **#17** hat einen Kommentar mit diesem Befund erhalten. +5. 🔴 **Sicherheitsvorfall dieser Session:** durch einen Env-Parse-Fehler stand der + `GITEA_ACCESS_TOKEN` in einer URL im Traceback — **Token ist als kompromittiert zu + betrachten und zu rotieren** (neues Token erzeugen, `~/.hermes/.env` aktualisieren, altes + widerrufen). Siehe Merkregel-Klasse „Werte nie suchen, um sie zu sehen". \ No newline at end of file diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 4206695..ebf4edf 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1099,7 +1099,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.** - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen). -### TP25 — WLAN-Stabilisierung ▸ ⏳ **FUND E ✅ GESCHLOSSEN 2026-09-02: die Abschlussmessung ist ruhig (4 reauth in 8,6 h, 0 Ausfälle, Verlauf 218→40→4) ⇒ `7.24.1` (TP27) war die Ursache, nicht `ft-over-ds`. Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, kein Geräte-Write** ([Handoff](handoff-20260902-tp25-fund-e-messung.md)) — **offen bleibt nur: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6 +### TP25 — WLAN-Stabilisierung ▸ ⏳ **ap2-UNTERPUNKT ✅ WIDERLEGT 2026-09-14 (In-situ, [Handoff](handoff-20260914-tp25-ap2-insitu-terrassse.md)): ap2 sendet auf 2 m mit −49…−51 dBm, stabil, 0 Roams — Hardware sauber, kein Tausch begründet. Terrasse = 5-GHz-Zellkante (−76…−81 vs. 2,4 GHz −65…−73), Thrash nur in der Band-Überlappungszone −70…−77. Hebel „Access-List-Band-Boden" in der Machbarkeitsprüfung GESCHEITERT (kein `band`-Property, cap-wifiN-Rejoin-Falle) — s. Block unten** — **FUND E ✅ GESCHLOSSEN 2026-09-02: die Abschlussmessung ist ruhig (4 reauth in 8,6 h, 0 Ausfälle, Verlauf 218→40→4) ⇒ `7.24.1` (TP27) war die Ursache, nicht `ft-over-ds`. Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, kein Geräte-Write** ([Handoff](handoff-20260902-tp25-fund-e-messung.md)) · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6 > 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen > 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv: > [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G), @@ -1108,6 +1108,27 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au > Merkregeln.** Wer an TP25 weiterarbeitet, kommt mit diesem Abschnitt aus; wer wissen will > *warum* etwas so entschieden wurde, liest die Langfassung. +**Stand 2026-09-14, 20:05 — ap2-In-situ: Hardware entlastet, Terrasse = 5-GHz-Zellkante, +Band-Boden nicht sauber ausdrückbar** ([Handoff](handoff-20260914-tp25-ap2-insitu-terrassse.md)). +Live-Session auf der Terrasse (Christoph kooperierte physisch — der Test, der am 08-31 „nachts +nicht möglich" war): das Fund-E-iPhone flappte 18:53–19:18 ~30×, fast ausschließlich +**ap2-5G ↔ ap2-2,4G** (−68…−81), mit 3 Abwürfen (2 Call-Aussetzer). Vor ap2 (1–2 m): **−49…−51 dBm, +>2 min stabil, 0 Roams** ⇒ der offene Verdacht „ap2 RF/Antenne/HW" (23:02-Befund, 2 m/−80) ist +**in situ widerlegt** — der 23:02-Wert reproduziert sich seit dem 09-04-Kanalplan (5300/5320, +tx-power 18 live) nicht mehr. Am Terrassenplatz ist **2,4 GHz klar besser** (−65…−73 vs. 5 GHz +−76…−81) und das Telefon dort **ruhig** (36 s im 1-s-Takt, 0 Roams) — es thrasht nur in der +Überlappungszone −70…−77 beider Bänder; zusätzlich client-getrieben (floh 19:44 selbst von −52 +auf 2,4/−77; Steering hat keine Schwellen, der AP drängt nichts). Mit `ft=no` ist jeder Roam ein +spürbarer Voll-Reconnect ⇒ so sterben Anrufe. **Hebel „Access-List-Boden < −76 auf 5G": +Machbarkeitsprüfung negativ** — `/interface/wifi/access-list` hat kein `band`-Property, +Interface-Scoping bricht am cap-wifiN-Rejoin, SSID-/MAC-Scope träfen 2,4 GHz mit (Schlafzimmer +−84 ⇒ Lockout). **Nicht umgesetzt.** Verbleibende Hebel: (1) `ft=yes` uniform auf `sec-main` +(nahtlose Roams — Aufweichung der 09-04-Entscheidung, wartet auf Christophs Go, dann +GC-ConfigPlan als Dry-Run), (2) Deckungsfix Variante 3 (ap1-5G erreichte die Terrasse mit −64). +Randnotizen: ap1 „FUNKSTILL" im CLAUDE.md ist überholt (dient live, Radar-Event 16:51 auf 5280 +sauber abgehandelt); Template-Abschnitt [6c] („Fund E WIEDER OFFEN", Stand 08-30) ist inhaltlich +überholt — beim nächsten Template-Edit mit aktualisieren, kein separater Edit nur für den Kommentar. + **Stand 2026-08-22, 23:30 — die Terrasse ist repariert.** Erster Lauf mit beiden Ping-Strecken ([`tp25-runde-20260822-2330-auswertung.md`](tp25-runde-20260822-2330-auswertung.md)): **43 % Verlust / 20,4 s längste Lücke (08-21) → 9 % / 1,0 s** bei gleichem Gerät und gleicher Rolle. Wirksam war das @@ -1804,6 +1825,7 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört | 6 | **MariaDB `root`** (LXC 302, `10.40.20.23`) | root-DB-Login | 🔴 am 2026-09-01 (TP39) ins Transkript geraten — die `/root/.my.cnf` trug `password ` **ohne `=`**, die Feld-Maskierung ankerte auf `=` und griff nicht | Wert in `/root/.my.cnf` (chmod 600) | `SET PASSWORD` + `.my.cnf` nachziehen; **kein** externer Konsument (Dienste nutzen eigene DB-User) ⇒ billigste Rotation der Liste | | 7 | **`TERPENE_ANDROID_KEYSTORE_PW`** | Terpene-Android-TWA-Signing (`android/android.keystore`, alias `terpene`) | 🔴 am 2026-09-01 (TP41) durch **Regex-Suffix-Loch** (`_PW` nicht abgedeckt) ins Transkript geraten | Wert in `~/.secrets/credentials.env` + Keystore-Datei | **Store-/Key-Passwort** via `keytool -storepasswd`/`-keypasswd` ändern + `credentials.env` nachziehen; Konsument = Android-Build/Play-Signing (**Cross-Projekt blaueblüten**) — den **Key selbst NICHT** neu erzeugen | | 8 | **`N8N_SMTP_PASS`** (Gmail-App-PW für `johnny.claw.0x00@gmail.com`) | SMTP-Versand aus n8n (Portainer-Stack 174 `n8n`, macmini) | 🔴 am 2026-09-01 (n8n-mcp-SSRF-Session) beim Ausgeben des Stack-174-Files ins Transkript geraten — Redaktionsmuster hatte `PASSWORD`, aber **nicht bare `PASS`** → `N8N_SMTP_PASS=` blieb stehen | Wert in Portainer-Stack 174 (`environment`) | **Gmail-App-Passwort widerrufen** (Google-Konto → App-Passwörter) + neues erzeugen, Stack-174-Env nachziehen + redeploy; Konsument = n8n-SMTP-Node(s) | +| 9 | **`GITEA_ACCESS_TOKEN`** (API-Zugang `gitea.emsenhuber.net`) | Session-Tooling (`bin/gitea-tp-sync.py`, Ad-hoc-API-Calls) | 🔴 am 2026-09-14 (TP25-In-situ-Session) **ins Transkript** geraten: Env-Parse-Fehler schob den Token in die URL-Konstruktion, `urllib` warf `ValueError: unknown url type` und druckte ihn im Traceback | Mechanismus zu: Token gehört **nur in den `Authorization`-Header, nie in eine URL** — und der Fehlerpfad, der ihn enthält, darf ihn nicht ausgeben (gleiche Familie wie #1/#5/#6/#7/#8, diesmal Unterklasse „Fehlerausgabe statt Maskierung") | neu anlegen (Gitea → Settings → Applications), `~/.hermes/.env` nachziehen, altes widerrufen; Konsumenten = `gitea-tp-sync.py` + Session-Ad-hoc-Calls | > ✅ **Der Leak-MECHANISMUS hinter #1 ist seit 2026-08-31 zu — der Wert bleibt trotzdem verbrannt.** > Alle sechs Skripte im Repo, die `sshpass -p ` benutzten (`nautobot/gc-transaktion.py` und @@ -1837,6 +1859,15 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört > Mal neu (und falsch) tippt: `sed -E 's/([A-Z0-9_]*(PASS|PASSWORD|PWD|PW|TOKEN|SECRET|KEY|BEARER))=[^[:space:]]*/\1=/g'` > — ankert auf den **Schlüsselnamen inkl. Präfix** und deckt alle bisher gesehenen Suffixe ab. > +> 🔴 **#9 ist der sechste Vorfall derselben Familie, aber eine neue Unterklasse** (SHELLY 08-28, +> Nautobot-Tokens 08-31, MariaDB-root 09-01, Keystore 09-01, SMTP 09-01): diesmal kein +> Maskierungsmuster, sondern ein **Fehlerpfad** — ein Env-Parse-Fehler schob den Token in die +> URL-Konstruktion, und `urllib` druckte ihn im `ValueError: unknown url type`-Traceback. +> **Merkregel: ein Secret gehört in keine Datenstruktur, die eine Exception ausgeben kann** +> (URL-Konstruktion validieren, bevor das Secret hineinwandert; Fehlerpfade dürfen den +> fehlerhaften Wert nicht mitschleppen). Das Redaktions-Snippet oben hilft hier nicht — es +> kann nichts maskieren, was als Fehlermeldung und nicht als Dateiinhalt kommt. +> > ℹ️ **#3 war bis 2026-08-24 TP17.2** und ist jetzt vollständig hier (s. Detailabschnitt unten) — > es benutzt denselben Geräte-Durchgang wie #2, **ein Reboot statt zwei**. #4 gehört sachlich zu > **TP14.4**, das als TP bestehen bleibt (dort steckt das CF-Access-Profil, nicht nur der Token).