Christoph Emsenhuber 5231f7b69b AP-Pin fuer den Rundgang -- und drei Dinge, die dabei still falsch waren ...

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>

2026-08-22 20:21:55 +02:00

26 KiB

Raw Blame History

View Raw