- Counter-Strike में लंबे समय से मौजूद
No user logon disconnect CS2 में भी दोहराया जाता है, और गेम शुरू होते ही सर्वर से बहुत जल्दी connect करने पर Steam ID verification शुरू नहीं हो सकता
- मुख्य बात यह है कि
CS2.exe startup के दौरान levelload loop Steam3 verification पूरा होने से पहले ही समय से पहले खत्म हो जाता है, और server unverified Steam ID के साथ connection को process करता है
- Esportal logs में normal users के लिए भी
STEAM USERID validated connection के करीब 1 मिनट 20 सेकंड बाद record हुआ, और failed users 2–3 मिनट बाद STEAMAUTH failure code 8 और NETWORK_DISCONNECT_STEAM_LOGON के साथ disconnect हुए
- Game reinstall, file verification, Steam restart, PC reboot, WiFi disable करना root cause को ठीक नहीं करता; CS2 को पहले launch करके main menu में 5–10 सेकंड इंतजार करना चाहिए
- Esportal ने 10 जनवरी 2024 को वह behavior ठीक किया जिसमें
CS2.exe पूरी तरह initialize होने से पहले steam://connect/<IP>:<Port> चलाया जाता था, और उसके बाद related tickets का हिस्सा 0% पर गिर गया
लंबे समय से दोहराई जा रही No user logon घटना
- Counter-Strike का
No user logon disconnect gameplay के दौरान random रूप से होने वाली समस्या के रूप में जाना जाता है, और 2008 से 2023 तक कई forums और Valve के official support forum में बार-बार report हुआ
No user logon और कुछ posts में दिखने वाला No steam logon तकनीकी रूप से एक ही root cause के अलग नाम हो सकते हैं
- Internet पर widely फैले fixes root cause को ठीक नहीं करते
- Game reinstall
- Game files verify करना
- Steam restart
- Computer reboot
- WiFi disable करना
- CS2 ने 27 सितंबर 2023 को CS:GO को replace किया, और regular users अब CS:GO नहीं खेल सकते
- Valve के HackerOne bug bounty scope में
cs2.exe शामिल नहीं था, और CS2 Limited Test reports भी scope से बाहर दिखाए गए थे
Esportal पर अचानक बढ़ीं reports
- Esportal ने पहले CS:GO में भी यह समस्या झेली थी, और records के अनुसार पहली घटना 2019-11-15 19:15:32 CET पर, आखिरी CS:GO घटना CS2 से replace होने से एक दिन पहले 2023-09-26 21:38:01 CET पर हुई थी
- CS2 के शुरुआती दिनों में समस्या गायब लग रही थी, लेकिन जनवरी 2024 के पहले हफ्ते में user reports बढ़ीं
- 2024-01-03: daily tickets में 6%
- 2024-01-05~06: 18%
- 2024-01-07: 23%
- 2024-01-08: 10%
- 2024-01-09: 9%
- Report timings मुख्य रूप से 13–17 बजे CET में केंद्रित थे, जो Valve के Washington time के हिसाब से 04–08 बजे होता है
- पहले reports पूरे दिन evenly distributed थीं, लेकिन नई observed समस्या किसी खास time window में concentrated थी
- Esportal के बाहर के players भी यही समस्या झेल रहे थे, इसलिए यह किसी एक platform की समस्या नहीं थी
Symptoms: देर से होने वाला Steam verification और गायब skins
- observed
No user logon error player के game server से connect होने के 2–3 मिनट बाद हुआ, और यह interval काफी consistent था
- एक colleague ने कहा, “game में enter करने के बाद कुछ मिनट तक CS2 में skins दिखाई नहीं देते,” और Esportal के बाहर के players ने भी missing skins report किए
- Skins Steam ID ownership से जुड़े होते हैं, इसलिए personal skins दिखने से पहले player के Steam के जरिए properly authenticated न होने की संभावना है
- Normal user logs में connection के करीब 1 मिनट 20 सेकंड बाद
STEAM USERID validated record हुआ
16:39:55: "Alice<1><>" connected
16:41:14: "Alice<1><>" STEAM USERID validated
17:17:32: "Alice<1><CT>" disconnected (reason "NETWORK_DISCONNECT_DISCONNECT_BY_USER")
- 3 जनवरी 2024 से पहले के पुराने logs में Steam verification connection के 2–3 सेकंड के भीतर पूरा हो जाता था
- Washington की रात के समय इसे manually reproduce किया जा सकता था, और Washington के daytime में reproduce नहीं हुआ
NETWORK_DISCONNECT_STEAM_LOGON और failure code 8
- Failed user logs में
STEAMAUTH: Client Bob received failure code 8 के तुरंत बाद NETWORK_DISCONNECT_STEAM_LOGON से connection टूट गया
16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")
NETWORK_DISCONNECT_STEAM_LOGON को user को दिखने वाले No user logon message का internal identifier माना जाता है
libengine2.so में STEAMAUTH: Client %s received failure code %d string खोजी गई, और CS:GO leaked source के sv_steamauth.cpp व reverse-engineering results की साथ में तुलना की गई
- CS2 का related function
eAuthSessionResponse value के आधार पर client को disconnect करता है
1: k_EAuthSessionResponseUserNotConnectedToSteam
7: k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed
8: k_EAuthSessionResponseAuthTicketInvalid
- failure code
8 Steam3 verification failure पर दिखने वाले k_EAuthSessionResponseAuthTicketInvalid से मेल खाता दिखता है
Steam3 verification flow
- Game client
CS2.exe game server से connect करते समय अपना Steam ID भेजता है
- Game server यह check करने के लिए कि वह Steam ID valid है या नहीं और game का ownership है या नहीं, Steam3 server से पूछता है
- Verification response का इंतजार करते समय player server पर खेलता रह सकता है, लेकिन personal skins दिखाई नहीं दे सकते
- Steam3 server “yes” return करता है तो game server उस जानकारी पर भरोसा करता है और skins जैसी personal information apply कर सकता है
- Steam3 server “no” return करता है तो game server client को
NETWORK_DISCONNECT_STEAM_LOGON से disconnect करता है
- Washington रात के समय Steam3 response slow होने की स्थिति में verification पूरा होने में करीब 1 मिनट 20 सेकंड लगे
CS2.exe trust verification और Steam client
- सिर्फ Steam ID valid होना यह prove नहीं करता कि वह
CS2.exe instance उसी machine पर logged-in Steam account का game है
CS2.exe को उसी machine के Steam.exe से connect करके confirm कराना होता है कि उसने जो Steam ID भेजी है, वह currently logged-in Steam account से match करती है
Steam.exe match confirm करता है तो Steam3 server में उस Steam ID के CS2 के लिए valid होने की जानकारी temporary रूप से store होती है
- Steam3 द्वारा “no” return करने की संभावित वजहों में actual problem के करीब ये दो cases बचे
CS2.exe instance trusted नहीं है
- Steam3 server को उस
CS2.exe instance के लिए Steam ID की जानकारी अभी नहीं है
Client-side clue: NETWORK_DISCONNECT_LOOPSHUTDOWN
- Failed logs में
NETWORK_DISCONNECT_STEAM_LOGON से पहले NETWORK_DISCONNECT_LOOPSHUTDOWN दिखाई देता है
16:40:03: "Bob<6><>" connected
16:40:08: "Bob<6><Unassigned>" disconnected (reason "NETWORK_DISCONNECT_LOOPSHUTDOWN")
16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")
NETWORK_DISCONNECT_LOOPSHUTDOWN के बाद game 5 सेकंड बाद automatically फिर से connect करने की कोशिश करता है
- यह पहला disconnect game server ने नहीं, बल्कि
CS2.exe ने खुद शुरू किया था
- इसलिए root cause game server में नहीं, game client side में था
Source 2 का levelload loop और initialization order
- Source 2 engine एक समय में एक active loop चलाता है, और loop किसी specific goal के complete होने तक background tasks और user input processing को repeat करता है
CS2.exe शुरू होने के बाद अंत में चलने वाला loop actual menu interaction और gameplay संभालने वाला game loop है
- Console output में
game loop पर switch होने से ठीक पहले Steam authentication status OK दिखता है
[SteamNetSockets] AuthStatus (steamid:<redacted>): OK (OK)
[Client] CL: CLoopModeLevelLoad::MaybeSwitchToGameLoop switching to "game" loopmode with addons ()
[EngineServiceManager] SwitchToLoop game requested: id [1] addons []
levelload CS2 startup पर चलने वाला initialization loop है, और actual map न होने पर भी intro video और main menu जैसी initial screens load करता दिखता है
levelload के आखिरी tasks में से एक CS2.exe से Steam.exe के जरिए Steam3 verification शुरू करना है
Bug का direct cause
- CS2 को तभी पूरी तरह initialized माना जा सकता है जब
levelload loop successfully खत्म हो जाए
- अगर
levelload initialization खत्म होने से पहले समय से पहले बंद हो जाए, तो Steam3 verification शुरू नहीं होता
- इस state में
CS2.exe instance broken state में चला जाता है, और simple CS2 restart किए बिना recover नहीं होता
- Bug flow इस तरह है
CS2.exe start
levelload loop start
- Steam3 verification शुरू होने से पहले
levelload का early shutdown
game loop unverified Steam ID के साथ game server से connect करता है
- Game server Steam3 से check करता है
- अधिकतम करीब 2 मिनट 50 सेकंड बाद failure response मिलता है और
No user logon के साथ disconnect होता है
- इस issue को CS2 example और names के आधार पर discuss किया गया है, लेकिन CS:GO और Counter-Strike: Source में भी equivalent bug है; सिर्फ technical names और method अलग हैं
Bug trigger करने वाला connection तरीका
- समस्या CS2 startup method पर निर्भर race condition है
- Bug को लगभग निश्चित रूप से trigger करने का तरीका है CS2 open न होने की स्थिति में सीधे game server से connect करना
- Risky connection methods ये हैं
- Game के बाहर server browser से, जब CS2 running न हो या अभी-अभी start हुआ हो, server से connect करना
- Steam friends list से, जब CS2 running न हो या अभी-अभी start हुआ हो, friend से join करना
steam://connect/127.0.0.1:27015 जैसे Steam browser protocol से बाहर से direct connect करना
- CS2 start करने के बाद fully initialize होने से पहले ऊपर वाले actions करने पर इसकी संभावना बढ़ जाती है
- Cause distribution को एक metaphor में इस तरह summarize किया गया: “Counter-Strike शुरू करने का तरीका 90%, computer speed 3%, user speed 3%, moon phase 3%, actual user settings problem 1%”
Actual fix
- ये steps नहीं करने चाहिए
- Game reinstall
- Game files verify करना
- Steam restart
- Computer reboot
- WiFi disable करना
- CS2 शुरू होने से पहले बाहर से game server से connect करना
- इसके बजाय पहले CS2 run करें, और game server से connect करने से पहले पर्याप्त इंतजार करें
- Guideline है game console दिखने तक इंतजार करना, या intro video दिखने के बाद 5–10 सेकंड इंतजार करना
- पक्का confirm करने के लिए CS2 start करने के बाद game console में
status type करें और यह line check करें
[EngineServiceManager] @ Current : game
Esportal fix के परिणाम
- Failed user
Bob पहली कोशिश के 9 मिनट बाद verification में इसलिए सफल हुआ क्योंकि उसने CS2 restart किया, और उस बार unlucky bug trigger नहीं हुआ
- एक बार Steam ID verify हो जाए तो उसी game instance में बाद में failure नहीं होता, जब तक Steam client बंद न किया जाए
- Esportal 10 जनवरी 2024 तक
CS2.exe process बनते ही, full initialization से पहले भी steam://connect/<IP>:<Port> से matchmaking server में connect करा रहा था
- यह behavior ठीक करके सभी Esportal players के लिए deploy करने पर related user tickets बंद हो गए
- Daily tickets में
No user logon का हिस्सा 2024-01-07 को 23% तक गया था, लेकिन 2024-01-10 से 2024-01-12 तक 0% पर गिर गया
1 टिप्पणियां
Hacker News की राय
डायग्राम का flow उस तरीके के ज्यादा करीब है जिसे Steam Session Tickets कहता है, और असल में मामला थोड़ा और सूक्ष्म है
game client Steam server से session ticket मांगता है, फिर game server को एक ticket भेजता है जो साबित करता है कि वह किसी खास Steam ID का मालिक है
इसके बाद game server को Steam की Web API से online जांच करके verify करना चाहिए कि ticket कई बार इस्तेमाल नहीं हुआ है या उसमें छेड़छाड़ नहीं की गई है
ऐसा लगता है कि CS2 client session ticket पाने की प्रक्रिया में delayed response को ठीक से handle नहीं कर पा रहा
flow यहां विस्तार से दिया है: https://partner.steamgames.com/doc/features/auth#3
अगर यह लेख के diagram जैसा काम करता है, तो attacker किसी victim के Steam ID से server join करने की race कर सकता है, जो काफी चिंताजनक है
समस्या यह लगती है कि game असल में session ticket बनाने से पहले, या धीमे Steam server response का इंतजार करते समय, रुक जाता है और बिना ticket के game server से connect कर लेता है
लेख बढ़िया है, लेकिन tracing process और conclusion पूरी तरह मेल नहीं खाते
एक तरफ यह “Counter-Strike कैसे शुरू होता है: जिम्मेदारी 90%” कहता है, और दूसरी तरफ यह भी कहता है कि दुनिया भर के players को Esportal के बाहर भी यही समस्या हुई और यह Washington में आधी रात की maintenance की वजह से confirm हुई—दोनों बातें साथ में सही होना मुश्किल है
अगर जिम्मेदारी 90% launch method की होती, तो समस्या maintenance time slots में clustered नहीं होती
मुख्य बात यह लगती है कि “game loop शुरू होने के ठीक पहले Steam ID verification शुरू होता है” और “अगर levelload initialization खत्म नहीं होती, तो Steam3 verification आखिरी step होने के कारण शुरू नहीं होता”
यानी maintenance time में अगर steam3 server बहुत slow हो जाए, तो यह process लंबा हो जाता है, और इस बीच game शुरू करके loop तोड़ देने की संभावना बढ़ जाती है
इसलिए “Counter-Strike कैसे शुरू होता है” भी सही है, लेकिन “चांद की स्थिति: जिम्मेदारी 3%” जैसी अभिव्यक्ति असल में maintenance time को ही refer करती है, इसलिए थोड़ा off लगती है
सलाह में यह भी शामिल हो तो अच्छा होगा कि “CET 13–17 बजे Valve का maintenance window है, इसलिए कुछ मिनट और इंतजार करें”
वैसे मैंने यह समस्या झेली है, और “थोड़ा इंतजार करके loading खत्म होने दें” वाला समाधान अब तक सुने गए उपायों में सबसे practical और reasonable है
CS:GO में भी maintenance time से unrelated यही समस्या थी, और CS2 में यह केवल maintenance time में देखी गई
आखिरकार CS:GO और CS2 के bugs की प्रकृति अलग भी हो सकती थी, लेकिन CS:GO को CS2 ने replace कर दिया है, इसलिए अब इसे prove करने का कोई तरीका नहीं है
बहुत पहले, Steam आने से पहले, मैंने एक tool बनाया था जो active players और score list दिखाता था, ताकि दोस्त जिस server पर हो उसमें सीधे join किया जा सके
वह tool बनाते समय गलती से test कर रहे server को गलत packet भेज दिया, तो server down हो गया
Delphi में लिखा source code अभी भी मेरे पास है; अगर 10 साल पुराने bugs अब भी बचे हैं, तो सोच रहा हूं क्या यह आज भी server को kill कर सकता है
असली bug यह है कि authentication पूरा होना non-LAN multiplayer शुरू करने की अनिवार्य शर्त नहीं है
ज्यादा तेज और robust तरीका यह हो सकता है कि Steam client Valve से कुछ घंटों के लिए valid signed token लेकर store करे, और हर बार game server से connect करते समय वही token भेजे
game server इसे Valve द्वारा जारी और server content के साथ distribute किए गए public certificate से locally verify कर सकेगा
कुछ paragraphs “टोपी के ऊपर टोपी रखने” जैसे लगते हैं
पहले से meme जैसे paragraph के ऊपर sarcasm की और layer चढ़ा दी गई है, जिससे जो चीज subtle होने पर ज्यादा असर करती है वह overdone लगती है
जैसा दूसरों ने कहा, बेहतर होगा कि core point पर जल्दी आया जाए
पढ़कर बहुत मजा आया। सोच रहा हूं कि क्या game client अचानक crash होने की वजह भी इसी तरह investigate की जा सकती है
यह भी curious है कि executable integrity check run के दौरान भी चलता है या नहीं, और उनमें से कोई run के दौरान fail हो तो क्या कोई अलग disconnect message दिखता है
GTA V की बहुत लंबी loading time की समस्या analyze करने वाले लेख की तरह यह reward के लायक लगता है: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
crashes theoretically investigate किए जा सकते हैं, लेकिन Valve crash reports को disk पर save नहीं करता, server पर भेजता है
debugger attach करके real time में पकड़ न पाएं तो analysis ज्यादा कठिन हो जाता है, और VAC की वजह से tricky है, लेकिन impossible नहीं। VAC बंद कर दें तो हो सकता है
लेख की शुरुआत में समस्या का समाधान search करके आने वालों के लिए summary रखना considerate लगा
लेकिन उसके तुरंत बाद “क्या नहीं करना चाहिए” बताया गया, और असल में की जा सकने वाली action किलोमीटर-लंबे लेख के बीच की एक line में छिपी है
बेहतर होगा कि workaround summary में डाल दिया जाए
यह बात Strunk and White style writing preference दिमाग में बैठी होने के कारण कह रहा हूं, चाहें तो ignore कर सकते हैं
अगर feedback चाहिए, तो सलाह दूंगा कि लेख को बहुत ज्यादा direct और concise बनाने के लिए काफी कड़ा edit किया जाए
लंबा लेख लिखना ठीक है, लेकिन कुछ मिनट बाद extra explanations और anecdotes जमा होने लगे और मैंने main flow काफी जल्दी खो दिया
इसमें Inception reference image भी आ जाए तो यह information-delivery article से ज्यादा unrelated चीजों का collection लगने लगता है
सोचें कि आप क्या कहना चाहते हैं, उसे कहें, फिर वापस जाकर check करें कि सच में सिर्फ वही कहा है या नहीं
बाकी चीज writing से ज्यादा typing practice जैसी है। अगर कहने को 3–4 बातें हैं, तो बस वही कह दें
लेख बढ़िया था, लेकिन कुछ सवाल बाकी हैं
क्या levelloadloop केवल game launch के समय चलता है, server join और map loading के समय नहीं?
अगर समस्या यह है कि Steam authentication process शुरू होने से पहले loop end हो जाता है, तो maintenance की वजह से slowdown important क्यों हो जाता है?
इस loop का नाम Portal जैसे single-player games से जुड़ा लगता है, और ऐसे games में levels seamlessly change होते हैं, इसलिए यह नाम वहां कहीं ज्यादा natural है
2 में explanation में gap है, यह सही है और मुझे जवाब नहीं पता
हालांकि यह तरीका समस्या fix करता है, यह पक्का है। conclusion के details incomplete होने की संभावना ज्यादा है, लेकिन अभी मुझे इसमें और गहराई तक जाने की जरूरत महसूस नहीं होती
Valve के reward program की wording में “Steam platform और Valve द्वारा develop/distribute किए गए current games” शामिल बताए गए हैं
साथ ही, 14 जून 2023 सुबह 10 बजे PDT से CS:GO की नई reports scope से बाहर हैं, और CS2 Limited Test reports भी अभी scope से बाहर हैं
Valve security में कमजोर है, यह सही है, लेकिन HackerOne के पूरे description को broad तरीके से पढ़ूं तो निजी तौर पर मैं इसे in scope मानूंगा
“Scope” tab में
csgo.exeको exclude करने के लिए update नहीं किया गया है, यानी सिर्फ उस tab पर भरोसा करना मुश्किल हैफिर भी Valve को वह हिस्सा जरूर update करना चाहिए
फिर भी मैं conclusion से सहमत हूं, बात समझ में आती है