Ditemukan bug yang menghentikan jaringan TCP di macOS setelah 49,7 hari

• Penghitung timestamp TCP (tcp_now) di macOS mengalami overflow 32-bit sekitar 49,7 hari setelah boot, sehingga jam TCP internal berhenti
• Akibatnya, koneksi dalam status TIME_WAIT tidak kedaluwarsa dan terus menumpuk, sehingga port sementara tidak dilepas
• Seiring waktu, port sementara habis, menyebabkan semua koneksi TCP baru gagal, sementara koneksi yang sudah ada tetap bertahan
• ICMP (ping) tetap berfungsi normal, tetapi seluruh fungsi TCP lumpuh, dan pemulihan tidak mungkin dilakukan selain dengan reboot
• Server macOS, build machine, dan lingkungan CI yang berjalan lama terpapar masalah ini setiap 49 hari 17 jam, sehingga memerlukan reboot berkala sampai ada perbaikan kernel

---

Latar belakang: konsep dasar TCP

• Saat koneksi TCP ditutup, koneksi tidak langsung hilang, melainkan masuk ke status TIME_WAIT, yaitu tahap untuk menangani paket yang terlambat dan memastikan terminasi yang andal
  • Ini bertujuan mencegah paket lama salah ditafsirkan sebagai koneksi baru, serta menangani retransmisi bila ACK terakhir hilang
• Durasi TIME_WAIT didefinisikan sebagai 2 × MSL (Maximum Segment Lifetime), dan di macOS disetel sekitar 30 detik
• MSL adalah waktu maksimum segmen TCP dapat bertahan di jaringan; RFC 793 mendefinisikannya sebagai 2 menit, tetapi pada sistem modern nilainya jauh lebih pendek
• Overflow bilangan bulat tak bertanda 32-bit adalah fenomena saat nilai kembali ke 0 setelah melewati batas maksimum (4.294.967.295). Timestamp TCP macOS (tcp_now) adalah penghitung 32-bit yang bertambah dalam satuan milidetik sejak boot, sehingga overflow terjadi setelah 49 hari 17 jam 2 menit 47,296 detik

Penemuan: koneksi TCP terhenti setelah 49,7 hari

• Server Mac milik Photon untuk pemantauan iMessage berjalan 24/7, dan pada 30 Maret 2026, tepat 49,7 hari setelah boot, terjadi fenomena di mana semua koneksi TCP baru gagal
  • Koneksi yang sudah ada dan ICMP (ping) tetap normal, tetapi pembuatan soket TCP baru tidak lagi memungkinkan
• Penyebabnya adalah overflow penghitung timestamp TCP (tcp_now) di kernel XNU, di mana logika validasi kenaikan monoton memblokir pembaruan setelah wraparound sehingga jam TCP internal berhenti
• Karena koneksi TIME_WAIT tidak kedaluwarsa, port sementara tidak dilepas dan terus menumpuk, hingga akhirnya tidak bisa dipulihkan tanpa reboot
• Setelah reboot, fenomena yang sama berulang dengan siklus 49,7 hari

Desain eksperimen: membandingkan perilaku TCP sebelum dan sesudah overflow

• Hipotesis: jika garbage collection TIME_WAIT berhenti setelah overflow, maka pola pembuatan koneksi TCP jangka pendek akan berbeda sebelum dan sesudah overflow
  • Sebelum overflow: TIME_WAIT kedaluwarsa normal setelah 30 detik
  • Setelah overflow: TIME_WAIT bertahan tanpa batas
• Skrip uji dijalankan dalam tiga tahap
  1. Tahap pemantauan: mencatat jumlah TIME_WAIT setiap 10 detik mulai 35 menit sebelum overflow hingga 5 menit sebelumnya
  2. Tahap ledakan: membuat sekitar 15 koneksi TCP pendek setiap 2 detik selama 10 menit di sekitar momen overflow
  3. Tahap observasi: memantau perubahan TIME_WAIT setelah pembuatan koneksi dihentikan

Hasil: TIME_WAIT macet setelah overflow

• Sebelum overflow, jumlah TIME_WAIT berputar stabil antara 0~200, yang menunjukkan mekanisme pembersihan normal
• Tepat setelah overflow, jumlah TIME_WAIT terus meningkat dan tidak lagi kedaluwarsa
• Pada Machine B, 2.828 koneksi TIME_WAIT tidak satu pun dibersihkan bahkan setelah 84 detik, dan terus menumpuk sesudahnya
• Machine A juga menunjukkan hasil pemeriksaan manual bahwa jumlah TIME_WAIT meningkat secara monoton dan tidak dapat dipulihkan

Akar masalah: overflow 32-bit tcp_now di kernel XNU

• tcp_now adalah penghitung 32-bit berbasis milidetik yang didefinisikan di bsd/netinet/tcp_var.h untuk melacak waktu sejak boot
• Di fungsi calculate_tcp_clock(), operasi (uint32_t)now.tv_sec * 1000 melampaui nilai maksimum setelah 49,7 hari dan menyebabkan wraparound
• Karena kondisi if (tmp < current_tcp_now), saat overflow nilai lama menjadi lebih besar daripada nilai baru sehingga pembaruan diblokir dan tcp_now berhenti permanen
• Pemeriksaan kedaluwarsa TIME_WAIT dilakukan berdasarkan tcp_now, jadi ketika jam berhenti, kondisi kedaluwarsa selalu bernilai salah dan pembersihan tidak pernah terjadi

Efek berantai: meluas menjadi penghentian total fungsi TCP

• Beberapa menit kemudian: pembersihan TIME_WAIT berhenti, dan beban kerja dengan banyak koneksi pendek mulai terdampak secara bertahap
• Beberapa jam kemudian: ribuan TIME_WAIT menumpuk, menyebabkan kehabisan port sementara
• Setelah port habis: koneksi TCP baru gagal dalam status SYN_SENT, dan hanya koneksi lama yang tetap bertahan
• Lonjakan beban CPU: kernel terus memindai antrean TIME_WAIT sehingga beban meningkat
• Hasil akhirnya adalah kelumpuhan total TCP, sementara ICMP tetap berfungsi normal
• Satu-satunya cara pemulihan adalah reboot, lalu hitungan 49,7 hari dimulai lagi dari awal

Bukti tambahan dan kasus terkait

• RFC 7323 menyebutkan bahwa wrapping bit tanda pada timestamp 32-bit dengan satuan 1 ms terjadi sekitar setiap 24,8 hari
  • Pada macOS, masalahnya adalah overflow 32-bit penuh (49,7 hari), yaitu cacat kernel lokal yang terpisah dari masalah timestamp jarak jauh yang dibahas di RFC
• Banyak laporan gejala yang sama di komunitas Apple dan proyek open source
  • Koneksi TCP tidak bisa dibuat, ping tetap normal, hanya reboot yang menyelesaikan, dan terjadi setelah sistem berjalan berminggu-minggu
  • Pola yang sama juga terlihat pada Podman issue #12495 dan lainnya
• Kesamaannya: hanya TCP yang gagal, ICMP tetap normal, perlu reboot, siklus kemunculan hitungan minggu

Cakupan dampak

• Dapat terjadi pada sistem macOS yang berjalan terus-menerus lebih dari 49 hari 17 jam
• Pengguna umum cenderung kurang terdampak karena pembaruan berkala biasanya disertai reboot
• Lingkungan berisiko tinggi
  • armada server yang berjalan lama
  • server build CI/CD berbasis macOS
  • workstation Mac Pro
  • Mac colocation dengan pengelolaan jarak jauh
  • klaster Mac mini untuk build farm dan infrastruktur pengujian

Langkah reproduksi

• Hitung waktu perkiraan overflow berdasarkan waktu boot
• Pantau jumlah TIME_WAIT sebelum dan sesudah overflow
• Buat banyak koneksi TCP pendek pada saat overflow
• Jika setelah 2 menit jumlah TIME_WAIT tidak berkurang, reproduksi bug dinyatakan berhasil

Kondisi sistem yang diamati setelah 9,5 jam

• Tidak satu pun koneksi TIME_WAIT dibersihkan, dan jumlahnya terus meningkat
• Lebih dari 3.000 koneksi gagal dalam status SYN_SENT menumpuk
• Hanya koneksi lama yang bertahan, koneksi baru tidak bisa dibuat
• Rata-rata beban Machine B naik hingga 49,74, karena kernel memakai CPU secara berlebihan untuk memindai antrean TIME_WAIT

Kesimpulan

• Hanya satu bilangan bulat 32-bit dan kondisi if (tmp < current_tcp_now) bertindak sebagai bom waktu yang menghentikan seluruh TCP setelah 49,7 hari
• Ini adalah jenis cacat yang sulit ditemukan pada tahap pengembangan, pengujian, maupun code review, dan baru tampak di lingkungan produksi nyata
• Photon berhasil mereproduksi fenomena yang sama di beberapa server, dan secara jelas mengonfirmasi bahwa sebelum overflow pembersihan berjalan normal, sesudahnya TIME_WAIT menumpuk
• Ketika tcp_now berhenti, jam TCP kernel ikut berhenti; sistem tampak normal di permukaan, tetapi semua port TCP pada akhirnya habis
• Administrator sistem macOS yang berjalan lama perlu mengingat 49 hari 17 jam 2 menit 47 detik, dan menyesuaikan siklus reboot atau melakukan reboot berkala sampai ada perbaikan kernel
• Photon saat ini sedang mengembangkan solusi sementara untuk memulihkan tcp_now tanpa reboot

[GN⁺]

Komentar Hacker News

• Sekarang akhirnya paham kenapa iMac saya kadang tidak bisa terhubung ke apa pun
  Sama sekali tidak tahu ternyata penyebabnya adalah uptime

• Saat membaca artikelnya, kesannya sangat kuat seperti ditulis AI, jadi saya penasaran apakah mereka benar-benar sudah menghubungi Apple
  Tentu bug ini penting, tapi terasa ada banyak ungkapan yang berlebihan
  Sepertinya sebagian besar pengguna hampir tidak akan terdampak
  Kalau Mac dibiarkan dalam mode tidur, stack TCP akan di-reset sehingga masalah ini mungkin bisa dihindari
  Pada akhirnya Apple pasti akan memperbaikinya, tapi ini bukan sesuatu yang perlu dipaniki sekarang juga

  • Saya juga sepertinya pernah mengalami masalah ini
    MacBook dengan sleep otomatis dimatikan menyala sekitar 50 hari, dan saat itu ping berfungsi tetapi koneksi TCP sama sekali tidak bisa
    Ganti Wi‑Fi atau pakai koneksi kabel pun tidak membantu, dan setelah reboot langsung kembali normal
  • Tidak menghubungi Apple, dan sepertinya penulis blog itu berniat memperbaikinya sendiri
    Katanya mereka sedang mengembangkan solusi alternatif yang lebih baik daripada reboot, dan sampai saat itu lakukan reboot secara berkala
  • Saya juga menyalakan Mac Mini 24 jam, dan kalau jaringan kadang macet, mematikan lalu menyalakan adaptor Wi‑Fi bisa menyelesaikannya
    Saat seperti itu memang waktu yang pas untuk reboot
  • Ini memang sudah dilaporkan ke Apple, dan katanya sudah didaftarkan ke sistem internal mereka

• Akhir-akhir ini tulisan blog yang dibuat AI terlalu sulit dibaca
  Gayanya terasa tidak alami dan terlalu lama untuk sampai ke inti

  • Saya juga sama. Tulisan buatan AI melelahkan untuk dibaca dan sulit membuat fokus
  • Kalau hanya melihat ringkasan dari AI, isinya sederhana — masalahnya adalah Mac tidak mengizinkan rollover saat clock tcp_now meluap

• Saya tidak setuju dengan pernyataan “tidak ada pengembang yang akan menguji selama 50 hari”
  Sebenarnya ini bisa diuji dengan simulasi percepatan waktu

  • Di kernel Linux, untuk menangkap masalah seperti ini, counter jiffies diinisialisasi saat boot ke nilai tepat sebelum overflow
  • macOS menggunakan clock perangkat keras sehingga berhenti saat sleep
    Dalam kasus seperti ini, verifikasi bisa dilakukan dengan mengubah fungsi seperti calculate_tcp_clock agar uptime diteruskan sebagai argumen
  • Cara seperti ini juga umum dipakai dalam pengujian video game

• Bug ini tidak hanya memengaruhi OpenClaw, tetapi semua koneksi TCP

  • Tidak perlu koneksi individual bertahan lama
    Setelah uptime macOS melewati 49,7 hari, semua koneksi TCP mulai terdampak
  • Ada juga candaan bahwa “sekarang OpenClaw terlihat seperti hal paling penting di dunia”

• Beberapa perangkat macOS saya sudah menyala lebih dari 600~1000 hari, dan koneksi TCP tetap kedaluwarsa secara normal
  Versi kernel masing-masing adalah 20.6.0 dan 17.7.0
  Jadi sepertinya bug ini hanya terjadi sejak versi tertentu

  • Dari analisisnya terlihat bahwa nilai tcp_now berhenti tepat sebelum overflow, dan wraparound yang salah dalam perhitungan timer membuat nilainya menjadi negatif sehingga perbandingan gagal
    Untuk sesaat koneksi TIME_WAIT memang bisa menumpuk, tetapi artikel aslinya bereaksi berlebihan dan terasa seperti tulisan LLM
  • Bug ini memang berasal dari kode baru yang diperkenalkan tahun lalu di macOS 26
    Tautan GitHub terkait

• Masalah seperti ini terus berulang di berbagai perangkat lunak
  Dulu server Guild Wars juga pernah mengalami hal serupa, dan untuk memicu overflow lebih cepat mereka menguji dengan menambahkan nilai tertentu ke GetTickCount()

  • Sistem yang menangani overflow seharusnya diuji dengan memaksa overflow segera setelah mulai berjalan

• Bug ini mengingatkan pada bug 49,7 hari di Windows 95
  Artikel terkait

  • Saya juga sempat mencoba mengingat pernah melihat angka ajaib itu di mana
  • Rasanya benar-benar seperti “masalah lama yang baru”
  • Masalah reboot daya 51 hari pada Boeing 787 juga contoh yang mirip
  • Itu sebabnya angka 49,7 hari terasa familier

• Saya penasaran apa hubungan OpenClaw dengan bug ini

• Masalah ini mengingatkan pada bug 208 hari di scheduler kernel Linux
  Tautan referensi

  • Dan masalah siklus daya Boeing 787 juga masih dalam konteks yang sama