macOS में 49.7 दिनों बाद TCP networking बंद हो जाने वाला bug मिला

 (photon.codes)
1 पॉइंट द्वारा GN⁺ 24 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS का TCP timestamp counter(tcp_now) बूट के लगभग 49.7 दिन बाद 32-bit overflow के कारण आंतरिक TCP clock को रोक देता है
  • इसके कारण TIME_WAIT state में मौजूद connections expire नहीं होते और जमा होते रहते हैं, जिससे ephemeral ports release नहीं हो पाते
  • समय बीतने पर ephemeral port exhaustion के कारण सभी नए TCP connections fail हो जाते हैं, और केवल existing connections ही बने रहते हैं
  • ICMP(ping) सामान्य रूप से काम करता है, लेकिन TCP की पूरी functionality ठप हो जाती है और reboot के अलावा recovery संभव नहीं होती
  • लंबे समय तक चलने वाले macOS server·build machine·CI environment इस समस्या के 49 दिन 17 घंटे के चक्र के संपर्क में रहते हैं, और kernel fix आने तक periodic reboot की आवश्यकता होती है

पृष्ठभूमि: TCP की बुनियादी अवधारणा

  • TCP connection बंद होने पर तुरंत गायब नहीं होता, बल्कि TIME_WAIT state में जाता है; यह delayed packets को संभालने और reliable termination के लिए जरूरी चरण है
    • यह पुराने packets को नए connection के रूप में गलत समझे जाने से रोकता है, और अंतिम ACK खो जाने पर retransmission संभालने के लिए होता है
  • TIME_WAIT की अवधि 2 × MSL(Maximum Segment Lifetime) के रूप में परिभाषित है, और macOS में यह लगभग 30 सेकंड पर सेट है
  • MSL वह अधिकतम समय है जितने समय तक TCP segment network में जीवित रह सकता है; RFC 793 में इसे 2 मिनट बताया गया था, लेकिन आधुनिक systems में यह काफी कम रखा जाता है
  • 32-bit unsigned integer overflow वह स्थिति है जिसमें मान अधिकतम सीमा(4,294,967,295) से आगे जाने पर 0 पर लौट आता है; macOS का TCP timestamp(tcp_now) बूट के बाद millisecond unit में बढ़ने वाला 32-bit counter है, जिसमें 49 दिन 17 घंटे 2 मिनट 47.296 सेकंड बाद overflow होता है

खोज: 49.7 दिनों बाद TCP connections रुकने की घटना

  • Photon के iMessage monitoring के लिए उपयोग किए जाने वाले Mac servers 24/7 चल रहे थे, और 30 मार्च 2026 को बूट के ठीक 49.7 दिन बाद सभी नए TCP connections fail होने लगे
    • existing connections और ICMP(ping) सामान्य रूप से काम कर रहे थे, लेकिन नए TCP sockets बनाना संभव नहीं था
  • मूल कारण XNU kernel के TCP timestamp counter(tcp_now) का overflow था, जहां monotonic increase verification logic wraparound के बाद update को रोक देता है, जिससे आंतरिक TCP clock रुक जाती है
  • TIME_WAIT connections expire नहीं होते, इसलिए ephemeral ports release नहीं होते और जमा होते रहते हैं, और अंततः reboot के अलावा recovery संभव नहीं रहती
  • reboot के बाद यही घटना फिर 49.7 दिन के चक्र में दोहराई गई

प्रयोग डिज़ाइन: overflow से पहले और बाद में TCP behavior की तुलना

  • परिकल्पना: अगर overflow के बाद TIME_WAIT garbage collection रुक जाती है, तो overflow से पहले और बाद में short-lived TCP connection creation pattern में अंतर दिखना चाहिए
    • overflow से पहले: TIME_WAIT 30 सेकंड बाद सामान्य रूप से expire होता है
    • overflow के बाद: TIME_WAIT अनिश्चितकाल तक बना रहता है
  • तीन चरणों वाला test script चलाया गया
    1. Monitoring phase: overflow से 35 मिनट पहले से 5 मिनट पहले तक हर 10 सेकंड में TIME_WAIT की संख्या रिकॉर्ड की गई
    2. Burst phase: overflow से पहले और बाद के 10 मिनट तक हर 2 सेकंड में लगभग 15 छोटे TCP connections बनाए गए
    3. Observation phase: connection creation रोकने के बाद TIME_WAIT में बदलाव को monitor किया गया

परिणाम: overflow के बाद TIME_WAIT ठहर गया

  • overflow से पहले TIME_WAIT की संख्या 0~200 के बीच स्थिर रूप से घूमती रही और सामान्य cleanup behavior की पुष्टि हुई
  • overflow के तुरंत बाद TIME_WAIT की संख्या लगातार बढ़ने लगी और फिर कभी expire नहीं हुई
  • Machine B में 2,828 TIME_WAIT connections 84 सेकंड बाद भी एक भी recover नहीं हुए, और उसके बाद भी लगातार जमा होते रहे
  • Machine A में भी manual verification के अनुसार TIME_WAIT की संख्या monotonic रूप से बढ़ी और recovery असंभव रही

मूल कारण: XNU kernel में tcp_now का 32-bit overflow

  • tcp_now bsd/netinet/tcp_var.h में परिभाषित millisecond unit वाला 32-bit counter है, जो boot के बाद बीते समय को track करता है
  • calculate_tcp_clock() function में (uint32_t)now.tv_sec * 1000 calculation 49.7 दिन बाद अधिकतम मान से ऊपर चली जाती है और wraparound होता है
  • if (tmp < current_tcp_now) condition के कारण overflow के समय पुराना मान नए मान से बड़ा हो जाता है, इसलिए update block हो जाता है और tcp_now स्थायी रूप से रुक जाता है
  • TIME_WAIT expiration check tcp_now के आधार पर की जाती है, इसलिए clock रुकने पर expiration condition हमेशा false हो जाती है और cleanup असंभव हो जाता है

श्रृंखलाबद्ध प्रभाव: TCP की पूरी functionality ठप

  • कुछ मिनट बाद: TIME_WAIT cleanup रुक जाता है, और short-lived connections वाले workloads में धीरे-धीरे समस्या शुरू होती है
  • कुछ घंटे बाद: हजारों TIME_WAIT जमा हो जाते हैं, और ephemeral port exhaustion शुरू हो जाता है
  • port exhaustion के बाद: नए TCP connections SYN_SENT state में fail होने लगते हैं, जबकि existing connections बने रहते हैं
  • CPU load में तेज़ बढ़ोतरी: kernel लगातार TIME_WAIT queue scan करता रहता है, जिससे load बढ़ता है
  • आखिरकार TCP पूरी तरह ठप, जबकि ICMP सामान्य रूप से काम करता रहता है
  • recovery का एकमात्र तरीका reboot है, जिसके बाद 49.7 दिन की गिनती फिर से शुरू होती है

अतिरिक्त साक्ष्य और संबंधित मामले

  • RFC 7323 स्पष्ट करता है कि 1ms unit वाले 32-bit timestamp में sign bit wrapping लगभग हर 24.8 दिन में होता है
    • macOS के मामले में यह पूरी 32-bit overflow(49.7 दिन) की समस्या है, जो RFC में बताए गए remote timestamp issue से अलग एक local kernel defect है
  • Apple community और open source projects में समान symptoms की कई reports मिलीं
    • TCP connection नहीं बनना, ping सामान्य, केवल reboot से समाधान, और कई हफ्तों की uptime के बाद समस्या आना
    • Podman issue #12495 आदि में वही pattern देखा गया
  • समानताएँ: सिर्फ TCP fail, ICMP सामान्य, reboot आवश्यक, कई हफ्तों के अंतराल पर समस्या

प्रभाव का दायरा

  • 49 दिन 17 घंटे से अधिक लगातार चलने वाले macOS systems में यह हो सकता है
  • सामान्य users पर असर कम है, क्योंकि periodic updates के दौरान reboot हो जाता है
  • उच्च-जोखिम वाले environment
    • लंबे समय तक चलने वाला server fleet
    • macOS आधारित CI/CD build servers
    • Mac Pro workstations
    • remote-managed colocation Macs
    • build farm·test infrastructure के लिए Mac mini clusters

पुनरुत्पादन प्रक्रिया

  • boot time से overflow के संभावित समय की गणना करें
  • overflow से पहले और बाद TIME_WAIT count monitor करें
  • overflow के समय बड़ी संख्या में short-lived TCP connections बनाएँ
  • 2 मिनट बाद भी यदि TIME_WAIT count कम न हो, तो bug reproduction सफल माना जाए

9.5 घंटे बाद देखी गई system state

  • TIME_WAIT connections में एक भी cleanup नहीं हुआ और वे लगातार बढ़ते रहे
  • SYN_SENT state में fail हुए 3,000 से अधिक connections जमा हो गए
  • केवल existing connections बने रहे और नए connections संभव नहीं रहे
  • Machine B का average load 49.74 तक पहुँच गया, क्योंकि kernel TIME_WAIT queue scan करने में अत्यधिक CPU इस्तेमाल कर रहा था

निष्कर्ष

  • केवल एक 32-bit integer और if (tmp < current_tcp_now) condition 49.7 दिन बाद पूरे TCP को रोक देने वाला time bomb बन गए
  • यह ऐसा defect है जिसे development·testing·code review चरणों में पकड़ना मुश्किल है, और जो केवल वास्तविक production environments में सामने आता है
  • Photon ने कई servers पर वही behavior reproduce किया, और overflow से पहले सामान्य cleanup तथा बाद में TIME_WAIT accumulation स्पष्ट रूप से पुष्टि हुई
  • tcp_now रुकते ही kernel की TCP clock रुक जाती है; system ऊपर से सामान्य दिखता है, लेकिन TCP ports पूरी तरह खत्म हो जाते हैं
  • लंबे समय तक चलने वाले macOS systems के admins को 49 दिन 17 घंटे 2 मिनट 47 सेकंड याद रखना चाहिए, और reboot schedule समायोजित करना या kernel fix आने तक periodic reboot करना आवश्यक है
  • Photon फिलहाल reboot के बिना tcp_now को recover करने वाला workaround विकसित कर रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 24 일 전
Hacker News की रायें

  • अब जाकर समझ आया कि मेरा iMac कभी-कभी किसी भी चीज़ से connect क्यों नहीं हो पाता था
    मुझे बिल्कुल पता नहीं था कि इसकी वजह uptime थी

  • पोस्ट पढ़ते हुए लगा कि उसमें AI से लिखे जाने वाला एहसास बहुत ज़्यादा है, इसलिए सोचा कि क्या Apple से सच में संपर्क किया गया था
    बेशक bug महत्वपूर्ण है, लेकिन लगा कि उसमें बढ़ा-चढ़ाकर लिखी गई बातें बहुत हैं
    ज़्यादातर users पर शायद इसका लगभग कोई असर नहीं पड़ेगा
    अगर Mac को sleep mode में रखा जाए तो TCP stack reset हो जाता है, इसलिए शायद इस समस्या से बचा जा सकता है
    आख़िरकार Apple इसे ठीक करेगा, लेकिन अभी तुरंत घबराने वाली बात नहीं है

    • मुझे भी लगता है कि मैंने यह समस्या झेली है
      auto-sleep बंद वाले MacBook को लगभग 50 दिनों तक चालू रखा था, और ping तो हो रहा था लेकिन TCP connection बिल्कुल नहीं बन रहा था
      Wi‑Fi बदलने या wired connection लगाने से भी समस्या हल नहीं हुई, और reboot करते ही सब तुरंत सामान्य हो गया
    • Apple से संपर्क नहीं किया गया, और लगता है कि ब्लॉग लिखने वाला खुद इसे ठीक करने की कोशिश कर रहा है
      उसने कहा है कि वह “reboot से बेहतर वैकल्पिक समाधान बना रहा है, और तब तक समय-समय पर reboot करें”
    • मैं भी Mac Mini को 24 घंटे चालू रखता हूँ, और कभी-कभी network रुक जाए तो Wi‑Fi adapter को off-on करने से ठीक हो जाता है
      ऐसे समय reboot करने का अच्छा मौका होता है
    • वास्तव में Apple को report किया गया था, और कहा गया कि वह उनके internal system में दर्ज हो चुका है

  • आजकल AI से लिखी गई ब्लॉग पोस्ट पढ़ना बहुत मुश्किल हो गया है
    उनकी शैली अस्वाभाविक होती है और मुद्दे तक पहुँचने में बहुत देर लगती है

    • मेरा भी यही अनुभव है। AI से लिखी चीज़ें पढ़ना थकाने वाला होता है और ध्यान टिकता नहीं
    • AI के summary को ही देखें तो बात सरल है — समस्या यह है कि Mac tcp_now clock के overflow होने पर rollover allow नहीं करता

  • “50 दिनों तक test करने वाला कोई developer नहीं होगा” इस बात से मैं सहमत नहीं हूँ
    असल में समय को तेज़ करके simulation test किया जा सकता है

    • Linux kernel में ऐसी समस्याएँ पकड़ने के लिए jiffies counter को boot के समय overflow से ठीक पहले वाले मान पर initialize किया जाता है
    • macOS hardware clock का इस्तेमाल करता है, इसलिए sleep के दौरान वह रुक जाती है
      ऐसे मामलों में calculate_tcp_clock जैसी function को बदलकर uptime को argument के रूप में pass किया जाए तो verification संभव है
    • ऐसा तरीका video game testing में भी आम है

  • यह bug सिर्फ OpenClaw नहीं बल्कि सभी TCP connections को प्रभावित करता है

    • किसी एक connection का लंबे समय तक बना रहना ज़रूरी नहीं है
      macOS uptime 49.7 दिन से आगे जाते ही सभी TCP connections प्रभावित होने लगते हैं
    • इस पर यह मज़ाक भी था कि “अब OpenClaw दुनिया की सबसे महत्वपूर्ण चीज़ लग रही है”

  • मेरे कई macOS devices 600~1000 दिनों से भी ज़्यादा समय से चालू हैं, और TCP connections सामान्य रूप से expire हो रहे हैं
    kernel versions क्रमशः 20.6.0 और 17.7.0 हैं
    इसलिए लगता है कि यह bug सिर्फ कुछ खास versions के बाद आता है

    • विश्लेषण के अनुसार tcp_now मान overflow से ठीक पहले रुक जाता है, और timer calculation में गलत wraparound के कारण वह negative हो जाता है, जिससे comparison fail हो जाता है
      थोड़े समय के लिए TIME_WAIT connections जमा हो सकते हैं, लेकिन मूल पोस्ट ने ज़रूरत से ज़्यादा प्रतिक्रिया दी और LLM से लिखी हुई लगती है
    • वास्तव में कहा गया कि यह bug पिछले साल macOS 26 में जोड़े गए नए code में आया था
      संबंधित GitHub लिंक

  • ऐसी समस्याएँ अलग-अलग software में बार-बार दिखाई देती हैं
    पहले Guild Wars server में भी ऐसा ही मामला था, जहाँ overflow जल्दी लाने के लिए GetTickCount() में एक खास मान जोड़कर test किया गया था

    • overflow संभालने वाले systems को शुरुआत के तुरंत बाद ही overflow करवाकर test करना चाहिए

  • यह bug Windows 95 के 49.7-दिन वाले bug की याद दिलाता है
    संबंधित लेख

    • मैं भी याद करने की कोशिश कर रहा था कि यह जादुई संख्या मैंने कहाँ देखी थी
    • सचमुच यह “नई पुरानी समस्या” जैसी लगती है
    • Boeing 787 का 51-दिन power reboot issue भी ऐसा ही उदाहरण है
    • इसलिए 49.7 दिन का यह अंक जाना-पहचाना लग रहा था

  • सोच रहा हूँ कि OpenClaw और इस bug का आपस में क्या संबंध है

  • यह समस्या Linux kernel scheduler के 208-दिन वाले bug की याद दिलाती है
    संदर्भ लिंक