Panel installieren¶

Warum ein einziges öffentliches Binary hier unbedenklich ist

Die Firmware enthält keine WLAN-Zugangsdaten, keine Bridge-URL und kein Token. Alles Deployment-Spezifische wird zur Laufzeit gesetzt und im Flash des Panels abgelegt. Genau das macht einen Browser-Installer überhaupt möglich — siehe „Secret-free firmware" in der Firmware-README.

Updates kommen von Ihrer Bridge, nicht von dieser Seite

Sobald das Panel seine Bridge URL kennt, fragt es dort nach neuerer Firmware und meldet sie auf dem eigenen Dashboard als Firmware Update. Daneben gibt es die Schaltfläche Check for Update: Sie fordert die Bridge sofort auf, bei GitHub nachzusehen; das Panel liest die Antwort danach dreimal, damit nicht bis zur nächsten planmäßigen Prüfung gewartet werden muss.

Meist steht das Ergebnis binnen etwa anderthalb Minuten. Es kann bis zu elf Minuten dauern: Die Bridge hält fünf Minuten zwischen zwei GitHub-Aufrufen ein, ein Druck kurz nach einer anderen Prüfung muss diese Frist also erst abwarten — und der Aufruf selbst darf noch einmal fünf Minuten brauchen. Erneutes Drücken startet die Folge von vorn, statt sie zu beschleunigen — wenn nichts erscheint, ist Warten schneller als Drücken.

Wie oft es fragt, hängt davon ab, wie die letzte Prüfung ausging. Solange keine erfolgreich war — falsche Bridge URL, Bridge nicht erreichbar — fragt es jede Minute, damit sich das Korrigieren der Einstellung fast sofort zeigt. Nach der ersten erfolgreichen Prüfung geht es auf alle 30 Minuten herunter und kehrt zum Minutentakt zurück, sobald eine Prüfung fehlschlägt. Was das zusagt und was nicht: Eine verschwundene Bridge fällt erst bei der nächsten planmäßigen Prüfung auf, wenn deren Anfrage in ihr Zeitlimit läuft — also gut eine halbe Stunde später. Ab diesem Moment fragt das Panel aber jede Minute nach und findet die Bridge binnen etwa drei Minuten nach ihrer Rückkehr wieder. Ohne gesetzte Bridge URL prüft es gar nicht. Jede Prüfung ist eine kleine Anfrage an Ihre eigene Bridge und erreicht GitHub nie.

Der Umweg über die Bridge ist keine Vorliebe. Das Panel erreicht diese Seite nicht — und GitHub ebenso wenig, und überhaupt nichts über HTTPS:

E esp-tls-mbedtls: mbedtls_ssl_setup returned -0x7F00
E http_request.update: Failed to fetch manifest

-0x7F00 ist MBEDTLS_ERR_SSL_ALLOC_FAILED. Die TLS-Sitzung lässt sich nicht anlegen — das Panel trägt bereits WLAN, den Bluetooth-Stack, LVGL und sein eigenes Dashboard, und mbedTLS möchte obendrauf rund 32 KB. Das ist eine Speichergrenze, kein Zertifikatsproblem: Ein eingebettetes Root-Zertifikat verschlimmert es, weil der Fehler auftritt, bevor überhaupt ein Zertifikat geprüft wird.

Diesen Teil übernimmt scan-bridge. Sie fragt alle fünf Stunden bei GitHub nach dem neuesten Release, lädt die Firmware, prüft sie gegen die SHA256SUMS des Releases und bietet sie erst danach unter http://<ihre-bridge>:18080/firmware/manifest.json an. Eine Datei, deren Prüfsumme nicht stimmt, wird verworfen; die Bridge liefert weiter das Release aus, das sie bereits hatte. Das Manifest nennt nie einen Build, den die Bridge nicht herausgeben kann.

Danach müssen Sie nichts weiter tun: Der Spiegel ist standardmäßig aktiv. Soll Ihre Bridge nicht mit dem öffentlichen Internet sprechen, setzen Sie in config.toml unter [firmware] den Wert enabled = false und nutzen weiterhin das Upload-Formular.

Was ein Update absichert

Die Integritätsgarantie ist die MD5-Summe aus dem Manifest, und das Panel prüft sie während des Schreibens. Ein abgeschnittener oder veränderter Download wird verworfen, die laufende Firmware bleibt bestehen — ein abgebrochenes Update kann das Panel nicht unbrauchbar machen. Zwischen GitHub und Ihrer Bridge kommen die SHA-256-Prüfsummen als zweite, stärkere Prüfung hinzu, die das Panel selbst nicht leisten kann.

Zwischen Bridge und Panel läuft der Verkehr als reines HTTP in Ihrem eigenen Netz. Wer dort Verkehr umschreiben kann, kann ein gefälschtes Manifest und eine dazu passende Binärdatei ausliefern — die MD5-Prüfung ginge durch. Deshalb meldet das Panel Updates, es installiert aber nie eines von selbst: Das entscheidende Zeitfenster ist der Moment, in dem Sie auf Installieren drücken, nicht jede Prüfung. Die vollständige Begründung steht in ADR 0024 und ADR 0025 im Repository.