Die cap-wifiN-Nummern sind nicht stabil -- und die Karte gehoert zum Messlauf
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>
This commit is contained in:
@@ -1364,6 +1364,41 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
|
||||
> zurückgebaut haben. Der Sticky-Client-Defekt ist damit **platzierungsunabhängig**.
|
||||
> ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach
|
||||
> dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos.
|
||||
> 🔴🔴 **2026-08-22, Werkzeug-Fund mit Rückwirkung auf ALLE bisherigen Messungen: die
|
||||
> `cap-wifiN`-Nummern sind NICHT stabil.** Der Manager vergibt sie dynamisch in der
|
||||
> Reihenfolge, in der sich die CAPs anmelden — nach dem ap1-Rückbau auf `ether15` sind heute
|
||||
> `cap-wifi1/2` = **ap2** und `cap-wifi3/4` = **ap1**, also genau umgekehrt zu der festen
|
||||
> Tabelle, die in `tp6-marker/server.py` und `tp25-gehweg-auswertung.py` stand.
|
||||
> ⚠️ **Daraus folgt NICHT, dass die alten Auswertungen falsch sind** — der erste Verdacht in
|
||||
> diese Richtung war voreilig. Die Gegenprobe spricht dagegen: wendet man die *heutige* Karte
|
||||
> auf die Raumkarte vom 08-21 an, wird **Technik OG von ap1 mit −43 dBm versorgt** — in dem
|
||||
> Raum, in dem **ap2 steht**. Die alte Tabelle war zu ihrer Zeit also plausibel richtig und
|
||||
> ist erst durch das Umstecken falsch geworden.
|
||||
> ⇒ **Die Zuordnung gehört zum Messlauf, nicht zur Auswertungszeit.** `tp25-walk-messung.sh`
|
||||
> friert sie jetzt als `ap-map.txt` im Lauf ein; die Auswertung nimmt ausschließlich diese
|
||||
> Datei und lässt die Namen sonst roh (`cap-wifiN`) — unbeschriftet ist ehrlicher als falsch
|
||||
> beschriftet. **Läufe vor dem 2026-08-22 sind nicht rekonstruierbar**; wer ihre AP-Namen
|
||||
> zitiert, muss sie an der Physik prüfen (der AP im Raum liefert dort das stärkste Signal).
|
||||
>
|
||||
> 🆕 **Messaufbau neu gedacht (Christoph, 2026-08-22) — eine Runde statt zwei.** Das frei
|
||||
> roamende iPhone zeigt ohnehin, welchen AP ein normaler Client wählt; interessant ist der
|
||||
> **andere**. Das S22 wird deshalb per `access-list` automatisch auf den **Gegen-AP** des
|
||||
> iPhones gezwungen (`docs/tp25-pin-s22.sh`, Automatik in der Klick-Konsole auf Port 3031).
|
||||
> Pro Standort fallen so **zwei** Messpunkte an. Ein Doppelton meldet „beide angemeldet,
|
||||
> verschiedene APs" = weitergehen.
|
||||
> 🔴 **Die Falle dabei, live erlebt:** ein vom Pin **abgewiesener** Verbindungsversuch ist in
|
||||
> den Ping-Daten **nicht** von einem Funkloch zu unterscheiden, und der Manager protokolliert
|
||||
> ihn auf `info`-Ebene **gar nicht** (Beleg: zwischen `disconnected, access-list changed` und
|
||||
> dem manuellen Reconnect stehen vier Minuten ohne eine einzige Zeile). Android quittiert die
|
||||
> Abweisung mit „Verbindung fehlgeschlagen" und **wählt das Netz ab** — danach misst der Rest
|
||||
> des Rundgangs Stille. Die Konsole schlägt deshalb mit Ton, Vibration und Vollbanner Alarm,
|
||||
> sobald das gepinnte Gerät nirgends hängt, und schreibt nach 45 s vergeblicher Suche
|
||||
> `UNERREICHBAR=apX` — denn „der Gegen-AP trägt hier nicht" **ist das Messergebnis**.
|
||||
> ⏸️ **Stand bei Sitzungsende 2026-08-22: Rundgang noch nicht gegangen.** Pin gelöst,
|
||||
> Automatik aus, `crs326-core` unverändert (die `access-list` steht unter keiner
|
||||
> ComplianceRule, es gibt also nichts zu committen). Erster Messwert nebenbei: am Arbeitsplatz
|
||||
> iPhone **ap2 −68**, S22 auf ap1 gezwungen **−77…−78**; ohne Pin geht das S22 sofort auf
|
||||
> **ap2/5 GHz −71**.
|
||||
> 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
|
||||
> ✅ **Transaktion `TEST-ether3-trunk-ap1-sideboard` am 2026-08-22 zurückgerollt und geschlossen**
|
||||
> (Scope `bridge-vlan`) — `ether3` ist wieder untagged VLAN40, Compliance zurück auf 92/92.
|
||||
|
||||
@@ -15,6 +15,7 @@ import argparse
|
||||
import csv
|
||||
import os
|
||||
import re
|
||||
import sys
|
||||
import urllib.parse
|
||||
|
||||
|
||||
@@ -23,8 +24,38 @@ def sec(t):
|
||||
return h * 3600 + m * 60 + s
|
||||
|
||||
|
||||
AP = {"cap-wifi1": "ap1/5GHz", "cap-wifi2": "ap1/2,4GHz",
|
||||
"cap-wifi3": "ap2/5GHz", "cap-wifi4": "ap2/2,4GHz"}
|
||||
# 🔴🔴 Hier stand bis 2026-08-22 eine feste Tabelle -- mit VERTAUSCHTEN APs: cap-wifi1/2
|
||||
# sind ap2, nicht ap1 (live belegt ueber cap=, configuration= und Kanal). Die Baender
|
||||
# stimmten, die Identitaet nicht. Der Manager vergibt die cap-wifiN-Nummern DYNAMISCH in
|
||||
# der Reihenfolge, in der sich die CAPs anmelden -- eine Konstante dazu ist nur bis zum
|
||||
# naechsten AP-Reboot richtig und faellt danach still falsch aus.
|
||||
#
|
||||
# ⚠️ OFFEN: ob die Messungen vom 2026-08-21 (Raumkarte, Sideboard-Test) mit vertauschten
|
||||
# AP-Namen ausgewertet wurden, ist NICHT geprueft. Die Rohdaten sind unberuehrt -- es geht
|
||||
# allein um die Beschriftung. Betroffen waere u.a. Fund F ("Schlafzimmer -61 ap1 -> -83
|
||||
# ap2") und damit die Sideboard-Entscheidung. Vor dem Zitieren alter Zahlen klaeren.
|
||||
def ap_karte(run_dir):
|
||||
"""cap-wifiN -> apX/Band, aus der Karte DIESES Messlaufs (ap-map.txt).
|
||||
|
||||
🔴 Ausdruecklich NICHT live nachschlagen. Die Nummern gelten nur fuer den Zeitpunkt der
|
||||
Messung; ein spaeter erzeugtes Mapping auf alte Daten anzuwenden ergibt eine
|
||||
selbstbewusst falsche Antwort. Fehlt die Datei (alle Laeufe vor 2026-08-22), bleiben
|
||||
die rohen cap-wifiN stehen -- unbeschriftet ist ehrlicher als falsch beschriftet.
|
||||
"""
|
||||
pfad = os.path.join(run_dir, "ap-map.txt")
|
||||
if os.path.exists(pfad):
|
||||
with open(pfad) as fh:
|
||||
return dict(z.strip().split("=", 1) for z in fh if "=" in z)
|
||||
print("⚠️ Kein ap-map.txt in diesem Lauf -- AP-Namen bleiben roh (cap-wifiN).\n"
|
||||
" Fuer Laeufe vor 2026-08-22 ist die Zuordnung NICHT rekonstruierbar: sie haengt\n"
|
||||
" daran, in welcher Reihenfolge sich die CAPs damals angemeldet haben.\n"
|
||||
" Anhaltspunkt aus der Physik: der AP im Raum sollte dort das staerkste Signal\n"
|
||||
" liefern (ap2 steht in Technik OG, ap1 haengt an core ether15).",
|
||||
file=sys.stderr)
|
||||
return {}
|
||||
|
||||
|
||||
AP = {}
|
||||
|
||||
|
||||
def ros_ms(v):
|
||||
@@ -40,6 +71,9 @@ def main():
|
||||
ap.add_argument("--dir", required=True)
|
||||
a = ap.parse_args()
|
||||
|
||||
global AP
|
||||
AP = ap_karte(a.dir)
|
||||
|
||||
pings = []
|
||||
csv_path = os.path.join(a.dir, "walk-ping.csv")
|
||||
if os.path.exists(csv_path):
|
||||
|
||||
@@ -34,6 +34,16 @@ mkdir -p "$RUN_DIR"
|
||||
# Auswertung auf, wenn die Raummarken fehlten.
|
||||
printf '%s\n' "$RUN_DIR" > "$HERE/docs/tp6-marker/.current-run"
|
||||
|
||||
# 🔴 Die AP-Zuordnung JETZT einfrieren, im Messlauf. Die cap-wifiN-Nummern vergibt der
|
||||
# Manager dynamisch beim Anmelden der CAPs -- sie aendern sich, sobald ein AP neu
|
||||
# bootet oder umgesteckt wird. Wer sie erst bei der Auswertung nachschlaegt, beschriftet
|
||||
# alte Daten mit einer neuen Wahrheit. Genau das waere am 2026-08-22 beinahe passiert:
|
||||
# die Raumkarte vom 08-21 haette Technik OG dann ap1 zugeschrieben -- dem AP, der nicht
|
||||
# in diesem Raum steht.
|
||||
bash "$HERE/docs/tp25-pin-s22.sh" map > "$RUN_DIR/ap-map.txt" 2>/dev/null \
|
||||
&& echo "AP-Zuordnung eingefroren -> $RUN_DIR/ap-map.txt" \
|
||||
|| echo "⚠️ AP-Zuordnung konnte nicht gelesen werden -- Auswertung bleibt bei cap-wifiN"
|
||||
|
||||
# Frueheren Lauf beiseitelegen, statt ihn zu ueberschreiben.
|
||||
if [[ -f "$RUN_DIR/sampler.csv" ]]; then
|
||||
ARCHIV="$RUN_DIR/archiv-$(date +%H%M%S)"; mkdir -p "$ARCHIV"
|
||||
|
||||
Reference in New Issue
Block a user