Christophs Einwand, und er hat recht: wer in ap2-Zone losgeht und das S22
auf ap2 pinnt, misst dort dasselbe, was das frei roamende iPhone ohnehin
liefert. Der Erkenntnisgewinn liegt beim ANDEREN AP.
Die Konsole liest deshalb beide Telefone mit und zwingt das S22 automatisch
auf den Gegen-AP des iPhones. Pro Standort gibt es damit zwei Messpunkte
statt einem, ohne den Weg zweimal zu gehen. Ein kurzer Doppelton meldet
"beide angemeldet, verschiedene APs" -- das ist das Signal zum Weitergehen.
Drei Zustaende statt zwei, weil zwei hier luegen wuerden:
bereit beide haengen -> Piep, weiter
sucht S22 versucht den Gegen-AP -> stehenbleiben
unerreichbar nach 45 s: der Gegen-AP traegt hier NICHT. Das ist das
Messergebnis, kein Defekt -- Marker UNERREICHBAR=apX, kein
Dauer-Alarm, weitergehen.
Ausserdem:
- Raumkacheln sind zurueck. Sie hingen am TP6-Treiber-Zustand und waren ohne
laufenden Call-Treiber unsichtbar -- ausgerechnet beim Kartieren.
- Die Call-Buttons (Start / Not-Aus fuer die Saettigungs-Flows) erscheinen nur
noch MIT Treiber. Ohne einen haette der Start-Klick nichts gemessen; der
Not-Aus haette nichts zu stoppen gehabt. 🚶/📍 brauchen keinen Treiber und
bleiben immer da.
Zwei Fehler beim Bauen, beide mit Merkwert:
1. `(:while (true) do={...})` -- die Klammern beenden die RouterOS-Sitzung
wortlos. Mit stderr auf DEVNULL sah man nur, dass alle 3 s ein neuer ssh
startet, und sonst nichts. stderr geht jetzt in beobachter.log.
2. `for zeile in proc.stdout` liest blockweise vor: bei einer Zeile alle 2 s
waeren die ersten Daten nach etwa einer Stunde gekommen. iter(readline, "").
Und eine Sicherheitskorrektur: `sshpass -p` schreibt das Router-Passwort in
die Kommandozeile -- sichtbar in ps und in jedem argv-Trace. Beim Debuggen ist
es am 2026-08-22 genau so im Klartext gelandet. Der Beobachter nutzt jetzt
`sshpass -e` (Passwort nur in der Umgebung des Kindprozesses). tp6-monitor-core.sh
und tp25-pin-s22.sh haben dieselbe Schwaeche und sind noch NICHT umgestellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>