From e9e701a94d0979a86b9223b3a4cb0fd111565717 Mon Sep 17 00:00:00 2001 From: Kay Date: Thu, 17 Sep 2026 21:45:25 +0200 Subject: [PATCH] =?UTF-8?q?bugs.md:=20Nutzer-gemeldeter=20H=C3=A4nger=20be?= =?UTF-8?q?im=20Anlegen=20eines=20DHCP-Pools?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Neuer Eintrag #11: Nutzer-Meldung + Code-Audit-Befund (plausibler Kandidat: SSHTransport.connect() hat keinen Timeout, jeder erste Schreibvorgang pro Session loest ueber ensureSessionBackup() eine dedizierte SSH-Verbindung aus - haengt die, blockiert die UI unbegrenzt). Noch nicht bestaetigt, Status offen. Co-Authored-By: Claude Sonnet 5 --- bugs.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/bugs.md b/bugs.md index 1688e52..bf8d2ca 100644 --- a/bugs.md +++ b/bugs.md @@ -318,3 +318,39 @@ entfernt. Button) ist nach diesem zweiten Code-Review-Durchgang funktional plausibel, aber noch nie tatsächlich in der App-UI durchgeklickt worden — dafür bräuchte es einen Live-Test durch den Nutzer, da UI-Automatisierung hier nicht verfügbar ist. + +--- + +## 2026-09-17 (Nachtrag 4: Nutzer-gemeldet, live in der App) + +### 11. Hänger beim Anlegen eines DHCP-Pools +**Status:** offen (Nutzer-Meldung, Ursache noch nicht bestätigt — siehe Code-Audit unten) +**Confidence:** mittel (plausibler Root-Cause-Kandidat per Code-Audit gefunden, noch nicht live +reproduziert/bestätigt, da UI-Automatisierung nicht verfügbar ist) + +Nutzer-Meldung: "Hänger beim Anlegen eines DHCP-Pools" — App bleibt beim Anlegen eines +`/ip pool`-Eintrags hängen. Noch keine weiteren Details bekannt (welcher Bereich — Experte-Tab +oder Einrichten-Assistent LAN-Schritt; ob sich die App von selbst erholt oder ein Neustart nötig +ist; ob vorher eine Fehlermeldung erscheint). + +**Code-Audit-Befund, plausibler Kandidat:** `SSHTransport.connect()` (`SSHTransport.swift`) setzt +für den `Citadel.SSHClient.connect(...)`-Aufruf **keinerlei Timeout** — im Gegensatz zu +`RestTransport`, das für jede Anfrage `request.timeoutInterval = 5` explizit setzt. Jeder erste +Schreibvorgang einer Session (egal ob Experte-Tab oder Einrichten-Assistent) löst zuerst +`ensureSessionBackup()` aus, was `BackupService.createBackup(for:)` über eine **dedizierte, neue +SSH-Verbindung** aufruft (`BackupService.swift`, "always over SSH"-Muster). Hängt dieser +`connect()`-Aufruf (z.B. durch einen kurzen Netzwerk-Aussetzer oder einen unter Last +langsam/nicht antwortenden Router — der hAP-lite-Testrouter ist mit MIPS 24Kc/650MHz/1 Kern sehr +schwach, in dieser Session bereits bis 80% CPU-Last beobachtet), gibt es keinen Timeout, der die +App wieder freigibt — `isApplying`/der Ladeindikator bliebe dann unbegrenzt aktiv, exakt das vom +Nutzer beschriebene Bild eines "Hängers" ohne Fehlermeldung. + +Noch nicht bestätigt, ob das tatsächlich die Ursache ist — nur ein durch Code-Lesen gefundener, +plausibler Kandidat, kein reproduzierter Fehler. Gleiche Lücke beträfe auch `ConnectionService. +applyViaSSH`/`flushConnections` (beide nutzen ebenfalls `SSHTransport.connect()` ohne Timeout) und +`UpdateService`/`FactoryResetService`/`NetworkToolsService`, die dieselbe Transport-Klasse nutzen. + +**Fix-Ansatz (noch nicht umgesetzt):** `SSHTransport.connect()` mit einem Timeout umgeben (z.B. +`withThrowingTaskGroup`/`Task.sleep`-Race, ähnlich wie RESTs `timeoutInterval`), damit ein +hängender Verbindungsaufbau nach einigen Sekunden als Fehler zurückkommt statt die UI unbegrenzt +zu blockieren.