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.
|