Beim Bauen der Gegen-AP-Automatik fiel auf, dass die feste AP-Tabelle in
server.py und tp25-gehweg-auswertung.py nicht zum Live-Zustand passt: heute
sind cap-wifi1/2 = ap2 und cap-wifi3/4 = ap1. Der Manager vergibt die Nummern
dynamisch beim Anmelden der CAPs; ap1 hat sich beim Rueckbau auf ether15 neu
angemeldet.
Der erste Schluss daraus war voreilig ("die alten Auswertungen sind
falsch beschriftet"). Die Gegenprobe widerlegt ihn: mit der HEUTIGEN Karte
haette Technik OG am 08-21 von ap1 mit -43 dBm versorgt worden sein -- in dem
Raum, in dem ap2 steht. Die alte Tabelle war zu ihrer Zeit also richtig und
ist erst durch das Umstecken falsch geworden.
Konsequenz, und das ist der eigentliche Fix: eine live nachgeschlagene Karte
auf alte Daten anzuwenden ist nicht die Loesung, sondern derselbe Fehler mit
umgekehrtem Vorzeichen. Die Zuordnung gehoert zum Messzeitpunkt.
- tp25-walk-messung.sh friert sie als ap-map.txt im Laufverzeichnis ein.
- tp25-gehweg-auswertung.py nimmt ausschliesslich diese Datei. Fehlt sie
(alle Laeufe vor heute), bleiben die rohen cap-wifiN stehen, mit lauter
Warnung -- unbeschriftet ist ehrlicher als falsch beschriftet.
teilprojekte.md: TP25 um den Werkzeug-Fund, den neuen Messaufbau (eine Runde
statt zwei) und den Pausenstand ergaenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP25: das S22 laesst sich jetzt per access-list am Manager auf EINEN AP
festnageln (docs/tp25-pin-s22.sh, Umschalter in der Klick-Konsole). Damit
werden Einzel-AP-Abdeckungskarten messbar, statt dass der Client mitten im
Weg wechselt. Gepinnt wird der Standort, nicht das Band -- Band-Ping-Pong
(Fund C) bleibt damit ein echter Befund und wird nicht wegkonfiguriert.
Beim Bauen fielen drei Fehler auf, die alle dieselbe Form haben: eine
Konstante, die einmal richtig war.
1. Die AP-Zuordnung war VERTAUSCHT. server.py und tp25-gehweg-auswertung.py
fuehren cap-wifi1/2 als ap1 -- live ist es ap2 (belegt ueber cap=,
configuration= und Kanal). Baender stimmten, Identitaet nicht. Die
cap-wifiN-Nummern vergibt der Manager dynamisch in der Anmeldereihenfolge
der CAPs, jede feste Tabelle dazu wartet auf den naechsten AP-Reboot.
server.py liest sie jetzt vom Geraet; die Auswertung ist NOCH NICHT
angefasst -- offen ist, ob die Funde vom 08-21 mit vertauschten AP-Namen
notiert sind.
2. Das Laufverzeichnis war beim Serverstart eingefroren. Die Konsole laeuft
als Dauer-Preview, der Messlauf legt spaeter ein neues Verzeichnis an --
Marker waeren in den Lauf von gestern gewandert, waehrend der Sampler ins
neue schreibt. tp25-walk-messung.sh hinterlaesst jetzt einen Zeiger.
3. Das Startbanner nannte eine hartkodierte IP (10.40.10.183 = MacBook Air).
Auf dem Mac mini ist es 10.40.10.82, und genau die falsche Adresse ging
ans Telefon: "geht nicht" bei einem Server, der sauber auf 0.0.0.0 lauschte.
Es werden jetzt die real gefundenen Interface-Adressen gedruckt.
Ausserdem, aus dem Test heraus:
- Ein vom Pin ABGEWIESENER Verbindungsversuch ist in den Ping-Daten nicht von
einem Funkloch zu unterscheiden, und der Manager protokolliert ihn auf
info-Ebene nicht. Android quittiert ihn mit "Verbindung fehlgeschlagen" und
waehlt das Netz ab -- danach misst der Rest des Rundgangs Stille. Die Konsole
schlaegt deshalb mit Vollbanner, Ton und Vibration Alarm, sobald das gepinnte
Geraet nirgends haengt.
- Die Konsole laeuft diesmal auf dem S22 selbst, also auf genau dem Geraet, das
der Pin gleich vom WLAN wirft. Die Anweisung zum Wiederverbinden erscheint
deshalb clientseitig VOR dem Abbruch.
- ThreadingHTTPServer: der Pin braucht ~8 s ueber SSH und haette sonst die
ganze Seite blockiert, Not-Aus inklusive.
Governance: /interface wifi access-list steht unter KEINER ComplianceRule --
der Change erzeugt keinen Drift und laesst sich nicht als Transaktion fuehren.
Fuer eine Messung vertretbar; relevant wird es, wenn Fund E (signal-range)
dauerhaft dort landet.
teilprojekte.md: die beiden Hinweise auf die offene Transaktion
TEST-ether3-trunk-ap1-sideboard nachgezogen -- sie ist seit 08-22
zurueckgerollt, crs326-core ist transaktionsfrei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pingt der messende Laptop das Telefon an, laeuft der Weg ueber zwei
Funkstrecken -- Laptop -> AP -> Core -> AP -> Telefon. Fehlt dann ein Paket, ist
nicht entscheidbar, welches der beiden Geraete weg war, und genau diese
Trennschaerfe ist der ganze Zweck der Messung. Vom Core aus ist die Strecke bis
zum AP durchgehend Kabel.
Ausloeser war unfreiwillig: das MacBook ist mitten in einem Lauf vom Dock ans
WLAN gewechselt und hat dabei die IP gewechselt -- die Konsole war ploetzlich
nicht mehr erreichbar, und der Ping haette ab da zwei Funkstrecken gemessen.
Das Ping-Protokoll ist jetzt eine CSV (ts_local,seq,ms; leeres ms = Verlust), die
Auswertung liest beide Formate, damit die Laeufe von gestern lesbar bleiben.
RouterOS-Dauern kommen als "3ms441us" oder "529us" und werden entsprechend
geparst.
Eine Falle steckt im Skript-Kommentar: tr puffert blockweise, sobald die Ausgabe
in eine Pipe geht -- die ersten ~130 Zeilen haengen im Puffer und die Datei
bleibt scheinbar leer. Das \r kommt deshalb im Shell-Loop weg, nicht per tr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Sampler-Daten zeigen bei jedem AP-/Bandwechsel ~4 s ohne Durchsatz, koennen
das aber nicht beweisen: nach einer Neuanmeldung starten die Zaehler der
Registration-Table ohnehin bei null. tp25-walk-messung.sh trennt beides, indem es
mit 5 Pings/s AUF das Telefon zielt -- Paketverlust ist echte Funkstille, kein
Verlust heisst, die 4 Sekunden waren Buchhaltung.
Laeuft ohne Call und ohne Last: Core-Sampler im 1-s-Takt plus der Ping, dazu eine
Anleitung auf der Klick-Konsole (Gehen/Stehen als Marker). Ein vorheriger Lauf
wird beiseitegelegt statt ueberschrieben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
