From d4ff497c8cb3e24e427850d58bdd8870e40ea5c4 Mon Sep 17 00:00:00 2001
From: Dicken <webmaster@sermerpartydorf.de>
Date: Sat, 25 Jul 2026 13:04:33 +0200
Subject: [PATCH] round43: Timeout wieder etwas grosszuegiger, Ports 80/443
 bekommen immer einen zweiten Versuch (behebt verpasste Ports bei
 WLAN-angebundenen Geraeten wie Mesh-Repeatern)

---
 apps/backend/src/scanner/networkScanner.ts | 12 +++++++++++-
 apps/backend/src/scanner/ports.ts          | 16 ++++++++--------
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/apps/backend/src/scanner/networkScanner.ts b/apps/backend/src/scanner/networkScanner.ts
index 99708ce..51f842a 100644
--- a/apps/backend/src/scanner/networkScanner.ts
+++ b/apps/backend/src/scanner/networkScanner.ts
@@ -116,7 +116,17 @@ export async function scanDeviceServices(
   // überfordern und dabei ausgerechnet den einen tatsächlich offenen Port
   // verpassen - das führte zu falschen "nicht mehr gefunden"-Meldungen,
   // obwohl sich am Gerät nichts geändert hatte.
-  const missedPriorityPorts = priorityPorts.filter((p) => !openPorts.includes(p));
+  // Bereits bekannte Dienst-Ports (priorityPorts) UND immer 80/443 (die
+  // wichtigsten, am meisten erwarteten Web-Ports überhaupt) bekommen einen
+  // zweiten, einzelnen Versuch mit mehr Zeit, falls der erste, stark
+  // parallele Durchlauf sie verpasst hat. Grund: viele gleichzeitige
+  // Verbindungsversuche können schwächere/per WLAN angebundene Geräte (z. B.
+  // ein FritzOS-Mesh-Repeater, Echo-Lautsprecher, Smart-TVs) kurzzeitig
+  // überfordern oder brauchen einfach etwas länger als der knappe
+  // Batch-Timeout - das führte sonst zu falschen "nicht gefunden"-Meldungen
+  // ausgerechnet bei 80/443, obwohl der Dienst da ist.
+  const mustRetryPorts = Array.from(new Set([...priorityPorts, 80, 443]));
+  const missedPriorityPorts = mustRetryPorts.filter((p) => !openPorts.includes(p));
   const retryResults = await Promise.all(
     missedPriorityPorts.map(async (port) => ({ port, open: await isPortOpen(device.ip, port, 1500) }))
   );
diff --git a/apps/backend/src/scanner/ports.ts b/apps/backend/src/scanner/ports.ts
index 690e8b6..3c71afc 100644
--- a/apps/backend/src/scanner/ports.ts
+++ b/apps/backend/src/scanner/ports.ts
@@ -44,19 +44,19 @@ export function isPortOpen(host: string, port: number, timeoutMs = 800): Promise
  * prüfen wäre bei 65535 Ports zu viel gleichzeitig offener Sockets; komplett
  * nacheinander wäre selbst bei schnellen RSTs zu langsam.
  *
- * Timeout bewusst knapp (300ms): im lokalen Netz (derselbe Subnetz-Bereich)
- * liegt die Round-Trip-Zeit normalerweise im niedrigen einstelligen
- * Millisekundenbereich - 300ms ist selbst dafür noch großzügig bemessen.
- * Der vorherige Wert von 600-800ms war für WAN-Verbindungen gedacht, nicht
- * fürs Heimnetz, und hat bei geschlossenen/gefilterten Ports (die den
- * vollen Timeout ausschöpfen) über ~131 Batches hinweg spürbar Sekunden
- * gekostet.
+ * Timeout bewusst knapp, aber nicht zu knapp (500ms): im lokalen Netz
+ * (derselbe Subnetz-Bereich) liegt die Round-Trip-Zeit normalerweise im
+ * niedrigen einstelligen Millisekundenbereich, ABER per WLAN angebundene
+ * Geräte (Mesh-Repeater, IoT-Geräte) können spürbar länger brauchen. Ports
+ * 80/443 sowie bereits bekannte Dienst-Ports bekommen zusätzlich einen
+ * zweiten, noch großzügigeren Versuch (siehe scanDeviceServices), falls
+ * dieser erste, knappe Durchlauf sie verpasst.
  */
 export async function scanPortsInBatches(
   host: string,
   ports: number[],
   batchSize = 1000,
-  timeoutMs = 300
+  timeoutMs = 500
 ): Promise<number[]> {
   const open: number[] = [];
   for (let i = 0; i < ports.length; i += batchSize) {