Download fails immediately on Apple IPSW (updates.cdn-apple.com) after Add dialog shows Ready #35

Activity

1. nimbold commented on Aug 3, 2026

   

   nimbold

   on Aug 3, 2026

   Owner

   More actions

   Hi,
   I produced the exact steps and mine is downloading without any issue:

   

   Please Follow these steps:

   • Tools > Logs > Clear all and Then Start a new log
   • Start reproducing the problem: Pasting download link, and starting it
   • Wait till you get the error
   • Export logs and share it here so I could track where exactly the error occurs
2. nimbold

   added

   questionFurther information is requestedFurther information is requested

   on Aug 3, 2026
3. aliafshany commented on Aug 5, 2026

   

   aliafshany

   on Aug 5, 2026 – with Grok (by xAI)

   Author

   More actions

   Update / root cause (reproduced)

   This is not specific to the Apple IPSW URL. With Streisand (macOS Network Extension PacketTunnel) enabled, downloads fail immediately after the Add dialog shows Ready.

   Failure mode

   Step	Component	Result
   Add URL	Metadata preflight (reqwest → system getaddrinfo / mDNSResponder)	Ready
   Start download	Bundled aria2 (Async DNS)	Failed immediately

   Exact aria2 error (reproduced against Firelink’s live RPC while Streisand was active):

   aria2 error code 19:
   Name resolution for updates.cdn-apple.com failed: Could not contact DNS servers
   

   The same class of error also hit other hosts under Streisand (e.g. real-debrid: Name resolution for … failed: Could not contact DNS servers). So this is a general DNS-stack issue, not IPSW-specific.

   Environment evidence (macOS)

   • Streisand running as PacketTunnel.appex → traffic default-routed via utun7
   • Unscoped system DNS broken while the tunnel is up:
     • scutil --dns: primary resolver reach: Not Reachable
     • dig updates.cdn-apple.com → connection timed out; no servers could be reached
   • System/app path still works:
     • dscacheutil / mDNSResponder resolves the host
     • curl HEAD/Range to the same IPSW returns 200/206 through the tunnel
   • Firelink proxy mode is none — not an HTTP proxy problem. Streisand is L3 tunnel routing; turning off Firelink’s proxy setting cannot bypass it.

   Why Ready ≠ download

   Different DNS stacks:

   1. Add dialog uses system resolver path → succeeds when mDNSResponder/cache still works.
   2. aria2 reports feature Async DNS and fails with error 19 when it cannot contact DNS servers (unscoped resolvers dead under the PacketTunnel).

   Workarounds (user side)

   1. Disable Streisand (or split-tunnel / direct route) for the download host while transferring large files.
   2. Fix Streisand DNS so unscoped resolvers are reachable (working DNS over the tunnel; IPv4 resolvers such as 1.1.1.1 answered when queried explicitly; tunnel-configured IPv6-only DNS timed out in testing).

   Possible product improvements

   1. Surface aria2 error 19 clearly in the UI (e.g. “DNS resolution failed — check VPN/DNS”), instead of a bare Failed state.
   2. Optional robustness: when Async DNS cannot contact servers, fall back to system getaddrinfo, async-dns=false, or configurable explicit DNS servers for the aria2 sidecar.
   3. Docs note: PacketTunnel VPNs that break unscoped DNS will break aria2-backed downloads even when the browser and Firelink’s Ready check still work.

   Happy to provide more logs or retest a build.
4. aliafshany commented on Aug 5, 2026

   

   aliafshany

   on Aug 5, 2026 – with Grok (by xAI)

   Author

   More actions

   Follow-up: fixed by changing Streisand DNS

   After switching Streisand Settings → DNS to:

   • DoU: 1.1.1.1 (DNS over plain UDP to Cloudflare)

   and restarting the tunnel (as Streisand notes), downloads work again — including the Apple IPSW case.

   Previously the tunnel’s DNS setup left unscoped system resolvers unreachable, so aria2 failed with error 19 (Could not contact DNS servers) while the Add dialog still showed Ready.

   Takeaway for others hitting this: if Firelink fails immediately under a PacketTunnel VPN (Streisand, etc.) with a DNS-related aria2 error, try a working DoU/DoH/DoT resolver in the VPN app (e.g. 1.1.1.1 or 8.8.8.8) and restart the tunnel. That restores DNS for aria2 without changing Firelink proxy settings.

   This doesn’t change the product suggestions above (clearer error 19 UI / more resilient DNS for the aria2 sidecar), but confirms the root cause was tunnel DNS configuration, not the IPSW host itself.
5. nimbold

   added a commit that references this issue on Aug 5, 2026

   fix(aria2): harden per-transfer DNS fallback (issue #35)

   c120222
6. nimbold commented on Aug 5, 2026

   

   nimbold

   on Aug 5, 2026

   Last edited by nimbold

   Owner

   More actions

   Thanks for the log. Confirmed this is a real issue caused by Aria2’s separate asynchronous DNS resolver.

   • Firelink now retries the affected download once using the system resolver, without changing global DNS or VPN settings.
   • The fix applies to normal downloads and Torrents (available in the next release), while preserving proxies, headers, resume state, and lifecycle safety.
   • I added error handling, persistence protection, regression tests, and cross-platform CI smoke checks. The changes are pushed to main in commit c120222.

   It will be included in the next release.
7. nimbold

   added

   bugSomething isn't workingSomething isn't working

   on Aug 5, 2026
8. nimbold commented on Sep 8, 2026

   

   nimbold

   on Sep 8, 2026

   Owner

   More actions

   Please test the new version (1.4.2) and report if the DNS problem is fixed. Thanks!