Christoph Emsenhuber
6cd9db61d5
Zwei Maengel aus dem Rundgang vom 22.8. behoben. 1. STOPP-KNOPF. Die Konsole nannte "⏹ Aufzeichnung stoppen", es gab ihn nicht. Christoph drueckte "Call beendet" und den Not-Aus -- beide schreiben nur Marken -- und die Messung lief weiter, waehrend der Core sein Telefon mit 5 Pings/s bearbeitete. Jetzt legt der Knopf stop.flag ab, und die Warteschleife des Messskripts bricht darauf ab. 2. ZWEITES TELEFON. Der Beobachter las immer schon beide Geraete, hielt die Zahlen aber nur im Speicher fuer die Anzeige. Da das S22 per Automatik immer auf dem GEGEN-AP sitzt, fehlte damit ausgerechnet die Strecke, die die Alltagsabdeckung zeigt -- der Terrassen-Vergleich war nicht zu fuehren. Jetzt: zweiter Ping (walk-ping-iphone.csv) und beide-telefone.csv im 2-s-Takt mit iface + Signal je Geraet. Beim Testen kamen zwei Fehler ans Licht, die den naechsten Lauf gekostet haetten: - `PINGER=$(ping_lauf ...)` blockiert. Die Kommandosubstitution wartet, bis die stdout-Pipe schliesst, und der Hintergrundjob darin haelt sie offen. Das Skript stand in dieser Zeile, der zweite Ping wurde nie gestartet -- und es sah von aussen aus wie ein normal laufender Lauf. Die Funktion laeuft in der aktuellen Shell, also liefert $! danach die richtige PID. - `kill $SAMPLER` traf nur den Wrapper. Dessen Subshell samt SSH-Sitzung wurde dabei verwaist und lief weiter: nach dem Stopp hielt der Core stumm eine Sampler-Sitzung offen. Wer den Vater zuerst killt, verliert den Zugriff auf die Kinder -- jetzt killbaum(), Kinder zuerst. Mitgenommen von der Rotationsliste: tp6-monitor-core.sh und der Ping in tp25-walk-messung.sh laufen jetzt ueber `sshpass -e` statt `-p`. Damit steht das Router-Passwort in keiner Kommandozeile mehr. `pgrep -fl "sshpass -p"` ist leer. Offen bleibt tp25-pin-s22.sh. Abnahme: Lauf gestartet, beide Ziele gepingt (10.40.10.178 + .196), ein Klick auf den Stopp-Knopf, danach kein Prozess und keine SSH-Sitzung mehr uebrig, Pin geloest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
154 lines
7.8 KiB
Markdown
154 lines
7.8 KiB
Markdown
# TP25 — Rundgang 2026-08-22, 22:43–22:56 (Gegen-AP-Messung)
|
||
|
||
**Rohdaten:** [`messdaten/tp25-runde-20260822-2242/`](messdaten/tp25-runde-20260822-2242/) ·
|
||
3 989 Pings (5/s vom Core), 762 Funkproben (1/s am Manager), 29 Raum-/Ereignismarken,
|
||
`manager-log.txt` (Roaming beider Telefone), `ap-map.txt` (eingefrorene AP-Zuordnung).
|
||
|
||
**Aufbau (neu, Christophs Entwurf):** das iPhone roamt frei und zeigt, welchen AP ein normaler
|
||
Client wählt. Das S22 wird automatisch auf den **Gegen-AP** gezwungen. Gemessen wird der Ping
|
||
auf das S22 — also **nicht die Alltagsabdeckung, sondern die Rückfallebene**. Christoph ist
|
||
bewusst „allen Mauern entlang, in die totesten Winkel" gegangen; die Zahlen sind damit
|
||
**Worst-Case je Raum**, nicht Durchschnitt.
|
||
|
||
**Gepinnt / daraus rekonstruiert, welchen AP das iPhone hatte:**
|
||
|
||
| Zeit | S22 gezwungen auf | ⇒ iPhone hatte |
|
||
|---|---|---|
|
||
| 22:43–22:47 (OG) | ap1 | **ap2** |
|
||
| 22:47–Ende (Treppe + UG) | ap2 | **ap1** |
|
||
|
||
**Messgüte:** nur **22 von 784** Funkproben „nicht angemeldet" (2,8 %). Die befürchteten
|
||
Abweisungs-Artefakte des Pins sind praktisch nicht aufgetreten — die Verluste unten sind
|
||
echte Funkschwäche, kein Messfehler. Keine `UNERREICHBAR`-Marke, kein Sampler-Abriss.
|
||
|
||
---
|
||
|
||
## 🔴 Hauptbefund: die KÜCHE ist ein Loch, und zwar für BEIDE APs gleichzeitig
|
||
|
||
Der Dead Spot dieses Projekts galt bisher als die Terrasse. Der ist es nicht mehr — oder
|
||
jedenfalls nicht allein. Zwischen **22:51:20 und 22:52:47** stand Christoph still in der Küche
|
||
(Marke `ARRIVED` 22:51:16), und **beide** Telefone fielen dort gleichzeitig aus, unabhängig
|
||
voneinander gemessen:
|
||
|
||
**S22 auf ap2** — durchgehend *angemeldet*, aber unbrauchbar:
|
||
|
||
| Totzeit | Dauer |
|
||
|---|---|
|
||
| 22:51:20–22:51:30 | 9 s |
|
||
| 22:51:45–22:51:57 | 12 s |
|
||
| **22:52:05–22:52:30** | **24 s** |
|
||
| 22:52:37–22:52:47 | 11 s |
|
||
| (+ 2 kürzere) | 6 s |
|
||
|
||
**57 % Paketverlust** über zwei Minuten, Signal konstant **−79 bis −87 dBm**, dabei
|
||
ununterbrochen zwischen ap2/5 GHz und ap2/2,4 GHz hin- und herspringend.
|
||
🔴 Das ist der Zustand „**verbunden, aber tot**" — kein Verbindungsabbruch, keine Fehlermeldung,
|
||
nichts, was ein Nutzer als Ursache erkennen könnte.
|
||
|
||
**iPhone auf ap1** — im selben Fenster schlicht weg:
|
||
|
||
```
|
||
22:51:37 F2:62:…@cap-wifi3 (ap1/5GHz) disconnected, connection lost, signal strength -76
|
||
22:53:06 F2:62:…@cap-wifi3 (ap1/5GHz) connected, signal strength -65
|
||
```
|
||
|
||
**89 Sekunden vollständig getrennt** — und wieder verbunden erst, als Christoph die Küche
|
||
Richtung Wohnzimmer verlassen hatte.
|
||
|
||
⇒ **In der Küche gibt es keine Rückfallebene.** ap1 wirft das Gerät ab, ap2 hält es bei −85 dBm
|
||
in einem Zustand, in dem mehr als die Hälfte der Pakete verschwinden. Ein Videocall ist dort
|
||
über 24 Sekunden am Stück tot. Das ist schlimmer als alles, was am 08-21 gemessen wurde.
|
||
|
||
---
|
||
|
||
## Terrasse: besser, aber nicht gelöst — und der Beweis fehlt
|
||
|
||
Am 08-21 (vor der Höhenänderung, iPhone frei roamend): **43 % Verlust, längste Lücke 20,4 s**
|
||
bei −72 dBm. Heute:
|
||
|
||
- **ap1 als Rückfallebene:** −79,4 dBm im Schnitt, **12 % Verlust**, längste Lücke 2,4 s —
|
||
und das **nur über 2,4 GHz** (66 von 70 Proben auf `cap-wifi4`; ap1/5 GHz trägt dort nicht).
|
||
- **iPhone auf ap2:** kein einziger Verbindungsabbruch im Log — aber **vier Bandwechsel in
|
||
49 Sekunden** (22:45:42 / 22:46:13 / 22:46:16 / 22:46:31) zwischen ap2/5 GHz und ap2/2,4 GHz,
|
||
bei −64 bis −73 dBm.
|
||
|
||
⚠️ **Was hier NICHT belegt ist:** ob das Anheben von ap2 auf 2,5 m die Terrasse repariert hat.
|
||
Der Ping lief nur auf das S22, und das war dort auf ap1 gezwungen. Für den direkten Vergleich
|
||
mit den 43 % vom 08-21 fehlt die iPhone-Ping-Strecke. **Die Anzeichen sind gut** (kein Abbruch
|
||
statt 43 % Verlust), **ein Beweis ist es nicht.** Nächster Lauf: beide Telefone pingen.
|
||
|
||
Das Band-Ping-Pong (**Fund C**) ist damit auf der Terrasse reproduziert — nach der
|
||
Höhenänderung, mit aktivem 802.11k/v und FT.
|
||
|
||
---
|
||
|
||
## Raumtabelle (S22 = jeweils der GEGEN-AP, Worst-Case-Weg)
|
||
|
||
| Raum | Gegen-AP | Signal ⌀ | Verlust | längste Lücke |
|
||
|---|---|---|---|---|
|
||
| Arbeitszimmer | ap1/5G | −63,9 | 0 % | — |
|
||
| Technik OG | ap1/5G | −69,0 | 9 % | 0,4 s |
|
||
| Arbeitszimmer (Wand) | ap1 | −68,4 | 22 % | 4,2 s |
|
||
| Diele OG | ap1 | −72,5 | 14 % | 2,0 s |
|
||
| **Terrasse** | ap1/2,4G | **−79,4** | 12 % | 2,4 s |
|
||
| Treppe | Übergang | −65,6 | 17 % | 5,2 s |
|
||
| Wohnzimmer | ap2 | −74,3 | 4 % | 0,4 s |
|
||
| Diele UG | ap2 | −72,7 | 9 % | 0,6 s |
|
||
| **Bad** | ap2/2,4G | **−84,0** | 28 % | 1,0 s |
|
||
| **Schlafzimmer** | ap2/2,4G | **−83,4** | 20 % | 1,0 s |
|
||
| Klo | ap2/2,4G | −78,2 | 7 % | 0,6 s |
|
||
| Technik UG | ap2/2,4G | −73,6 | 2 % | 0,2 s |
|
||
| Kinderzimmer | ap2/2,4G | −80,8 | 4 % | 0,4 s |
|
||
| **KÜCHE** | ap2 | **−82,3** | **57 %** | **24,0 s** |
|
||
|
||
*(Der letzte Wohnzimmer-Block, 170 s, ist der Rückweg an den Schreibtisch und von der
|
||
Auswertung als Ruhezustand markiert — nicht als Messpunkt lesen.)*
|
||
|
||
**Muster:** im gesamten UG trägt der Gegen-AP (ap2) **nur noch 2,4 GHz** — 5 GHz kommt aus dem
|
||
OG nicht durch. Bad, Schlafzimmer, Kinderzimmer und Küche liegen bei −80 bis −86 dBm. Die
|
||
Redundanz ist dort also nominell vorhanden und praktisch wertlos.
|
||
|
||
---
|
||
|
||
## Was das für die offenen Punkte heißt
|
||
|
||
**Fund E (`signal-range`-Boden) — Bewertung ändert sich.** Ein Boden steuert klebende Clients
|
||
auf den besseren AP. Das setzt voraus, dass es einen gibt. Die Tabelle sagt: im UG gibt es
|
||
ihn nicht (ap2 liefert dort −80…−86), im OG für die Terrasse ebenfalls nicht. **Fund E hilft
|
||
auf der Treppe und im Übergangsbereich — nicht in den Problemräumen.** Er bleibt richtig,
|
||
aber er ist nicht mehr die Antwort auf den Dead Spot.
|
||
|
||
**Dritter AP — die User-Randbedingung ist jetzt prüfbar.** „Kein neuer AP, solange nicht alles
|
||
aus den vorhandenen rausgeholt ist." Was noch nicht ausgereizt ist: 5 GHz auf 20 MHz (+3 dB,
|
||
steht seit 08-21 offen). Was die Messung zeigt: in der Küche fehlen nicht 3 dB, sondern eher
|
||
15–20. **Ein AP im UG-Bereich Küche/Wohnzimmer würde dort zwei Probleme gleichzeitig lösen**
|
||
(Küchenloch + fehlende Rückfallebene für Bad/Schlafzimmer). Das ist eine Empfehlung, keine
|
||
Entscheidung — und sie steht unter dem Vorbehalt, dass 20 MHz vorher gemessen wird.
|
||
|
||
**Fund F (5:05-Takt IoT-Trennungen)** — von diesem Lauf nicht berührt.
|
||
|
||
---
|
||
|
||
## Zwei Werkzeugmängel, die dieser Lauf aufgedeckt hat — ✅ beide behoben (2026-08-22)
|
||
|
||
1. 🔴 **Es gibt keinen Stopp-Knopf.** Christoph drückte 22:53:26 „📴 Call beendet" und
|
||
„⛔ Last sofort stoppen" — beides schreibt nur Marken (`ABORT_killed=0`, es gab keine
|
||
Lastflüsse). Die Aufzeichnung lief weitere ~2,5 Minuten weiter, bis sie von Hand beendet
|
||
wurde; der Core pingte das Telefon derweil mit 5/s. Der Docstring von
|
||
`tp25-walk-messung.sh` behauptet fälschlich, es gäbe einen Knopf.
|
||
2. 🔴 **Die iPhone-Werte wurden nicht mitgeschrieben.** Der Beobachter der Konsole liest beide
|
||
Telefone, hält die Zahlen aber nur im Speicher für die Anzeige. Nachträglich ließ sich nur
|
||
das *Roaming-Log* am Manager retten (`manager-log.txt`) — Ereignisse, keine Zeitreihe.
|
||
Deshalb fehlt oben der direkte Terrassen-Vergleich.
|
||
|
||
**Behoben.** Die Konsole hat jetzt einen echten `⏹ Aufzeichnung stoppen`, der die Messung
|
||
beendet (`stop.flag`), und es werden **beide** Telefone gepingt (`walk-ping.csv` +
|
||
`walk-ping-iphone.csv`) sowie beide im 2-s-Takt mitgeschrieben (`beide-telefone.csv`).
|
||
Beim Testen fielen dabei zwei weitere Fehler auf, die beide diesen Lauf betroffen hätten:
|
||
`PINGER=$(ping_lauf …)` blockierte (Kommandosubstitution wartet auf die stdout-Pipe, die der
|
||
Hintergrundjob offen hält) — der zweite Ping wäre nie gestartet; und `kill $SAMPLER` traf nur
|
||
den Wrapper, dessen Subshell samt SSH-Sitzung verwaist weiterlief. Jetzt wird der
|
||
Prozessbaum kindzuerst beendet.
|
||
|
||
⇒ **Der nächste Lauf beantwortet die Terrassen-Frage.** Diesmal nicht.
|