A macOS bug that causes TCP networking to stop working after 49.7 days

Original Article ↗ Hacker News Discussion ↗

A blog post claims that a bug in recent macOS “Tahoe” releases can freeze an internal TCP timer after roughly 49.7 days of uptime, eventually causing new TCP connections to fail until the machine is rebooted. Commenters note this resembles classic uptime-overflow bugs in Windows, Linux, and even aircraft systems, but argue the article is overdramatic, AI-written, and technically imprecise about how the overflow and TIME_WAIT cleanup actually behave. Most see it as a real but niche reliability issue mainly for always-on Macs, mitigated by periodic reboots or sleep, and likely limited to newer macOS versions rather than “every Mac.”

Comparisons to past uptime/overflow bugs

  • Many relate the 49.7-day limit to classic uint32 millisecond overflows (Windows 95, Arduino, Boeing 787’s 51‑day bug, Linux scheduler bugs).
  • General sentiment: this class of time/overflow bugs keeps reappearing despite being well known.

Who is affected / which macOS versions

  • Several users with very long uptimes on older macOS versions (Catalina and earlier) report no issue.
  • Multiple comments note the bug appears introduced in “macOS 26” (Tahoe) based on XNU source blame.
  • This conflicts with the blog’s implication that “every Mac” or much older releases are affected; some call that a clear overstatement.

Observed behavior, reproduction, and diagnostics

  • Reported symptom: new TCP connections eventually fail while existing ones may keep working; reboot fixes it.
  • Some users think they’ve hit this on always‑on Macs (especially minis or laptops that never sleep).
  • Others with >50 days uptime on recent macOS say networking is fine, suggesting it’s workload‑ and sleep‑dependent.
  • Suggested checks:
    • netstat -an | grep TIME_WAIT and watch for TIME_WAIT sockets that never expire.
    • Use sysctl kern.boottime to compute when 49.7 days elapse.

Debate over severity and real‑world impact

  • Some see it as a “ticking time bomb”; others dismiss that as dramatic since a reboot (or perhaps sleep) clears it.
  • Many note typical desktop behavior (short‑lived connections, browser retries) will hide the bug; long‑lived services, tunnels, DB connections are more vulnerable.
  • HN crowd admits they’re more likely than average users to hit long uptimes.

Critiques of the blog post (style and correctness)

  • Multiple comments say the article reads like AI‑generated: verbose, dramatic, slow to reach the point.
  • Several point out technical mistakes in the wraparound explanation; the real behavior around tcp_now, timer wrap, and TIME_WAIT seems subtler and partially misdescribed.
  • Some note Apple has been notified; others question the need for a long, AI‑assisted write‑up instead of a concise bug report.

Testing and design lessons

  • Discussion about designing time‑based code to be testable (injectable clocks, forced early wraparound).
  • Reminder: systems that rely on wraparound should trigger it soon after start in tests to catch bugs early.