round43: Timeout wieder etwas grosszuegiger, Ports 80/443 bekommen immer einen zweiten Versuch (behebt verpasste Ports bei WLAN-angebundenen Geraeten wie Mesh-Repeatern)

This commit is contained in:
2026-07-25 13:04:33 +02:00
parent 6457475e26
commit d4ff497c8c
2 changed files with 19 additions and 9 deletions

View File

@@ -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) }))
);

View File

@@ -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) {