{"id":12,"date":"2026-05-03T21:09:00","date_gmt":"2026-05-03T21:09:00","guid":{"rendered":"https:\/\/rpi.temporiti.net\/wordpress\/blog\/troubleshooting-connettivita-homelab\/"},"modified":"2026-05-30T14:05:57","modified_gmt":"2026-05-30T12:05:57","slug":"troubleshooting-connettivita-homelab","status":"publish","type":"post","link":"https:\/\/rpi.temporiti.net\/wordpress\/?p=12","title":{"rendered":"Troubleshooting connettivit\u00e0 in un homelab eterogeneo"},"content":{"rendered":"

In un homelab che mescola Raspberry Pi, mini PC con Linux, un Mac, qualche IoT scemo e uno switch managed, prima o poi capita: “un host non risponde pi\u00f9, non capisco perch\u00e9”. E sotto la frustrazione c’\u00e8 quasi sempre la stessa cosa: una catena di ipotesi non verificate. Il modo per uscirne in tempi ragionevoli \u00e8 una checklist mentale che parte dal basso e sale.<\/p>\n

Racconto una sessione di troubleshooting recente e i comandi che uso, ne approfitto per fissare il metodo per la prossima volta.<\/p>\n

L’incidente<\/h2>\n

Un sabato pomeriggio, verso le 16:00, mi accorgo che un Raspberry Pi del homelab (lo chiamo rpi-monitoring<\/code>) non risponde pi\u00f9 al ping dal portatile. Dalle metriche Grafana risulta off dalla rete da circa un’ora. Niente alert sul telefono perch\u00e9 avevo silenziato Telegram nel pomeriggio. Ma il fatto \u00e8 l\u00ec: l’host non c’\u00e8 pi\u00f9.<\/p>\n

Step 1: dove sta il problema?<\/h2>\n

La prima domanda non \u00e8 “perch\u00e9 non risponde”, \u00e8 “da quale layer in gi\u00f9 la cosa funziona”. Vado dal portatile in gi\u00f9:<\/p>\n

\nping -c 4 rpi-monitoring\n<\/code><\/pre>\n
Risposta: Name or service not known<\/code>. Quindi il DNS non risolve. Il primo strato gi\u00e0 rotto. Provo a interrogare direttamente il resolver interno:<\/p>\n
\ndig +short rpi-monitoring @203.0.113.1\n<\/code><\/pre>\n
Risposta vuota. Il DNS interno non ha pi\u00f9 il record. Sospetto un DHCP-DNS che non ha rinnovato la lease. Provo per IP statico, perch\u00e9 ricordo che ha un fallback:<\/p>\n
\nping -c 4 203.0.113.42\n<\/code><\/pre>\n
Anche qui timeout. Il problema non \u00e8 DNS, \u00e8 che proprio non raggiungo l’host in IP.<\/p>\n
Step 2: layer 2 o layer 3?<\/h2>\n
Ipotesi: il device non \u00e8 connesso alla LAN. Lo verifico dallo switch managed (accesso via Tailscale dato che \u00e8 raggiungibile sulla management interface):<\/p>\n
\nssh admin@switch-managed\nshow interfaces ethernet port5 status\n<\/code><\/pre>\n
Port5 down. Cavo non collegato, NIC del device gi\u00f9, o cavo rotto. Vado fisicamente al rack: cavo collegato sia sullo switch che sul Pi, ma spia LAN sul Pi spenta. Tolgo l’alimentatore e lo riattacco. La spia POWER resta spenta. Provo un altro alimentatore: idem. Sospetto SBC morto.<\/p>\n
Step 3: c’\u00e8 alimentazione?<\/h2>\n
Tiro fuori un multimetro economico, misuro la tensione del cavo USB-C dell’alimentatore: 5,15 V, dentro spec. Il problema non \u00e8 l’alimentatore. Provo a infilare la microSD del Pi morto in un altro Raspberry Pi 5 di backup: avvio in 30 secondi, dmesg pulito. Il problema \u00e8 hardware sul Pi originale. Probabilmente il regolatore di tensione lato SBC \u00e8 andato.<\/p>\n
A questo punto la troubleshooting di rete \u00e8 finita: non c’era niente da fare via comandi. Il device \u00e8 hardware-dead, non network-dead. Ma se avessi saltato i primi step e fossi corso a sostituire l’host senza verificare DNS, switch e fisico, avrei potuto perdere un’ora a configurare un Pi nuovo per scoprire poi che lo switch aveva la porta down per un altro motivo.<\/p>\n
Comandi che uso spesso<\/h2>\n
Senza ordine preciso, la cassetta degli attrezzi:<\/p>\n
\nip link show\nip addr show\nip route show\nss -tunlp\narp -an\nping -c 4 -W 2 host\ntraceroute -n host\nmtr -n -c 10 host\ndig +short host @resolver\nnslookup host resolver\nnmap -sn 203.0.113.0\/24\ntcpdump -i eth0 -nn host 203.0.113.42\nethtool eth0\nsudo nft list ruleset\n<\/code><\/pre>\n
Su Mac molti hanno equivalenti con flag diversi (ping<\/code> con -W<\/code> in millisecondi, traceroute<\/code> senza -n<\/code> per default).<\/p>\n
Un caso reale collaterale<\/h2>\n
Stessa settimana, un altro incidente: latenza folle (centinaia di ms) e pacchetti duplicati ogni ping<\/code> verso un host in LAN. Sintomo classico di ARP duplicato su VLAN. arp -an<\/code> dal portatile mostrava due MAC diversi per lo stesso IP. Un Pi vecchio, smesso da mesi e tirato fuori per un test, era stato ricollegato con IP statico identico a uno gi\u00e0 attivo. L’avevo dimenticato. Spegnimento del Pi vecchio, arp -d 203.0.113.42<\/code> per pulire la cache, latenza tornata a valori normali in dieci secondi. Anche quel caso si \u00e8 risolto in cinque minuti perch\u00e9 ho seguito la checklist invece di indovinare.<\/p>\n
Cosa funziona bene<\/h2>\n
Avere strumenti standard (ping, dig, mtr, tcpdump, ip) installati ovunque, su ogni Pi e mini PC. Niente tool esotici, niente script personalizzati. Funzionano dappertutto, e quando arriva il problema in mezzo alla notte non devi ricordarti come si lancia un binario custom.<\/p>\n
Limiti<\/h2>\n
Il troubleshooting di rete su Wi-Fi \u00e8 sempre pi\u00f9 frustrante: client che migrano fra AP, mesh che fanno scelte opache, banda 2.4\/5\/6 GHz che cambia comportamento. Per quello tengo separati i client Wi-Fi dai server, e i server stanno tutti su ethernet. Niente Wi-Fi nei percorsi critici.<\/p>\n
In pratica<\/h2>\n
Il metodo \u00e8 pi\u00f9 importante degli strumenti. Partire dal layer 1 (cavo, alimentazione, link) e salire (layer 2 MAC\/switch, layer 3 IP, layer 4 porte, layer 7 applicazione) evita di girare a vuoto. Quasi tutti i problemi si risolvono nei primi tre layer, e il tempo speso a verificare l’ovvio si recupera ampiamente non andando dietro alle ipotesi sbagliate.<\/p>\n
\n
\n
Immagine generata con ComfyUI Mac M1 \/ RealVisXL V5 Lightning.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
In un homelab che mescola Raspberry Pi, mini PC con Linux, un Mac, qualche IoT scemo e uno switch managed, prima o poi capita: “un host non risponde pi\u00f9, non capisco perch\u00e9”. E sotto la frustrazione c’\u00e8 quasi sempre la stessa cosa: una catena di ipotesi non verificate. Il modo per uscirne in tempi ragionevoli […]<\/p>\n","protected":false},"author":1,"featured_media":182,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-12","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-self-hosting"],"_links":{"self":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/12","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12"}],"version-history":[{"count":10,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":361,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions\/361"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/media\/182"}],"wp:attachment":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}