TIM, GeForce Now e l'ICMP Black Hole

Premessa: la guerra interna

Buongiorno Signori. Eravate probabilmente qui per un writeup su CVE recenti, qualche analisi di cyberwarfare, magari un deep-dive su architetture cloud. E invece siamo qui a parlare di TIM. Non perché voglia farlo — assolutamente no. Ma quando paghi un Gigabit, scarichi a 26 Mbps, e il supporto ti chiude il ticket come «risolto» senza che nessuno abbia fatto un cazzo, a un certo punto apri il text editor.

Questo writeup esiste per tutti coloro che hanno subito una prevaricazione tecnologica da parte di TIM — termine che uso deliberatamente invece di quello che vorrei scrivere, per motivi di diffide. Sto vedendo un sacco di post su Reddit e forum di gaming di gente con packet loss inspiegabile su GeForce Now con TIM FTTH. Questo è il posto giusto. Avvicinatevi. Siamo tanti.

Venerdì 27 Febbraio 2026: l'ignominia si manifesta

Stavo per ultimare la mia sessione su ArcRaiders prima del wipe. Chiunque conosca il gaming sa quanto questo momento sia sacro. E allora, come insegna la legge di Murphy — il principio empirico per cui tutto ciò che può andare storto, andrà storto, nel peggior momento possibile — avviene la magia.

Per chi usa servizi in cloud per il gaming, una perdita di pacchetti così elevata è, in termini aulici, una condizione di esperienza utente notevolmente al di sotto delle aspettative contrattuali. In termini meno aulici: sono uccelli senza zucchero.

La fase di esclusione: non sono io, è lui

Prima di accusare chiunque, ho fatto l'unica cosa sensata: escludere sistematicamente ogni variabile del mio ambiente. Lista completa delle torture inflitte alla mia rete domestica:

• Riavviare il modem
• Riavviare il PC
• Cambiare cavo LAN
• Provare con WiFi
• Cambiare porta sul router
• Provare con l'hotspot del telefono (🔑 questo è il test decisivo)

Ed è qui che avviene la vera magia: sull'hotspot mobile, perdita di pacchetti = 0%. Larghezza di banda nella media mobile, latenza paragonabile alla velocità di risposta di un funzionario pubblico in vacanza — ma zero perdita di pacchetti. Il problema non era nel mio hardware. Era nella rete TIM.

Il supporto Nvidia: un'oasi nel deserto

Ho contattato Nvidia EU per segnalare il problema. Sito Nvidia, assistenza tecnica, chat con operatore. In due minuti ero in contatto con una persona in carne e ossa che chattava con me, non con un bot che mi chiedeva se avessi provato a spegnere e riaccendere. Mi fido (fu una pessima scelta, col senno di poi, ma non per colpa di Nvidia). Dopo alcuni giorni, ho contattato anche Nvidia USA, che ha confermato: zero problemi rilevati lato loro.

Il supporto TIM: benvenuti nell'antro di Angie

Avete presente la chat dove in due minuti entrate in contatto con un operatore umano? Dimenticatela completamente. TIM ha Angie. Angie è un chatbot senza cuore, senza cervello, programmato per non lasciarvi mai arrivare al punto. Ogni risposta apre un menù, ogni menù porta a una soluzione sbagliata, ogni soluzione sbagliata ti riporta all'inizio. È un loop infinito progettato da qualcuno che odia gli esseri umani.

Dopo aver trovato la combinazione esatta di risposte per raggiungere il box di segnalazione libera — nascosto come l'accesso a un dungeon segreto in un JRPG degli anni '90 — ho inviato il problema. Risposta dopo mezz'ora: «Risolto?». Nessuna notifica. Nessuna chiamata. Solo un ticket chiuso unilateralmente da qualcuno che evidentemente non ha fatto nulla.

Ho aperto 5 ticket. Li ho riaperti almeno una decina di volte ciascuno. Risultato ogni volta: «Risolto». Senza che nessuno chiamasse. Senza che nessuno intervenisse. Così ho chiamato io. 54 minuti in attesa. Trasferimento al tecnico. Linea caduta. Riprovato: 24 minuti in attesa. Linea caduta due secondi prima del trasferimento. La rete TIM — quella che stavo segnalando essere rotta — ha eliminato due mie telefonate al supporto di TIM. Applausi.

Il problema è ancora in lavorazione mentre scrivo questo. Non è risolto. Il ticket è ancora aperto — o meglio: è stato chiuso come «risolto» almeno cinque volte, e riaperto altrettante. La situazione attuale è esattamente quella descritta in questo articolo: rete rotta, workaround VPN attivo, TIM silente. Aggiornamenti seguiranno.

Il troubleshooting vero: quando si smette di aspettare TIM

Arrivati a questo punto, con la consapevolezza che TIM non avrebbe risolto nulla da sola, ho deciso di fare quello che si fa quando il supporto non supporta: diagnosticare da soli e raccogliere prove schiaccianti. Di seguito trovate ogni comando, ogni test, e cosa mi ha detto ciascuno di essi.

Step 1 — Identificare interfacce e gateway

Prima di sparare comandi a caso, bisogna capire con cosa si ha a che fare. Il sistema: MacBook Pro su macOS, connesso via USB Ethernet al router TIM AGGPON_2024. Il WiFi era attivo contemporaneamente — primo dettaglio importante.

# Vediamo tutti i servizi di rete disponibili
networksetup -listallnetworkservices

# Identifichiamo le interfacce attive (en0 = WiFi, en6 = USB Ethernet)
ifconfig | grep -E "^(en|utun|lo)"

# Chi è il gateway? (il router TIM)
netstat -rn | grep "^default"

Risultato: gateway 192.168.1.1 (router TIM), interfaccia primaria en6 via USB Ethernet con IP 192.168.1.x, WiFi en0 con IP 192.168.1.y — entrambe attive. Per chiarire le priorità:

# Verifica ordine di priorità dei servizi di rete
networksetup -listnetworkserviceorder

# Risultato:
# 1. USB 10/100/1000 LAN (en6) ← priorità più alta
# 2. Wi-Fi (en0)

Bene. Il traffico passa da Ethernet, come dovrebbe. Il problema non è nell'ordine delle interfacce.

Step 2 — Test ping base: dove il problema si nasconde

Il comando ping è il bisturi base della diagnostica di rete. Manda piccoli pacchetti ICMP a una destinazione e misura quanti tornano indietro e in quanto tempo. Ho testato quattro destinazioni chiave.

# Router locale — il primo hop, sempre testare per primo
ping -c 50 -i 0.2 192.168.1.1

# Google DNS — destinazione pubblica stabile e affidabile
ping -c 50 -i 0.2 8.8.8.8

# Cloudflare — seconda destinazione pubblica per conferma
ping -c 50 -i 0.2 1.1.1.1

# Server GeForce Now EU — la destinazione del problema
ping -c 50 -i 0.2 185.56.218.1

Nessuna perdita. Tutto funziona. Ed è esattamente qui che il problema diventa interessante — e un po' subdolo. Con pacchetti piccoli (ICMP standard, ~64 byte), non c'è perdita. Il bug si nasconde altrove.

Step 3 — Test ad alta frequenza: il jitter si fa vivo

GeForce Now e i servizi di cloud gaming non mandano un pacchetto al secondo — ne mandano decine o centinaia. Per simulare quel carico, ho alzato la frequenza dei ping.

# Frequenza alta: 20 pacchetti al secondo verso Google
ping -c 100 -i 0.05 8.8.8.8

# Frequenza alta verso il server GFN
ping -c 100 -i 0.05 185.56.218.1

Risultati rivelatori: verso Google 1% di perdita a 20 pacchetti/secondo. Verso GFN, nessuna perdita ma jitter abnorme — minimo 50ms, media 101ms, massimo 581ms, dev std 86ms. Qualcosa stava andando storto, ma non abbastanza da essere ovvio. Era ora di tirare fuori il traceroute.

Step 4 — Traceroute: mappare il percorso del problema

Il traceroute è come mettere un GPS su ogni pacchetto che esce dalla tua macchina. Ti dice esattamente da quale nodo a quale nodo viaggia il traffico, e quanto tempo impiega in ogni tratto. Permette di identificare dove la rete inizia a comportarsi male.

# -n: niente DNS reverse lookup (più veloce)
# -q 10: 10 probe per hop (più affidabile statisticamente)
# -w 3: timeout 3 secondi per hop
traceroute -n -q 10 -w 3 185.56.218.1

# Percorso verso i server GeForce Now EU
Hop  1:  192.168.1.1          →  0.8 ms    (router TIM, stabile)
Hop  2:  * * *                →  ICMP bloccato (normale)
Hop  3:  172.17.112.60/64     →  5-8 ms    (rete TIM, stabile)
Hop  4:  172.17.112.90-102    →  6-8 ms    (rete TIM, stabile)
Hop  5:  172.19.184.24-30     →  10 ms     (backbone TIM, stabile)
Hop  6:  172.19.177.10-66     →  9-10 ms   (backbone TIM, stabile)
Hop  7:  195.22.192/205.x     →  9-12 ms   (transit TIM, stabile)
Hop  8:  195.22.192.117/119   →  25-29 ms  (backbone internazionale, stabile)
Hop  9:  185.100.113.154-157  →  26-30 ms  (ingresso rete GFN, stabile)
Hop 10:  185.8.179.45/46      →  28-48 ms  (infrastruttura GFN)
Hop 11:  185.8.179.37/38      →  29-33 ms  (infrastruttura GFN)
Hop 12:  192.168.10.26/70     →  47-59 ms  + 4/10 timeout ← segnale
Hop 13:  185.56.218.1         →  56-79 ms  + picchi 143ms, 218ms ← destinazione

Osservazione critica: il percorso TIM dagli hop 1 a 9 è completamente stabile. Il problema sembra apparire agli hop 12-13 nell'infrastruttura GFN. Ma aspettate — questo è fuorviante. Il jitter agli hop finali non è originato lì. È una conseguenza di qualcosa che accade prima, silenziosamente.

Step 5 — Il colpevole: MTU e il PPPoE di TIM

MTU significa Maximum Transmission Unit: la dimensione massima di un pacchetto che può attraversare un link di rete. Su Ethernet standard è 1500 byte. Ma la fibra TIM usa PPPoE (Point-to-Point Protocol over Ethernet) internamente, che aggiunge 8 byte di overhead. Risultato: il limite reale scende a 1492 byte.

Per verificare questa ipotesi, ho usato il flag -D del ping — che imposta il bit Don't Fragment sul pacchetto. Questo dice alla rete: «non spezzare questo pacchetto, o droppalo». Poi ho variato la dimensione del payload.

# Payload 1400 byte → pacchetto totale 1428 byte (sotto il limite)
ping -c 10 -D -s 1400 185.56.218.1

# Payload 1472 byte → pacchetto totale 1500 byte (al limite Ethernet)
ping -c 10 -D -s 1472 185.56.218.1

Per trovare l'MTU esatto, ho fatto una ricerca binaria — testando dimensioni crescenti fino al punto di rottura.

# Binary search dell'MTU effettivo
for size in 1460 1465 1470 1471 1472; do
    ping -c 5 -W 2000 -D -s $size 185.56.218.1
done

Il path MTU effettivo è 1492 byte. Esattamente il limite standard PPPoE. Confermato. Ma il problema non è che il limite esiste — il problema è come TIM gestisce i pacchetti che lo superano.

La causa root: ICMP Black Hole

Quando un router riceve un pacchetto troppo grande con il bit DF impostato, dovrebbe rispondere al mittente con un messaggio ICMP «Fragmentation Needed» — in pratica: «ehi, il tuo pacchetto è troppo grande, mandamelo più piccolo». Questo meccanismo si chiama Path MTU Discovery (PMTUD) ed è fondamentale per il funzionamento corretto di qualsiasi connessione.

# Comportamento CORRETTO (quello che NON sta succedendo)
NVIDIA invia UDP 1470B → Router TIM → "troppo grande per PPPoE"
Router TIM → ICMP "Fragmentation Needed" → NVIDIA
NVIDIA riduce pacchetti a ≤1464B → tutto funziona ✓

# Comportamento EFFETTIVO (il bug TIM)
NVIDIA invia UDP 1470B → Router TIM → DROP SILENZIOSO 🕳️
NVIDIA non riceve nessun avviso → continua a mandare 1470B
→ loop → 10% packet loss → GFN ingiocabile

Questo si chiama ICMP Black Hole: il router droppa i pacchetti troppo grandi ma non invia il messaggio ICMP «Fragmentation Needed» al mittente. NVIDIA non scopre mai il limite e continua a mandare pacchetti che vengono silenziosamente eliminati.

Soluzioni testate (e cosa non funziona)

Fix Mac-side MTU — non risolve

Prima ipotesi: abbassare l'MTU dell'interfaccia del Mac in modo da non mandare mai pacchetti più grandi di 1464 byte.

# Abbasso l'MTU dell'interfaccia Ethernet
sudo ifconfig en6 mtu 1464

Risultato: non risolve. Il problema è sui pacchetti in arrivo dal server GFN, non in uscita. Il server GFN non conosce il nostro limite MTU (nessuno glielo ha comunicato) e continua a mandare pacchetti grandi che vengono droppati.

Cloudflare WARP — peggiora

# WARP usa MASQUE/QUIC (UDP) — soggetto allo stesso bug MTU
warp-cli connect
ping -c 100 -i 0.05 185.56.218.1
# Risultato: 18-40% packet loss. Peggio di prima.

WARP usa UDP come trasporto. UDP con pacchetti grandi. Lo stesso identico problema. Anzi, peggio: 18-40% di perdita. Ho provato anche a bloccare QUIC per forzare WARP su TCP.

# Blocco QUIC per forzare WARP su HTTP/2 TCP
sudo pfctl -e
echo "block out proto udp to any port 443" | sudo pfctl -f -
warp-cli connect
# Risultato: 20% packet loss, jitter max 627ms. Anche peggio.

# Ripristino sistema
sudo pfctl -f /etc/pf.conf
warp-cli disconnect
sudo ifconfig en6 mtu 1500

Anche in modalità HTTP/2 TCP, WARP non funziona in questa configurazione. Non è la soluzione.

✅ ProtonVPN con WireGuard (TCP) — risolve

ProtonVPN in modalità WireGuard (TCP) risolve il problema perché imposta automaticamente il suo tunnel a MTU 1380 byte — ben sotto il limite PPPoE di 1492. Il TCP si occupa della negoziazione MSS, aggirando completamente l'ICMP Black Hole di TIM.

# Come funziona il tunnel:
# [GFN UDP grandi] → [WireGuard TCP, MTU 1380] → TIM (pacchetti ≤1380B < 1492) → ✓

# Configurazione in ProtonVPN:
# Settings → Protocol → WireGuard (TCP)

# Verifica stato VPN
scutil --nc list

Il verdetto tecnico

Linea contrattuale: Gigabit fiber. Download effettivo senza fix: ~26 Mbps (2.6% del contratto). Download effettivo con ProtonVPN WireGuard TCP: ~900 Mbps.

I fix — perché TIM non lo farà al posto tuo

Comandi di riferimento rapido

# Verifica MTU path verso un host — se 100% loss, il path MTU è inferiore al payload+28
ping -c 5 -W 2000 -D -s 1465 185.56.218.1

# Traceroute completo verso i server GFN
traceroute -n -q 10 -w 3 185.56.218.1

# Speed test da terminale (macOS)
START=$(date +%s%N)
BYTES=$(curl -s -o /dev/null -w "%{size_download}" "https://speed.cloudflare.com/__down?bytes=50000000")
END=$(date +%s%N)
echo "scale=1; $BYTES * 8 / 1000000 / (($END - $START) / 1000000000)" | bc

# Verifica quale interfaccia gestisce il traffico verso GFN
route get 185.56.218.1

# Statistiche errori su entrambe le interfacce (en0 WiFi, en6 USB Ethernet)
netstat -i | grep -E "en0|en6"

# Abbassare MTU lato Mac (workaround parziale — non risolve GFN)
sudo ifconfig en6 mtu 1464

# Ripristinare MTU standard
sudo ifconfig en6 mtu 1500

// Epilogo: «Stay With Me» di Miki Matsubara in sottofondo. Vent'anni di Vodafone nella vecchia casa. Zero problemi. Zero ticket. Zero proposte di tecnici a pagamento per problemi dell'operatore.
// Sapevo che questo momento sarebbe arrivato — l'unica fibra FTTH disponibile nella nuova casa era TIM. Si accetta il proprio destino. Si apre una VPN. Si scrive un post.
// Il ticket è ancora aperto. La VPN è ancora attiva. TIM non si è ancora fatta viva. Buona continuazione.