TIM, GeForce Now and the ICMP black hole

Preamble: the internal war

Good morning, gentlemen. You were probably here for a CVE writeup, cyberwarfare analysis, maybe a cloud architecture deep-dive. Instead we're here to talk about TIM. Not because I want to — absolutely not. But when you pay for a Gigabit, download at 26 Mbps, and support closes your ticket as 'resolved' without anyone having done a damn thing, at some point you open a text editor.

This writeup exists for everyone who has been on the receiving end of a technological overreach from TIM — a term I deliberately use instead of what I actually want to write, for legal reasons. I'm seeing a lot of posts on Reddit and gaming forums with inexplicable packet loss on GeForce Now with TIM FTTH. This is the right place. Come closer. There are many of us.

Friday, February 27, 2026: the ignominy manifests

I was about to finish my ArcRaiders session before the wipe. Anyone who games knows how sacred this moment is. And so, as Murphy's Law teaches us — the empirical principle that anything that can go wrong will go wrong, at the worst possible moment — the magic happens.

For anyone using cloud gaming services, that level of packet loss is, in elevated terms, a user experience condition notably below contractual expectations. In less elevated terms: it's a thoroughly unpleasant situation.

The exclusion phase: it's not me, it's them

Before accusing anyone, I did the only sensible thing: systematically rule out every variable in my environment. Complete list of torture inflicted on my home network:

• Reboot the modem
• Reboot the PC
• Change LAN cable
• Try WiFi
• Change port on router
• Try with mobile hotspot (🔑 this is the decisive test)

And here the real magic happens: on the mobile hotspot, packet loss = 0%. Bandwidth in the mobile average, latency comparable to a civil servant on vacation — but zero packet loss. The problem was not in my hardware. It was in the TIM network.

Nvidia support: an oasis in the desert

I contacted Nvidia EU to report the problem. Nvidia website, technical support, chat with operator. In two minutes I was talking to an actual human being, not a bot asking me if I'd tried turning it off and on again. I trusted them (a poor choice in hindsight, but not Nvidia's fault). After a few days, I also contacted Nvidia USA, who confirmed: zero issues on their end.

TIM support: welcome to Angie's lair

Remember that chat where you reach a human operator in two minutes? Forget it completely. TIM has Angie. Angie is a chatbot without heart, without brain, programmed to never let you reach the point. Every answer opens a menu, every menu leads to a wrong solution, every wrong solution brings you back to the start. It's an infinite loop designed by someone who hates human beings.

After finding the exact combination of answers to reach the free-text report box — hidden like the entrance to a secret dungeon in a '90s JRPG — I submitted the problem. Response half an hour later: 'Resolved?'. No notification. No phone call. Just a ticket unilaterally closed by someone who clearly did nothing.

I opened 5 tickets. Reopened each at least ten times. Result every time: 'Resolved'. Without anyone calling. Without anyone intervening. So I called myself. 54 minutes on hold. Transfer to technician. Line dropped. Tried again: 24 minutes on hold. Line dropped two seconds before the transfer. The TIM network — the one I was reporting as broken — dropped two of my calls to TIM support. Applause.

The problem is still being worked on as I write this. It's not resolved. The ticket is still open. Or rather: it's been closed as 'resolved' at least five times, and reopened at least five times. The current situation is exactly what's described in this article: broken network, VPN workaround active, TIM silent. This article is a work in progress in the most literal sense of the term.

The real troubleshooting: when you stop waiting for TIM

At this point, knowing TIM would not fix anything on its own, I decided to do what you do when support doesn't support: self-diagnose and gather overwhelming evidence. Below you'll find every command, every test, and what each one told me.

Step 1 — Identify interfaces and gateway

Before shooting commands at random, you need to understand what you're dealing with. The system was a MacBook Pro on macOS, connected via USB Ethernet to the TIM AGGPON_2024 router. WiFi was active at the same time — first important detail to keep in mind.

# List all available network services
networksetup -listallnetworkservices

# Identify active interfaces (en0 = WiFi, en6 = USB Ethernet)
ifconfig | grep -E "^(en|utun|lo)"

# Who is the gateway? (the TIM router)
netstat -rn | grep "^default"

Result: gateway 192.168.1.1 (TIM router), primary interface en6 via USB Ethernet with IP 192.168.1.x, WiFi en0 with IP 192.168.1.y — both active. To clarify priorities:

# Check network service priority order
networksetup -listnetworkserviceorder

# Result:
# 1. USB 10/100/1000 LAN (en6) ← highest priority
# 2. Wi-Fi (en0)

Good. Traffic goes through Ethernet, as expected. The problem is not in the interface order.

Step 2 — Basic ping test: where the problem hides

The ping command is the basic scalpel of network diagnostics. It sends small ICMP packets to a destination and measures how many come back and how long it takes. I tested four key destinations.

# Local router — the first hop, always test first
ping -c 50 -i 0.2 192.168.1.1

# Google DNS — stable and reliable public destination
ping -c 50 -i 0.2 8.8.8.8

# Cloudflare — second public destination for confirmation
ping -c 50 -i 0.2 1.1.1.1

# GeForce Now EU server — the problem destination
ping -c 50 -i 0.2 185.56.218.1

No loss. Everything works. And this is exactly where the problem gets interesting — and a bit insidious. With small packets (standard ICMP, ~64 bytes), there's no visible loss. The bug hides elsewhere.

Step 3 — High frequency test: jitter shows up

GeForce Now and cloud gaming services don't send one packet per second — they send dozens or hundreds per second. To simulate that load, I increased the ping frequency.

# High frequency: 20 packets per second toward Google
ping -c 100 -i 0.05 8.8.8.8

# High frequency toward the GFN server
ping -c 100 -i 0.05 185.56.218.1

Revealing results: toward Google, 1% loss at 20 packets per second. Toward GFN, no loss but abnormal jitter — minimum 50ms, average 101ms, maximum 581ms, standard deviation 86ms. Something was going wrong, but not enough to be obvious. Time to bring out traceroute.

Step 4 — Traceroute: mapping the problem's path

Traceroute is like putting a GPS on every packet that leaves your machine. It tells you exactly which node to which node your traffic travels, and how long each segment takes. It lets you identify where the network starts misbehaving.

# -n: no reverse DNS lookup (faster)
# -q 10: 10 probes per hop (more statistically reliable)
# -w 3: 3-second timeout per hop
traceroute -n -q 10 -w 3 185.56.218.1

# Path to GeForce Now EU servers
Hop  1:  192.168.1.1          →  0.8 ms    (TIM router, stable)
Hop  2:  * * *                →  ICMP blocked (normal)
Hop  3:  172.17.112.60/64     →  5-8 ms    (TIM network, stable)
Hop  4:  172.17.112.90-102    →  6-8 ms    (TIM network, stable)
Hop  5:  172.19.184.24-30     →  10 ms     (TIM backbone, stable)
Hop  6:  172.19.177.10-66     →  9-10 ms   (TIM backbone, stable)
Hop  7:  195.22.192/205.x     →  9-12 ms   (TIM transit, stable)
Hop  8:  195.22.192.117/119   →  25-29 ms  (international backbone, stable)
Hop  9:  185.100.113.154-157  →  26-30 ms  (GFN network ingress, stable)
Hop 10:  185.8.179.45/46      →  28-48 ms  (GFN infrastructure)
Hop 11:  185.8.179.37/38      →  29-33 ms  (GFN infrastructure)
Hop 12:  192.168.10.26/70     →  47-59 ms  + 4/10 timeout ← signal
Hop 13:  185.56.218.1         →  56-79 ms  + spikes 143ms, 218ms ← destination

Critical observation: the TIM path from hops 1 to 9 is completely stable. The problem seems to appear at hops 12-13 in the GFN infrastructure. But wait — this is misleading. The jitter at the final hops is not originating there. It's a consequence of something happening earlier, silently.

Step 5 — The culprit: MTU and TIM's PPPoE

MTU stands for Maximum Transmission Unit: the maximum size of a packet that can traverse a network link. On standard Ethernet it's 1500 bytes. But TIM fiber uses PPPoE (Point-to-Point Protocol over Ethernet) internally, which adds 8 bytes of overhead. Result: the real limit drops to 1492 bytes.

To test this hypothesis, I used ping's -D flag — which sets the Don't Fragment bit on the packet. This tells the network: 'don't fragment this packet, or drop it'. Then I varied the payload size.

# Payload 1400 bytes → total packet 1428 bytes (below limit)
ping -c 10 -D -s 1400 185.56.218.1

# Payload 1472 bytes → total packet 1500 bytes (at Ethernet limit)
ping -c 10 -D -s 1472 185.56.218.1

To find the exact MTU, I did a binary search — testing increasing sizes until finding the exact breaking point.

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

The effective path MTU is 1492 bytes. Exactly the standard PPPoE limit. Confirmed. But the problem is not that the limit exists — the problem is how TIM handles packets that exceed it.

Root cause: ICMP Black Hole

When a router receives an oversized packet with the DF (Don't Fragment) bit set, it should reply to the sender with an ICMP 'Fragmentation Needed' message — essentially: 'hey, your packet is too big, send it smaller'. This mechanism is called Path MTU Discovery (PMTUD) and is fundamental for any connection to work correctly.

# CORRECT behavior (what is NOT happening)
NVIDIA sends UDP 1470B → TIM router → "too large for PPPoE"
TIM router → ICMP "Fragmentation Needed" → NVIDIA
NVIDIA lowers packets to ≤1464B → everything works ✓

# ACTUAL behavior (the TIM bug)
NVIDIA sends UDP 1470B → TIM router → SILENT DROP 🕳️
NVIDIA receives no warning → keeps sending 1470B
→ loop → 10% packet loss → GFN unplayable

This is called an ICMP Black Hole: the router drops oversized packets but never sends the 'Fragmentation Needed' ICMP message to the sender. NVIDIA never discovers the limit and keeps sending packets that are silently discarded.

Tested solutions (and what doesn't work)

Mac-side MTU fix — doesn't resolve

First hypothesis: lower the Mac's interface MTU so it never sends packets larger than 1464 bytes.

# Lower the MTU of the Ethernet interface
sudo ifconfig en6 mtu 1464

Result: doesn't work. The problem is on packets incoming from the GFN server to us, not outbound. The GFN server doesn't know our MTU limit (nobody told it, because TIM doesn't send ICMP) and keeps sending large packets that get dropped.

Cloudflare WARP — makes it worse

# WARP uses MASQUE/QUIC (UDP) — subject to the same MTU bug
warp-cli connect
ping -c 100 -i 0.05 185.56.218.1
# Result: 18-40% packet loss. Worse than before.

WARP uses UDP as transport. UDP with large packets. The exact same problem. Actually worse: 18-40% loss. I also tried blocking QUIC to force WARP onto TCP.

# Block QUIC to force WARP onto HTTP/2 TCP
sudo pfctl -e
echo "block out proto udp to any port 443" | sudo pfctl -f -
warp-cli connect
# Result: 20% packet loss, max jitter 627ms. Even worse.

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

Even in HTTP/2 TCP mode, WARP doesn't work in this configuration. Not the solution.

✅ ProtonVPN with WireGuard (TCP) — works

ProtonVPN in WireGuard (TCP) mode fixes the problem because it automatically sets its tunnel to MTU 1380 bytes — well below the PPPoE limit of 1492. TCP handles segment size negotiation (MSS negotiation), completely bypassing TIM's ICMP Black Hole.

# How the tunnel works:
# [Large GFN UDP] → [WireGuard TCP, MTU 1380] → TIM (packets ≤1380B < 1492) → ✓

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

# Check VPN status
scutil --nc list

The technical verdict

Contracted line: Gigabit fiber. Actual download without fix: ~26 Mbps. Actual download with ProtonVPN WireGuard TCP: ~900 Mbps.

The fixes — because TIM won't do it for you

Quick reference commands

# Check path MTU to a host — if 100% loss, the path MTU is below payload+28
ping -c 5 -W 2000 -D -s 1465 185.56.218.1

# Full traceroute to GFN servers
traceroute -n -q 10 -w 3 185.56.218.1

# Speed test from terminal (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

# Check which interface handles traffic to GFN
route get 185.56.218.1

# Error stats on both interfaces (en0 WiFi, en6 USB Ethernet)
netstat -i | grep -E "en0|en6"

# Lower Mac-side MTU (partial workaround — doesn't fix GFN)
sudo ifconfig en6 mtu 1464

# Restore standard MTU
sudo ifconfig en6 mtu 1500

// Epilogue: «Stay With Me» by Miki Matsubara playing in the background. Twenty years of Vodafone at the old place. Zero issues. Zero tickets. Zero suggestions to pay for a technician for operator network problems.
// I knew this moment would come — the only FTTH fiber available at the new place was TIM. You accept your fate. You open a VPN. You write a post.
// The ticket is still open. The VPN is still active. TIM hasn't called back. Good luck out there.