Dicken/LaunchPad
1
0
Fork 0
generated from Dicken/dickendock
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Dicken
2026-07-25 13:04:33 +02:00
parent 6457475e26
commit d4ff497c8c
2 changed files with 19 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
apps/backend/src/scanner/networkScanner.ts
View File

@@ -116,7 +116,17 @@ export async function scanDeviceServices(
// überfordern und dabei ausgerechnet den einen tatsächlich offenen Port // überfordern und dabei ausgerechnet den einen tatsächlich offenen Port
// verpassen - das führte zu falschen "nicht mehr gefunden"-Meldungen, // verpassen - das führte zu falschen "nicht mehr gefunden"-Meldungen,
// obwohl sich am Gerät nichts geändert hatte. // 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( const retryResults = await Promise.all(
missedPriorityPorts.map(async (port) => ({ port, open: await isPortOpen(device.ip, port, 1500) })) missedPriorityPorts.map(async (port) => ({ port, open: await isPortOpen(device.ip, port, 1500) }))
); );

16
apps/backend/src/scanner/ports.ts
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 * prüfen wäre bei 65535 Ports zu viel gleichzeitig offener Sockets; komplett
* nacheinander wäre selbst bei schnellen RSTs zu langsam. * nacheinander wäre selbst bei schnellen RSTs zu langsam.
* *
* Timeout bewusst knapp (300ms): im lokalen Netz (derselbe Subnetz-Bereich) * Timeout bewusst knapp, aber nicht zu knapp (500ms): im lokalen Netz
* liegt die Round-Trip-Zeit normalerweise im niedrigen einstelligen * (derselbe Subnetz-Bereich) liegt die Round-Trip-Zeit normalerweise im
* Millisekundenbereich - 300ms ist selbst dafür noch großzügig bemessen. * niedrigen einstelligen Millisekundenbereich, ABER per WLAN angebundene
* Der vorherige Wert von 600-800ms war für WAN-Verbindungen gedacht, nicht * Geräte (Mesh-Repeater, IoT-Geräte) können spürbar länger brauchen. Ports
* fürs Heimnetz, und hat bei geschlossenen/gefilterten Ports (die den * 80/443 sowie bereits bekannte Dienst-Ports bekommen zusätzlich einen
* vollen Timeout ausschöpfen) über ~131 Batches hinweg spürbar Sekunden * zweiten, noch großzügigeren Versuch (siehe scanDeviceServices), falls
* gekostet. * dieser erste, knappe Durchlauf sie verpasst.
*/ */
export async function scanPortsInBatches( export async function scanPortsInBatches(
host: string, host: string,
ports: number[], ports: number[],
batchSize = 1000, batchSize = 1000,
timeoutMs = 300 timeoutMs = 500
): Promise<number[]> { ): Promise<number[]> {
const open: number[] = []; const open: number[] = [];
for (let i = 0; i < ports.length; i += batchSize) { for (let i = 0; i < ports.length; i += batchSize) {