Christoph Emsenhuber
c9a8256e9f
Auftrag war, den nicht abschaltbaren DTU-AP von ch1 wegzubekommen, indem man den Client per access-list an ap2 bindet. Transaktion TP17.1-dtu-pin-ap2 eroeffnet, fuenf reject-Regeln auf ap1s 2,4-GHz-Interfaces deployt. Der DTU flog um 14:38:48 von ap1 und kam bei ap2 nie an. Nach 2,5 Minuten zurueckgerollt, access-list ist wieder leer. Ursache ist Christophs Verdacht und protokollseitig belegbar: SetConfig.proto kennt channel_select (Feld 9). Der eigene AP des Geraets sendet auf ch1, und ein ESP hat ein Radio -- AP und STA teilen zwingend den Kanal. ap2 laeuft auf ch11, dort kann das Geraet gar nicht assoziieren. Die Sperre hat es also nicht umgeleitet, sondern ausgesperrt. Christophs Wiederverbindungsversuch ueber S-Miles scheiterte mit genau der Meldung, die er von Frequenz-Fehlanpassungen kennt. Damit ist meine Empfehlung "AP-Kanal verschieben, indem man den Client bindet" fuer dieses Geraet widerlegt und im Text durchgestrichen. Sie gilt weiter fuer frei scannende Geraete wie die Shellys. Zwei Merkregeln festgehalten: - Ein reject auf AP A ist keine Umleitung auf AP B, sondern ein Rausschmiss. Ob das Geraet woanders unterkommt, ist seine Entscheidung. Bei fixem Kanal: nirgends. - Vor einem Pin pruefen, ob der Client den Kanal des Ziel-APs ueberhaupt benutzen kann. Der Beleg lag vor: DTU-AP auf 2412, ap2 auf 2462. Signalstaerke ist kein Nachweis fuer Assoziationsfaehigkeit -- meine Abnahme war zu lasch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5 lines
178 B
Plaintext
5 lines
178 B
Plaintext
# Snapshot des Scopes 'wifi-access-list' auf crs326-core, 2026-08-23 (Transaktion TP17.1-dtu-pin-ap2)
|
|
# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
|
|
|
|
|