Christoph Emsenhuber
5231f7b69b
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>
17 lines
426 B
Plaintext
17 lines
426 B
Plaintext
.DS_Store
|
|
.secrets
|
|
|
|
# Python bytecode
|
|
__pycache__/
|
|
*.pyc
|
|
|
|
# NAS-VLAN20-Migration: Compose-Files/Inspects enthalten Live-Secrets → nicht committen
|
|
docs/nas-vlan20/stacks/
|
|
docs/nas-vlan20/inspect_*.json
|
|
|
|
# RouterOS-Config-Exports/Backups enthalten Live-Secrets (WiFi-Passphrasen etc.) → nicht committen
|
|
routeros/state-backups/
|
|
routeros/ap1-wg-hub.privkey
|
|
routeros/tp15-core-cutover-intended.rsc
|
|
docs/tp6-marker/.current-run
|