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>
Erster Lauf mit der Gegen-AP-Automatik: iPhone frei roamend, S22 automatisch
auf den jeweils anderen AP gezwungen. Gemessen wird damit nicht die
Alltagsabdeckung, sondern die RUECKFALLEBENE. Christoph ist bewusst allen
Waenden entlang in die totesten Winkel gegangen -- Worst Case je Raum.
Messguete: 22 von 784 Funkproben nicht angemeldet (2,8 %). Die befuerchteten
Abweisungs-Artefakte des Pins sind praktisch ausgeblieben, die Verluste sind
echte Funkschwaeche.
HAUPTBEFUND: In der Kueche fallen BEIDE APs gleichzeitig aus, unabhaengig
voneinander belegt.
S22 auf ap2: 57 % Verlust ueber 2 min, laengste Totzeit 24 s, dabei
durchgehend ANGEMELDET bei -79..-87 dBm und staendig
zwischen 5 und 2,4 GHz springend -- "verbunden, aber tot".
iPhone auf ap1: 22:51:37 "disconnected, connection lost" bei -76 dBm,
89 Sekunden komplett weg, wieder da erst beim Verlassen
des Raums.
Es gibt dort also keine Rueckfallebene. Das ist schlimmer als alles vom 08-21.
Terrasse: Anzeichen einer Verbesserung nach dem Anheben von ap2 (kein
Verbindungsabbruch statt 43 % Verlust am 08-21), aber NICHT bewiesen -- der
Ping lief nur auf das S22, und das war dort auf ap1 gezwungen. Belegt ist
dagegen Fund C: vier Bandwechsel in 49 s auf ap2, nach der Hoehenaenderung,
mit aktivem 802.11k/v und FT.
Folge fuer Fund E: ein signal-range-Boden steuert auf den besseren AP -- den
gibt es in den Problemraeumen nicht (ap2 liefert im UG -80..-86). Fund E hilft
auf der Treppe, nicht gegen den Dead Spot. Bleibt richtig, ist aber nicht mehr
die Antwort.
Zwei Werkzeugmaengel, die der Lauf aufdeckte und die noch offen sind:
kein Stopp-Knopf (die Aufzeichnung lief nach dem Ende weiter, der Core pingte
mit 5/s), und die iPhone-Zeitreihe wird nicht mitgeschrieben -- nachtraeglich
liess sich nur das Roaming-Log am Manager sichern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
