TP25 — Rundgang 2026-08-22, 22:43–22:56 (Gegen-AP-Messung)

Rohdaten: 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)

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

7.8 KiB Raw Blame History Unescape Escape