Lỗi “No user logon” 10 năm tuổi của Steam

• Hiện tượng ngắt kết nối No user logon lâu năm của Counter-Strike vẫn tái hiện trong CS2; nếu kết nối tới máy chủ quá nhanh ngay sau khi khởi động game, quá trình xác minh Steam ID có thể không được bắt đầu
• Cốt lõi là trong lúc CS2.exe khởi động, vòng lặp levelload kết thúc sớm trước khi hoàn tất xác minh Steam3, và máy chủ xử lý kết nối bằng một Steam ID chưa được xác minh
• Trong log của Esportal, ngay cả người dùng bình thường cũng có dòng STEAM USERID validated được ghi khoảng 1 phút 20 giây sau khi kết nối; người dùng gặp lỗi bị ngắt sau 2–3 phút với STEAMAUTH failure code 8 và NETWORK_DISCONNECT_STEAM_LOGON
• Cài lại game, xác minh tệp, khởi động lại Steam, khởi động lại PC, tắt WiFi đều không sửa được nguyên nhân gốc; cần mở CS2 trước rồi đợi 5–10 giây ở menu chính
• Esportal đã sửa hành vi chạy steam://connect/<IP>:<Port> trước khi CS2.exe khởi tạo hoàn tất vào ngày 10/01/2024, và sau đó tỷ lệ ticket liên quan giảm xuống 0%

---

Hiện tượng No user logon lặp lại trong thời gian dài

• Hiện tượng ngắt kết nối No user logon của Counter-Strike được biết đến như một vấn đề xảy ra ngẫu nhiên trong lúc chơi, và đã được báo cáo lặp đi lặp lại trên nhiều diễn đàn cũng như diễn đàn hỗ trợ chính thức của Valve từ năm 2008 đến 2023
• No user logon và No steam logon xuất hiện trong một số bài viết nhiều khả năng về mặt kỹ thuật là những tên gọi khác nhau của cùng một nguyên nhân gốc
• Các cách khắc phục lan truyền rộng rãi trên Internet không sửa được nguyên nhân gốc
  • Cài lại game
  • Xác minh tệp game
  • Khởi động lại Steam
  • Khởi động lại máy tính
  • Tắt WiFi
• CS2 đã thay thế CS:GO vào ngày 27/09/2023, và người dùng thông thường không còn có thể chơi CS:GO nữa
• Phạm vi bug bounty HackerOne của Valve không bao gồm cs2.exe, và các báo cáo về CS2 Limited Test cũng được đánh dấu là nằm ngoài phạm vi

Số báo cáo tăng đột biến trên Esportal

• Esportal từng gặp vấn đề này trong CS:GO trước đây; lần xuất hiện đầu tiên được ghi nhận là 2019-11-15 19:15:32 CET, còn lần xuất hiện CS:GO cuối cùng là 2023-09-26 21:38:01 CET, một ngày trước khi bị thay thế bởi CS2
• Ban đầu trong CS2, vấn đề có vẻ đã biến mất, nhưng đến tuần đầu tiên của tháng 1/2024, báo cáo từ người dùng tăng lên
  • 2024-01-03: 6% ticket trong ngày
  • 2024-01-05~06: 18%
  • 2024-01-07: 23%
  • 2024-01-08: 10%
  • 2024-01-09: 9%
• Thời điểm báo cáo chủ yếu tập trung vào 13–17 giờ CET, tương ứng 04–08 giờ theo giờ Washington, nơi Valve đặt trụ sở
• Trước đây, báo cáo phân bố khá đều trong cả ngày, nhưng vấn đề mới quan sát được lại tập trung vào một khung giờ cụ thể
• Người chơi bên ngoài Esportal cũng gặp cùng vấn đề, nên đây không phải vấn đề riêng của một nền tảng cụ thể

Triệu chứng: xác minh Steam bị chậm và skin biến mất

• Lỗi No user logon quan sát được xảy ra 2–3 phút sau khi người chơi kết nối vào máy chủ game, và khoảng thời gian này khá ổn định
• Một đồng nghiệp nói rằng “sau khi vào game, skin không hiển thị trong CS2 trong vài phút”, và người chơi bên ngoài Esportal cũng báo cáo việc thiếu skin
• Vì skin gắn với quyền sở hữu Steam ID, có khả năng người chơi chưa được xác thực đúng cách qua Steam cho đến khi skin cá nhân xuất hiện
• Trong log của người dùng bình thường, STEAM USERID validated được ghi khoảng 1 phút 20 giây sau khi kết nối

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")

• Trong các log cũ trước ngày 03/01/2024, việc xác minh Steam hoàn tất trong vòng 2–3 giây sau khi kết nối
• Có thể tự tái hiện vào khung giờ ban đêm ở Washington, nhưng không tái hiện được vào ban ngày ở Washington

NETWORK_DISCONNECT_STEAM_LOGON và failure code 8

• Trong log của người dùng gặp lỗi, kết nối bị ngắt bằng NETWORK_DISCONNECT_STEAM_LOGON ngay sau STEAMAUTH: Client Bob received failure code 8

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 được cho là định danh nội bộ của thông báo No user logon mà người dùng nhìn thấy
• Tác giả đã tìm chuỗi STEAMAUTH: Client %s received failure code %d trong libengine2.so, rồi so sánh cùng sv_steamauth.cpp từ mã nguồn CS:GO bị rò rỉ và kết quả dịch ngược
• Hàm liên quan trong CS2 ngắt kết nối client tùy theo giá trị eAuthSessionResponse
  • 1: k_EAuthSessionResponseUserNotConnectedToSteam
  • 7: k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed
  • 8: k_EAuthSessionResponseAuthTicketInvalid
• failure code 8 có vẻ tương ứng với k_EAuthSessionResponseAuthTicketInvalid, xuất hiện khi xác minh Steam3 thất bại

Luồng xác minh Steam3

• Client game CS2.exe truyền Steam ID của mình khi kết nối tới máy chủ game
• Máy chủ game hỏi máy chủ Steam3 để kiểm tra Steam ID đó có hợp lệ không và có sở hữu game không
• Trong lúc chờ phản hồi xác minh, người chơi vẫn có thể tiếp tục chơi trên máy chủ, nhưng skin cá nhân có thể không hiển thị
• Nếu máy chủ Steam3 trả về “yes”, máy chủ game tin thông tin đó và có thể áp dụng dữ liệu cá nhân như skin
• Nếu máy chủ Steam3 trả về “no”, máy chủ game ngắt client bằng NETWORK_DISCONNECT_STEAM_LOGON
• Trong tình huống phản hồi Steam3 chậm vào khung giờ ban đêm ở Washington, mất khoảng 1 phút 20 giây để hoàn tất xác minh

Xác minh độ tin cậy của CS2.exe và Steam client

• Chỉ việc Steam ID hợp lệ không chứng minh được rằng instance CS2.exe đó là game của tài khoản Steam đã đăng nhập trên cùng máy
• CS2.exe phải kết nối với Steam.exe trên cùng máy để xác nhận rằng Steam ID nó gửi khớp với tài khoản Steam hiện đang đăng nhập
• Khi Steam.exe xác nhận sự trùng khớp, nó tạm lưu thông tin rằng Steam ID đó hợp lệ với CS2 trên máy chủ Steam3
• Trong các khả năng khiến Steam3 trả về “no”, hai khả năng gần với vấn đề thực tế được thu hẹp còn như sau
  • Instance CS2.exe không được tin cậy
  • Máy chủ Steam3 chưa biết thông tin Steam ID cho instance CS2.exe đó

Manh mối phía client: NETWORK_DISCONNECT_LOOPSHUTDOWN

• Trong log lỗi, NETWORK_DISCONNECT_LOOPSHUTDOWN xuất hiện trước NETWORK_DISCONNECT_STEAM_LOGON

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")

• Sau NETWORK_DISCONNECT_LOOPSHUTDOWN, game tự động thử kết nối lại sau 5 giây
• Lần ngắt kết nối đầu tiên này không phải do máy chủ game mà do chính CS2.exe khởi tạo
• Vì vậy, nguyên nhân gốc nằm ở phía client game chứ không phải máy chủ game

Vòng lặp levelload của Source 2 và thứ tự khởi tạo

• Engine Source 2 chạy một vòng lặp đang hoạt động tại một thời điểm; vòng lặp lặp lại xử lý tác vụ nền và đầu vào người dùng cho đến khi hoàn tất một mục tiêu cụ thể
• Vòng lặp cuối cùng được chạy sau khi CS2.exe khởi động là vòng lặp game, phụ trách tương tác menu thực tế và gameplay
• Trong output console, trạng thái xác thực Steam được hiển thị là OK ngay trước khi chuyển sang vòng lặp game

[SteamNetSockets] AuthStatus (steamid:<redacted>):  OK  (OK)
[Client] CL:  CLoopModeLevelLoad::MaybeSwitchToGameLoop switching to "game" loopmode with addons ()
[EngineServiceManager] SwitchToLoop game requested:  id [1] addons []

• levelload là vòng lặp khởi tạo chạy khi CS2 khởi động, có vẻ dùng để tải các màn hình ban đầu như video intro và menu chính, dù đó không phải bản đồ thực tế
• Một trong những tác vụ cuối của levelload là bắt đầu xác minh Steam3 từ CS2.exe thông qua Steam.exe

Nguyên nhân trực tiếp của lỗi

• CS2 chỉ có thể được xem là đã khởi tạo hoàn tất sau khi vòng lặp levelload kết thúc thành công
• Nếu levelload bị kết thúc sớm trước khi khởi tạo xong, xác minh Steam3 sẽ không bắt đầu
• Instance CS2.exe ở trạng thái này trở nên hỏng, và không thể phục hồi chỉ bằng cách nào khác ngoài khởi động lại CS2
• Luồng lỗi như sau
  • Khởi động CS2.exe
  • Bắt đầu vòng lặp levelload
  • levelload kết thúc sớm trước khi bắt đầu xác minh Steam3
  • Vòng lặp game kết nối tới máy chủ game bằng Steam ID chưa được xác minh
  • Máy chủ game kiểm tra với Steam3
  • Nhận phản hồi thất bại sau tối đa khoảng 2 phút 50 giây và ngắt kết nối bằng No user logon
• Bài viết này xử lý vấn đề dựa trên ví dụ và tên gọi trong CS2, nhưng CS:GO và Counter-Strike: Source cũng có lỗi tương đương, chỉ khác tên kỹ thuật và cách thức

Cách kết nối gây ra lỗi

• Vấn đề là một race condition tùy theo cách khởi động CS2
• Cách gần như chắc chắn gây ra lỗi là kết nối thẳng tới máy chủ game khi CS2 chưa mở
• Các cách kết nối rủi ro gồm
  • Kết nối tới máy chủ từ server browser bên ngoài game khi CS2 chưa chạy hoặc vừa mới bắt đầu chạy
  • Kết nối tới bạn bè từ danh sách bạn bè Steam khi CS2 chưa chạy hoặc vừa mới bắt đầu chạy
  • Kết nối trực tiếp từ bên ngoài bằng giao thức trình duyệt Steam như steam://connect/127.0.0.1:27015
• Nếu thực hiện các thao tác trên trước khi CS2 khởi tạo hoàn tất sau khi khởi động, khả năng xảy ra cao hơn
• Tỷ lệ nguyên nhân được tóm tắt bằng phép ví von: “cách khởi động Counter-Strike 90%, tốc độ máy tính 3%, tốc độ người dùng 3%, trạng thái của mặt trăng 3%, vấn đề cấu hình người dùng thực sự 1%”

Cách giải quyết thực tế

• Những việc không nên làm
  • Cài lại game
  • Xác minh tệp game
  • Khởi động lại Steam
  • Khởi động lại máy tính
  • Tắt WiFi
  • Kết nối tới máy chủ game từ bên ngoài trước khi CS2 khởi động
• Thay vào đó, cần chạy CS2 trước và chờ đủ lâu trước khi kết nối tới máy chủ game
• Mốc tham chiếu là chờ đến khi thấy console game, hoặc chờ 5–10 giây sau khi thấy video intro
• Để xác nhận chắc chắn, sau khi khởi động CS2, nhập status trong console game và kiểm tra dòng sau

[EngineServiceManager] @ Current  :  game

Kết quả sau bản sửa của Esportal

• Lý do người dùng lỗi Bob xác minh thành công 9 phút sau lần thử đầu tiên là vì đã khởi động lại CS2, và lần đó không xui xẻo gặp lỗi
• Khi Steam ID đã được xác minh một lần, trong cùng instance game sẽ không thất bại về sau trừ khi đóng Steam client
• Cho đến ngày 10/01/2024, Esportal vẫn cho kết nối tới máy chủ matchmaking bằng steam://connect/<IP>:<Port> ngay khi tiến trình CS2.exe xuất hiện, kể cả trước khi khởi tạo hoàn tất
• Sau khi sửa hành vi đó và triển khai cho toàn bộ người chơi Esportal, các ticket người dùng liên quan đã dừng lại
• Tỷ lệ No user logon trong ticket hằng ngày đã tăng tới 23% vào ngày 07/01/2024, nhưng giảm xuống 0% từ ngày 10/01/2024 đến 12/01/2024

[GN⁺]

Ý kiến trên Hacker News

• Luồng trong sơ đồ khá giống với cách Steam gọi là Session Tickets, còn thực tế thì tinh tế hơn một chút
  Client game yêu cầu một vé phiên từ máy chủ Steam, rồi chuyển vé đó cho máy chủ game để chứng minh mình là một Steam ID cụ thể
  Sau đó máy chủ game phải kiểm tra trực tuyến qua Web API của Steam để xác minh vé không bị dùng nhiều lần hoặc bị sửa đổi
  Nghe có vẻ client CS2 không xử lý đúng phản hồi bị trễ trong quá trình lấy vé phiên
  Luồng được mô tả chi tiết ở đây: https://partner.steamgames.com/doc/features/auth#3
  Nếu nó hoạt động như sơ đồ trong bài viết thì khá đáng lo, vì kẻ tấn công có thể chạy đua để vào server bằng Steam ID của nạn nhân

  • Đúng, nhìn chung rất có thể là vé phiên, và có vẻ bài viết chưa diễn đạt rõ phần đó
    Vấn đề dường như nằm ở chỗ game bị dừng trước khi thực sự tạo vé phiên, hoặc trong lúc chờ phản hồi chậm từ máy chủ Steam, rồi kết nối tới máy chủ game mà không có vé
  • Đúng, về mặt kỹ thuật luồng này là chính xác, và tôi nghĩ nó không quá quan trọng với phần mô tả vấn đề, nhưng lẽ ra nên nêu rõ hơn

• Bài viết rất hay, nhưng quá trình truy vết và kết luận không hoàn toàn khớp với nhau
  Khi nói “cách Counter-Strike khởi động: chịu 90% trách nhiệm”, đồng thời lại nói người chơi trên toàn thế giới cũng gặp cùng vấn đề ngoài Esportal và đã xác nhận là do bảo trì lúc nửa đêm ở Washington, thì hai điều đó khó có thể cùng đúng
  Nếu 90% trách nhiệm nằm ở cách khởi chạy, vấn đề đã không phân bố theo khung giờ bảo trì
  Điểm mấu chốt có vẻ là “xác minh Steam ID bắt đầu ngay trước khi game loop khởi động” và “nếu quá trình khởi tạo levelload chưa kết thúc, xác minh Steam3 là bước cuối nên sẽ chưa bắt đầu”
  Tức là nếu trong khung giờ bảo trì, máy chủ steam3 trở nên rất chậm, quá trình này kéo dài hơn và khả năng người dùng khởi động game trong lúc đó rồi làm đứt vòng lặp sẽ tăng lên
  Vì vậy “cách Counter-Strike khởi động” cũng đúng, nhưng những cách diễn đạt như “trạng thái của mặt trăng: chịu 3% trách nhiệm” thực chất đang chỉ vào khung giờ bảo trì, nên hơi lệch
  Lời khuyên cũng nên có thêm kiểu “từ 13–17h CET là khung giờ Valve bảo trì, hãy chờ thêm vài phút”
  Dù sao tôi cũng từng gặp vấn đề này, và cách giải “chờ một chút để nó tải xong” là cách thực tế và hợp lý nhất tôi từng nghe đến nay

  • Có những lỗ hổng trong chi tiết phần giải thích hoặc kết luận, nhưng tôi cũng khó chắc cách diễn giải này hoàn toàn đúng
    Trong CS:GO cũng từng có cùng vấn đề, không liên quan đến khung giờ bảo trì, còn trong CS2 thì chỉ quan sát thấy vào khung giờ bảo trì
    Rốt cuộc có thể bản chất lỗi của CS:GO và CS2 khác nhau, nhưng CS:GO đã bị CS2 thay thế nên không còn cách chứng minh nữa

• Ngày xưa, hồi chưa có Steam, tôi từng làm một công cụ hiển thị danh sách người chơi đang hoạt động và điểm số để có thể xem bạn mình đang vào server nào rồi vào ngay
  Trong lúc làm công cụ đó, tôi gửi nhầm một packet tới server đang dùng để test và làm server sập
  Tôi vẫn còn mã nguồn viết bằng Delphi, và nếu các lỗi 10 năm tuổi vẫn còn tồn tại thì tôi tò mò liệu thứ đó bây giờ còn có thể làm sập server không

  • Thử một phát được không? :D

• Lỗi thật sự là việc hoàn tất xác thực không phải điều kiện bắt buộc để bắt đầu multiplayer không phải LAN

  • Hoặc việc luồng xác minh vé phiên phụ thuộc vào kết nối giữa máy chủ game và máy chủ xác thực của Valve cũng là vấn đề. Máy chủ xác thực đó có vẻ đôi khi rất chậm
    Một cách nhanh và vững chắc hơn có thể là Steam client nhận và lưu một token đã ký có hiệu lực vài giờ từ Valve, rồi gửi token đó mỗi lần kết nối tới máy chủ game
    Máy chủ game chỉ cần xác minh cục bộ bằng chứng chỉ công khai do Valve phát hành và được phân phối kèm nội dung server

• Một vài đoạn có cảm giác như “đội thêm mũ lên trên một cái mũ”
  Lại chồng thêm mỉa mai lên một đoạn vốn đã kiểu meme, khiến yếu tố vốn hiệu quả hơn khi tinh tế trở nên quá đà
  Như những người khác đã nói, nên đi vào trọng tâm nhanh hơn

• Đọc rất thú vị. Tôi tự hỏi liệu có thể điều tra theo cách tương tự lý do client game đột ngột crash không
  Cũng tò mò liệu kiểm tra tính toàn vẹn của file thực thi có chạy cả khi game đang chạy không, và nếu một trong các lần kiểm tra đó thất bại trong lúc đang chạy thì có hiện thông báo ngắt kết nối khác không
  Có vẻ đáng được thưởng như bài phân tích vấn đề thời gian tải GTA V quá dài: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

  • Tôi tò mò bạn đang nói tới kiểu crash đột ngột nào
    Về lý thuyết có thể điều tra crash, nhưng Valve không lưu báo cáo crash ra đĩa mà gửi lên server
    Nếu không bắt được theo thời gian thực khi gắn debugger thì phân tích sẽ khó hơn; do VAC nên hơi rắc rối, nhưng không phải bất khả thi. Chỉ cần tắt VAC là được

• Việc đặt phần tóm tắt ở đầu bài cho những người vào từ tìm kiếm cách xử lý vấn đề là khá chu đáo
  Nhưng ngay sau đó lại nói “những gì không nên làm”, còn hành động thực sự có thể làm thì bị giấu trong một câu ở giữa bài dài hàng cây số
  Nên đưa cách обход vào phần tóm tắt

  • Gần như một trò đùa tàn nhẫn. Tóm tắt: đừng làm cái này, thay vào đó hãy đọc toàn bộ bài!
  • “Bài dài hàng cây số” nếu tính theo đơn vị đo lường thì khoảng 25 lần Page Down, còn theo đơn vị tự do thì khoảng một lần CTRL+F
  • Nói đúng, nên tôi đã sửa lại bằng một phần tóm tắt tốt hơn

• Tôi nói điều này vì gu viết kiểu Strunk and White đã ăn sâu trong đầu, nên nếu muốn thì cứ bỏ qua
  Nếu bạn muốn góp ý, tôi khuyên nên biên tập mạnh tay để bài trực tiếp và súc tích hơn nhiều
  Có thể viết dài, nhưng chỉ sau vài phút, các phần giải thích phụ và giai thoại chồng lên nhau khiến tôi khá nhanh mất mạch chính
  Thêm cả hình tham chiếu Inception vào nữa thì cảm giác nó giống một tập hợp nội dung không liên quan hơn là một bài truyền đạt thông tin
  Hãy nghĩ xem mình muốn nói gì, nói điều đó, rồi quay lại kiểm tra xem có thật sự chỉ nói đúng điều đó không
  Phần còn lại gần với luyện gõ phím hơn là viết. Nếu có 3–4 điều cần nói thì cứ nói đúng những điều đó thôi

• Bài viết rất hay nhưng tôi vẫn còn vài câu hỏi
  levelloadloop chỉ chạy khi khởi động game, chứ không chạy khi tham gia server và tải map à?
  Nếu vấn đề là vòng lặp kết thúc trước khi tiến trình xác thực Steam bắt đầu, thì hiện tượng chậm do bảo trì trở nên quan trọng vì sao?

  • Câu 1 thì đúng, nó chỉ chạy khi khởi động game
    Tên vòng lặp này có vẻ liên quan tới các game single-player như Portal, và trong các game đó việc chuyển level diễn ra liền mạch, nên tên như vậy tự nhiên hơn nhiều
    Câu 2 đúng là phần giải thích còn lỗ hổng, và tôi không biết câu trả lời
    Tuy nhiên chắc chắn phương pháp này sửa được vấn đề. Có khả năng cao chi tiết của kết luận chưa hoàn chỉnh, nhưng hiện tại tôi không thấy cần đào sâu hơn

• Nội dung chương trình thưởng của Valve nói rằng phạm vi bao gồm “nền tảng Steam và các game hiện tại do Valve phát triển/phát hành”
  Ngoài ra, từ 10:00 sáng PDT ngày 14/6/2023, các báo cáo mới về CS:GO nằm ngoài phạm vi, và các báo cáo về CS2 Limited Test hiện cũng ngoài phạm vi
  Đúng là Valve yếu về bảo mật, nhưng nếu đọc rộng toàn bộ mô tả HackerOne thì cá nhân tôi sẽ xem đây là trong phạm vi
  Ý tôi là vì tab “Scope” chưa được cập nhật để loại trừ csgo.exe, nên chỉ dựa vào tab đó thì khó tin cậy
  Dù vậy Valve thật sự nên cập nhật phần đó

  • Valve không trả lời cả một yêu cầu đơn giản hỏi xem cái này có nằm trong phạm vi không, nên không thể biết được
    Nhưng tôi đồng ý với kết luận, và nó hợp lý