I6: Der HTTP-Task schreibt die 202 erst nach nl_api_handle(); die
Warteschlangennachricht geht aber schon darin raus, und net_task hat die
hoehere Prioritaet (35 gegen 42, im WM-SDK ist die kleinere Zahl hoeher). Er
verdraengt also sofort und reisst das Netz ab, bevor send_all() laeuft. Beim
Wechsel AUS dem WLAN kam die 202 trotzdem an, weil tls_wifi_disconnect()
asynchron arbeitet - ueber den eigenen AP ist tls_wifi_softap_destroy() der
haertere Abriss, und dieser Fall ist ungemessen.
Deshalb beides: rund 250 ms Pause im MSG_STANDALONE-Zweig vor dem Wechsel als
billige Versicherung, und der Fall als offener Punkt in der Abnahmeliste - die
Messung am Geraet bleibt noetig.
I5: s_ap_mdns_done wurde VOR nl_mdns_on_ip_up() gesetzt und merkte damit den
Versuch, nicht den Erfolg. Die Arbeit laeuft asynchron im tcpip-Thread; liefert
pick_netif() dort NULL, weil das AP-Netif noch keine Adresse hat, protokolliert
announce() nur "no usable netif yet" - und niemand versucht es je wieder,
solange der AP steht. mDNS ist laut Spec Pflichtteil, die Lampe waere im
eigenen AP dauerhaft nicht auffindbar.
Neu meldet nl_mdns_service_up() den tatsaechlichen Zustand aus s_service_added,
und der Netz-Task stoesst alle 5 s erneut an, solange die Lampe standalone ist,
der AP steht und der Dienst noch nicht gemeldet ist. s_announce_pending deckt
das Fenster zwischen dem Anstossen und dem Lauf von announce() ab: ohne das
haette die Abfrage beim Wechsel Station -> eigener AP noch den Dienst des alten
Netifs als Erfolg gewertet.
Dazu der netif-Zeiger (%p) aus der mdns-Protokollzeile: waehrend der
Fehlersuche war er wertvoll, in einer Release-Firmware ist er Rauschen.
Namenskuerzel, Nummer und IPv4 unterscheiden Station und eigenen AP bereits
eindeutig, eine Speicheradresse in einem Protokoll, das Nutzer weiterreichen,
hilft niemandem - und die Abnahmeliste zitiert die Zeile ohnehin ohne ihn.
nl_wifi_status() fuellte out->ssid immer aus der Stations-SSID. Eine
Standalone-Lampe mit noch gespeicherten Heimnetzdaten meldete damit
mode: "ap", standalone: true UND den Namen des Heim-WLANs: App und HA zeigten
den falschen Netznamen, und der Heimnetzname stand in einer tokenfrei lesbaren
Antwort. Die Spec verlangt dort den AP-Namen.
Gemeldet wird jetzt im Modus "ap" (eigener AP oder Onboarding-AP) der
WIRKSAME AP-Name: die Daten des laufenden AP, sonst der gewuenschte, sonst der
Hostname. "apsta" bleibt bei der Station - dort ist sie die Hauptsache.
Erwuenschter Nebeneffekt: ein Rueckfall auf andere AP-Daten wird ueber die API
sichtbar, ohne ein neues Feld.
Beruehrt den API-Vertrag, deshalb ein eigener Commit. test/test_api.c ist
nicht betroffen: die Tests fahren ueber den Fake nl_sys_info_t, nl_wifi_status()
selbst gibt es im Hostbau nicht.
C1 (Merge-Blocker): Schaltet jemand den Standalone-Modus ab, waehrend keine
WLAN-Daten gespeichert sind, geht die Zustandsmaschine in den Onboarding-AP -
nl_wifi_sm_open_access() liefert dann true, obwohl der AP noch mit Name und
Passwort des Nutzers steht. Wer das AP-Passwort kennt, koennte system/settings
und system/command ohne Token benutzen: Token setzen, OTA anstossen,
Werksreset. Der Netz-Task reisst den AP in diesem Fall jetzt ausdruecklich ab
und baut ihn mit den Vorgabedaten neu auf - vor execute(ev) und nicht ueber die
Aktionsstruktur, weil execute() start_ap vor stop_ap ausfuehrt. Damit stimmt
auch die README-Zusage wieder, der AP heisse danach "ninlight-<mac4>".
I1: Der zweite Rueckfall nach drei abgelehnten tls_wifi_softap_create() setzte
ueber reset_ap_defaults() auch das Passwort auf das einkompilierte, das in der
README oeffentlich dokumentiert ist - eine Standalone-Lampe stuende dann mit
einem allgemein bekannten Passwort im Funkfeld, und sACN ist unauthentifiziert.
reset_ap_defaults() ist dafuer in reset_ap_identity() (Name und Kanal) und die
vollstaendige Rueckstellung aufgeteilt; der Rueckfall nimmt nur noch die
Identitaet. Kanal und SSID sind ohnehin die plausiblen Gruende, die
Passwortlaenge prueft die API selbst.
I2: destroy_ap() liess s_ap_live_ssid/-pass/-channel stehen. Nach dem Verlassen
des Standalone-Modus trugen diese Puffer weiter die Daten des Nutzers, und der
erste Rueckfallzweig holte sie Minuten spaeter zurueck - die Lampe pendelte
dann im 15-s-Takt zwischen Nutzerdaten und Vorgaben. Neu: forget_ap_live() in
beiden Abschaltwegen (clear_standalone und enabled:false), nicht in
destroy_ap() selbst, weil der Rueckfall auf zuletzt tragende Daten sonst auch
im Neuaufbau-Fall verlorenginge, fuer den er gedacht ist.
I3: s_ap_create_fails wurde nur bei Erfolg genullt und summierte damit ueber
verschiedene Datensaetze - nach einer Korrektur von Kanal 13 auf 6 loeste schon
ein einziger Fehlschlag den Rueckfall aus. Jetzt auch in destroy_ap() und bei
jedem neuen Wunsch aus MSG_STANDALONE.
Kleinigkeiten: nl_app_clear_standalone() wird auf seinen Rueckgabewert geprueft
und ein Schreibfehler protokolliert (sonst steht die Lampe im WLAN und nach dem
Neustart wieder im eigenen AP, ohne jede Spur). enabled:false auf einer Lampe,
die gar nicht standalone war, erzwingt keine Neuverbindung mehr, sondern tut
nichts und antwortet weiter mit 202.
Abnahmeliste: der Gerätebeleg für C1 als offener Punkt.
C1: nl_recovery_try() verglich nichts mit der laufenden Firmware. Vor einer
laufenden Rettungsstation - laut Spec 9 der Normalfall, solange eine Charge
migriert - lud die Lampe bei jedem Boot dasselbe Image erneut und startete neu.
nl_ota_start_recovery() setzt jetzt ein Flag, das nl_fwup_verify_tail() nur im
Recovery-Pfad auswerten lässt: Trägt der Trailer dieselbe Version wie die
laufende Firmware (nl_trailer_version(), bisher ungenutzt), wird das Image
abgelehnt und der Boot läuft normal weiter. Ein absichtliches Neuflashen
derselben Version über die REST-API bleibt möglich. Kein neuer Wert im
last_ota_error-Vokabular (Spec 8.2); unterschieden wird über die Konsole.
C1/I2: boot_ms wurde erst nach nl_recovery_try() gesetzt und der
Power-Cycle-Zähler erst 5 s danach gelöscht - bei erfolgreicher Recovery also
nie. Nach NL_FACTORY_RESET_BOOTS Runden folgte ein Werksreset. boot_ms startet
jetzt am Anfang von app_task (damit gilt wieder das in Spec 3.4/5.5 zugesagte
5-s-Fenster statt faktisch ~8 s), und nl_app_clear_reset_counter() löscht den
Zähler zusätzlich, sobald die Rettungsstation gefunden ist.
I3: tls_sys_auto_mode_run() stößt direkt nach UserMain() einen SDK-eigenen
Verbindungsversuch an; das dabei entstehende NETIF_IP_NET_UP war in
recovery_join_event() nicht vom eigenen Join zu unterscheiden, die Lampe hätte
im falschen Netz geladen. nl_wifi_disable_sdk_auto_connect() schaltet das Flag
ab und kappt eine bestehende Verbindung jetzt am Anfang von nl_recovery_try();
zusätzlich prüft nl_wifi_join_blocking() über tls_wifi_get_current_bss(), dass
die Verbindung wirklich zur erwarteten SSID gehört.
- wm_internal_fls.c: TLS_DBGPRT_ERR ist in diesem Build wegkompiliert, daher
printf() für die fehlgeschlagene s_fls2_lock-Anlage; PATCHES.md korrigiert.
- nl_wifi_w600.c: der SoftAP-Backstop (Zerstören eines unerwarteten SDK-Softap)
lief bisher innerhalb von lock()/unlock() - tls_wifi_softap_destroy() und
clear_softap_param() greifen aber auf SDK-Zustand zu, nicht auf s_sm/die
Credential-Puffer, die s_lock eigentlich schützt. Jetzt wird im Lock nur noch
ein lokales Flag gesetzt, die SDK-Aufrufe laufen danach.
- clear_softap_param() liest TLS_PARAM_ID_WPROTOCOL jetzt aus SRAM (FALSE)
statt Flash (TRUE) - das Schreiben bleibt weiterhin geflasht.
- app_main.c füttert den Watchdog erst, wenn Licht-, Netz- und HTTP-Task
jeweils seit dem letzten Feed einen Fortschritt gemeldet haben. Dafür
bekommen nl_wifi_w600.c (nl_net_beat) und nl_http_server.c (nl_http_beat)
je einen volatile Heartbeat-Zähler; der HTTP-Listen-Socket bekommt ein
SO_RCVTIMEO von 2 s auf accept(), damit er auch ohne Anfragen tickt.
C2: tls_wifi_softap_create() setzt das SOFTAP-Bit (IEEE80211_MODE_AP = 4)
in TLS_PARAM_ID_WPROTOCOL und schreibt es in den Flash; tls_wifi_softap_destroy()
löscht es nie wieder. Solange das Bit gesetzt bleibt, erstellt
sys_net_status_changed() (sdk/Platform/Sys/tls_sys.c:519-525) bei jedem
NETIF_IP_NET_UP über tls_auto_reconnect_softap() erneut den Onboarding-AP
mit den SDK-eigenen (öffentlichen Default-)Parametern - unabhängig vom
Auto-Connect-Flag. Nach jedem Onboarding/Fallback käme der AP
`ninlight-<mac4>` mit dem öffentlichen Default-Passwort bei jedem
Reconnect/Reboot zurück, offen fürs LAN (SDK-NAPT).
Verifiziert in sdk/Platform/Sys/tls_sys.c, sdk/Include/Platform/wm_params.h
und sdk/Platform/Common/Params/wm_param.c:
- TLS_PARAM_ID_WPROTOCOL (10) ist ein u8, TLS_PARAM_IEEE80211_SOFTAP == 4 ==
IEEE80211_MODE_AP (sdk/Include/WiFi/wm_wifi.h).
- tls_param_get()/tls_param_set(id, argv, to_flash) - genau die Signaturen
aus dem Finding.
- tls_param_to_default() (tls_param_load_factory_default() + param_to_flash())
arbeitet ausschließlich auf `struct tls_sys_param` (Wi-Fi/Netzwerk-Konfig);
es liest/schreibt nirgends die MAC-Adresse oder RF-Kalibrierdaten - die
liegen in einer komplett getrennten, efuse-gestützten FT_PARAM_ST-Struktur
in sdk/Platform/Drivers/efuse/wm_efuse.c. tls_param_to_default() ist damit
für den Werksreset sicher.
Fix (nl_wifi_w600.c):
1. clear_softap_param(): liest TLS_PARAM_ID_WPROTOCOL, löscht bei gesetztem
IEEE80211_MODE_AP-Bit und persistiert das (to_flash=TRUE). Aufgerufen in
nl_wifi_start() (vor allem anderen) und nach jedem tls_wifi_softap_destroy().
2. nl_wifi_start(): zerstört einen bereits vom SDK selbst erzeugten SoftAP
(tls_wifi_softap_get_state() != WM_WIFI_DISCONNECTED), bevor unsere eigene
State Machine startet.
3. Backstop im Netzwerk-Task: NETIF_WIFI_SOFTAP_SUCCESS, während die State
Machine sagt, der AP solle unten sein (s_sm.ap_up == false) -> AP wieder
zerstören und Param erneut löschen (geloggt).
4. Werksreset (nl_app_factory_reset, src/app_main.c): setzt zusätzlich
tls_param_to_default() (siehe Verifikation oben) und dokumentiert das
inline.
Nebenbei im selben Treiber erledigt, weil sie denselben Codepfad betreffen:
- M2: connect_station() loggt den Rückgabewert von tls_wifi_connect(), wenn
er nicht WM_SUCCESS ist.
- M3: start_ap() merkt sich einen fehlgeschlagenen tls_wifi_softap_create()
(`s_ap_create_pending`) und wiederholt ihn alle 5 s, solange die State
Machine den AP oben haben will.
Nicht host-testbar (bindet SDK-Header ein); über den Firmware-Build
verifiziert (baut sauber für evk, keine neuen Warnungen).
Michael Sauer