रुकिए: WPA3 कनेक्शन 11 घंटे के बाद विफल हो जाते हैं

मूल लेख ↗ Hacker News चर्चा ↗

कुछ Broadcom/Infineon-आधारित devices पर WPA3 Wi‑Fi connections लगभग 11 घंटे के uptime के बाद गिर रहे हैं, और माना जा रहा है कि इसका कारण WPA3 की किसी अंतर्निहित खामी के बजाय chipset या driver में key rekeying या counters से जुड़ा bug है। टिप्पणीकार scheduled reboots या WPA2 पर वापस जाने जैसे workarounds पर चर्चा करते हैं, और व्यापक Wi‑Fi ecosystem की आलोचना तक बात बढ़ाते हैं: opaque firmware blobs, कमजोर long-term vendor support, और ऐसे आर्थिक प्रोत्साहन जो मानकों को पूरी तरह test करने के बजाय नए standards जारी करने को बढ़ावा देते हैं। कई आवाज़ें थोड़े पुराने, अच्छी तरह समर्थित hardware और OpenWrt जैसे open-source stacks को reliability के लिए सुझाती हैं, जबकि पूरी तरह open Wi‑Fi chipsets के सामने व्यावहारिक और नियामकीय बाधाओं को भी रेखांकित करती हैं.

11-घंटे की WPA3 विफलता के मूल-कारण की परिकल्पनाएँ

  • कई लोग एक “uptime bug” पर संदेह करते हैं: Broadcom/Cypress/Infineon Wi‑Fi चिप/ड्राइवर संयोजन में integer overflow या counter wrap।
  • अन्य लोगों का मानना है कि यह खास तौर पर rekeying की समस्या है:
    • GTK/SAE rekey interval अक्सर लगभग 3600s होता है; कुछ लोग प्रस्तावित करते हैं कि लगभग 10 सफल rekeys के बाद कुछ टूट जाता है और 11वाँ विफल होता है, जो 11-घंटे के लक्षण से मेल खाता है।
    • hostapd के एक patch (key lifetimes बदलना, default लगभग 12h) को संभावित fix के रूप में सुझाया गया है, हालांकि समय-निर्धारण बिल्कुल मेल नहीं खाता।
  • साधारण 16-बिट second counters ठीक 11h से मेल नहीं खाते; लोग अन्य timer granularities या frame counters के बारे में अटकलें लगाते हैं।
  • सहमति: यह संभवतः client/driver bug है, कोई सामान्य WPA3 spec failure नहीं; vendor drivers reportedly काम करते हैं, जो दर्शाता है कि कोई workaround मौजूद है।

हार्डवेयर, ड्राइवर, और ecosystem की आलोचना

  • Broadcom/Cypress/Infineon Wi‑Fi ecosystem को “cursed” कहा गया है: binary blobs, कमजोर Linux support, vendor की न्यूनतम भागीदारी।
  • Raspberry Pi का कुछ लोग बचाव करते हैं कि यह अपनी कीमत के लिए “ठीक” है, जबकि अन्य इसे अविश्वसनीय बताते हैं, क्योंकि इसमें सस्ते, न्यूनतम-tested components होते हैं।
  • कई लोग स्थिरता के लिए Intel PCIe Wi‑Fi cards की सिफारिश करते हैं, लेकिन अन्य हाल की Intel समस्याओं और नए chips पर AP mode support की कमी का हवाला देते हैं।
  • ath9k और OpenWrt जैसे open-source stacks को स्थिरता के लिए सराहा जाता है, लेकिन वे पुराने hardware या सीमित chipsets पर निर्भर रहते हैं।

Workarounds और व्यावहारिक सलाह

  • स्वचालित किए जा सकने वाले workarounds पर चर्चा की गई:
    • विफलता विंडो से ठीक पहले scheduled reboots (cron/systemd timers)।
    • कनेक्टिविटी की निगरानी (जैसे, ping) और failure पर interface को bounce करना।
    • WPA rekey intervals समायोजित करना या जहाँ संभव हो WPA2 पर टिके रहना।
    • सुरक्षा के लिए open/OWE Wi‑Fi के साथ WireGuard जैसे overlay VPN का उपयोग करना।
  • कुछ लोग चेतावनी देते हैं कि workarounds प्रकाशित करने से vendors bugs को “wontfix” के रूप में दर्ज कर सकते हैं।

Wi‑Fi standards की परिपक्वता और deployment strategy

  • Wi‑Fi practitioners से सलाह: reliability के लिए 1–2 generations पीछे रहें (जैसे, 802.11ac + WPA2, बजाय bleeding-edge WPA3/6E/7 के)।
  • अन्य लोग तर्क देते हैं कि Wi‑Fi 6/ax अब पर्याप्त परिपक्व है; Wi‑Fi 7 को बहुत जल्दी माना जाता है।
  • Enterprise बनाम consumer: enterprise gear को आम तौर पर वास्तविक bugfixes मिलते हैं; consumer routers अक्सर auto-reboot features से instability को work around करते हैं।

Open-source Wi‑Fi hardware पर चर्चा

  • पूरी तरह open Wi‑Fi chips को आर्थिक और नियामकीय रूप से कठिन माना जाता है:
    • अत्यधिक spec complexity और certification burden।
    • FCC rules जो user-modifiable transmit behavior के खिलाफ हैं।
    • कम margins और volume-driven chip economics।
  • FPGA-based open Wi‑Fi projects research platforms के रूप में मौजूद हैं, लेकिन अभी mass-market alternatives के रूप में व्यावहारिक नहीं हैं।