Unofficial archive. This is a read-only, community-run archive of the Apple Support Community. It is not affiliated with or endorsed by Apple Inc.

iCloud services stall on Türk Telekom fiber due to QUIC packet drops

Problem

On Türk Telekom (TT, AS9121) fiber, iCloud Photos (items not stored on the device), iCloud Drive, Calendar and Contacts hang or time out on iPhone, iPad and Mac. Mobile data, VPN, and IPv6 work fine. Many TT users report the same, and blocking QUIC to Apple at the router is the known community workaround.


Setup: TT fiber, PPPoE (MTU 1492), IPv4 only; TP-Link EX520v router (TT-supplied); macOS 27.0.1.


Cause

  1. iCloud servers send 1500-byte QUIC (UDP 443) packets. TT's PPPoE line carries at most 1492 bytes.
  2. TT's network fragments these packets (1492 + 28 B) instead of returning ICMP "fragmentation needed". QUIC's path-MTU discovery therefore never shrinks the packets.
  3. The fragments carry tiny, reused IPv4 IDs (0, 1, 2…). Network.framework fails to reassemble them (`Failed to reassemble IP ID 0, dropping N frames`) even though they all arrive intact.
  4. QUIC treats this as packet loss, then stalls or closes the connection after 120 s (`PTO limit reached`). It does not fall back to TCP, because the handshake succeeded.


Google and Cloudflare QUIC (~1350 B packets) are never fragmented and work fine on the same line.


Evidence (Mac)

  • QUIC to `*.icloud.com` -> Handshakes succeed, so this is **not** a block
  • 3-min packet capture (Photos/Drive) -> 78% of inbound UDP packets from 17.0.0.0/8 were fragments; all 1931 were 1500 B split into 1492 + 28 B
  • Same capture, IP IDs -> ID 0 used 183x; the same (source, ID) pair repeated within 50 ms 1011x
  • Same capture vs. macOS log -> No loss on the wire, but 16 reassembly failures in the same 3 minutes
  • macOS log, 24 h -> 96 reassembly failures, all from iCloud processes (`cloudd`, `nsurlsessiond`, …)
  • macOS log, ~20 h -> 20–36% of iCloud QUIC handshakes failed


Not proven from the client side: the exact hop that fragments (most likely TT's BNG), and whether Apple sets DF. If Apple does, TT is clearing DF before fragmenting.


Fix needed

  • Apple:
    • Cap QUIC packet size on IPv4, or treat a path-MTU probe that only got through as fragments as a failed probe.
    • Make reassembly robust to reused IDs.
    • Fall back to TCP when an established QUIC connection keeps losing data.
    • Please also raise this with Türk Telekom; iCloud is broken for a large share of its customers.
  • Türk Telekom: return ICMP "fragmentation needed" instead of fragmenting (or support a 1500-byte MTU on PPPoE), and provision IPv6, where routers never fragment packets.


Workaround

On the router, block outbound UDP to 17.0.0.0 – 17.255.255.255, port 443. iCloud switches to TCP within a second. FaceTime, Private Relay (not available in Turkiye), and non-Apple traffic are not affected.


0 replies

There are no replies.