Le bug « No user logon » de Steam vieux de 10 ans

• L’ancienne déconnexion No user logon de Counter-Strike se reproduit aussi dans CS2 : si l’on se connecte trop vite à un serveur juste après le lancement du jeu, la vérification de l’ID Steam peut ne pas démarrer
• Le point clé est que, pendant le lancement de CS2.exe, la boucle levelload se termine prématurément avant que la vérification Steam3 ne soit achevée, et que le serveur traite alors la connexion avec un ID Steam non vérifié
• Dans les logs d’Esportal, même pour un utilisateur normal, STEAM USERID validated était enregistré environ 1 min 20 s après la connexion ; pour les utilisateurs en échec, la déconnexion survenait 2 à 3 minutes plus tard avec le code d’échec STEAMAUTH 8 et NETWORK_DISCONNECT_STEAM_LOGON
• Réinstaller le jeu, vérifier les fichiers, relancer Steam, redémarrer le PC ou désactiver le Wi-Fi ne corrigent pas la cause racine ; il faut lancer CS2 d’abord, puis attendre 5 à 10 secondes dans le menu principal
• Le 10 janvier 2024, Esportal a corrigé le comportement qui lançait steam://connect/<IP>:<Port> avant que CS2.exe soit entièrement initialisé ; depuis, la part des tickets liés à ce problème est tombée à 0 %

---

Un phénomène No user logon qui se répète depuis longtemps

• La déconnexion No user logon de Counter-Strike est connue comme un problème survenant aléatoirement en pleine partie, et a été signalée à de nombreuses reprises sur divers forums et sur les forums officiels de support de Valve entre 2008 et 2023
• No user logon et No steam logon, visible dans certains messages, sont probablement deux noms différents d’une même cause racine sur le plan technique
• Les solutions largement diffusées sur Internet ne corrigent pas la cause racine
  • Réinstaller le jeu
  • Vérifier les fichiers du jeu
  • Relancer Steam
  • Redémarrer l’ordinateur
  • Désactiver le Wi-Fi
• CS2 a remplacé CS:GO le 27 septembre 2023, et les utilisateurs ordinaires ne peuvent plus jouer à CS:GO
• Le périmètre du programme de bug bounty HackerOne de Valve n’incluait pas cs2.exe, et les signalements concernant le CS2 Limited Test étaient également indiqués comme hors périmètre

Une hausse soudaine des signalements chez Esportal

• Esportal avait déjà rencontré ce problème par le passé avec CS:GO ; d’après les journaux, la première occurrence datait du 2019-11-15 19:15:32 CET, et la dernière occurrence sur CS:GO du 2023-09-26 21:38:01 CET, la veille de son remplacement par CS2
• Au début de CS2, le problème semblait avoir disparu, mais les signalements d’utilisateurs ont augmenté pendant la première semaine de janvier 2024
  • 2024-01-03 : 6 % des tickets quotidiens
  • 2024-01-05~06 : 18 %
  • 2024-01-07 : 23 %
  • 2024-01-08 : 10 %
  • 2024-01-09 : 9 %
• Les signalements se concentraient principalement entre 13 h et 17 h CET, ce qui correspond à 04 h-08 h dans l’État de Washington, où se trouve Valve
• Auparavant, les signalements étaient répartis de façon homogène sur toute la journée, mais le nouveau problème observé était concentré sur une plage horaire précise
• Des joueurs extérieurs à Esportal rencontraient aussi le même problème : ce n’était donc pas propre à une plateforme donnée

Symptômes : vérification Steam retardée et skins qui disparaissent

• L’erreur No user logon observée se produisait 2 à 3 minutes après la connexion du joueur au serveur de jeu, avec un intervalle assez constant
• Un collègue a indiqué que « les skins ne s’affichent pas dans CS2 pendant quelques minutes après l’entrée en jeu », et des joueurs extérieurs à Esportal ont également signalé l’absence de skins
• Les skins étant liés à la propriété de l’ID Steam, il est possible que le joueur ne soit pas correctement authentifié via Steam tant que ses skins personnels ne s’affichent pas
• Dans les logs d’un utilisateur normal, STEAM USERID validated est enregistré environ 1 min 20 s après la connexion

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

• Dans les anciens logs antérieurs au 3 janvier 2024, la vérification Steam se terminait en 2 à 3 secondes après la connexion
• Le problème était reproductible directement pendant les horaires nocturnes dans l’État de Washington, mais ne l’était pas en journée dans cet État

NETWORK_DISCONNECT_STEAM_LOGON et failure code 8

• Dans les logs des utilisateurs en échec, la connexion est interrompue avec NETWORK_DISCONNECT_STEAM_LOGON juste après 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 est supposé être l’identifiant interne du message No user logon vu par l’utilisateur
• La chaîne STEAMAUTH: Client %s received failure code %d a été recherchée dans libengine2.so, puis comparée à sv_steamauth.cpp dans le code source divulgué de CS:GO ainsi qu’aux résultats de rétro-ingénierie
• Dans CS2, la fonction concernée déconnecte le client selon la valeur de eAuthSessionResponse
  • 1 : k_EAuthSessionResponseUserNotConnectedToSteam
  • 7 : k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed
  • 8 : k_EAuthSessionResponseAuthTicketInvalid
• Le failure code 8 semble correspondre à k_EAuthSessionResponseAuthTicketInvalid, observé lors d’un échec de vérification Steam3

Flux de vérification Steam3

• Lorsqu’il se connecte à un serveur de jeu, le client CS2.exe transmet son ID Steam
• Le serveur de jeu interroge les serveurs Steam3 pour vérifier que cet ID Steam est valide et que le jeu est bien possédé
• Pendant l’attente de la réponse de vérification, le joueur peut continuer à jouer sur le serveur, mais ses skins personnels peuvent ne pas s’afficher
• Si le serveur Steam3 renvoie « yes », le serveur de jeu fait confiance à cette information et peut appliquer les données personnelles comme les skins
• Si le serveur Steam3 renvoie « no », le serveur de jeu déconnecte le client avec NETWORK_DISCONNECT_STEAM_LOGON
• Dans les situations où la réponse de Steam3 ralentissait pendant la nuit dans l’État de Washington, il fallait environ 1 min 20 s pour que la vérification se termine

Vérification de confiance de CS2.exe et client Steam

• Le simple fait qu’un ID Steam soit valide ne prouve pas que cette instance de CS2.exe correspond au jeu du compte Steam connecté sur la même machine
• CS2.exe doit se connecter à Steam.exe sur la même machine pour faire confirmer que l’ID Steam qu’il a envoyé correspond au compte Steam actuellement connecté
• Quand Steam.exe confirme la correspondance, il enregistre temporairement sur les serveurs Steam3 l’information selon laquelle cet ID Steam est valide pour CS2
• Parmi les raisons possibles pour lesquelles Steam3 peut renvoyer « no », les deux plus proches du problème réel sont les suivantes
  • L’instance de CS2.exe n’est pas considérée comme fiable
  • Le serveur Steam3 ne connaît pas encore les informations d’ID Steam pour cette instance de CS2.exe

Indice côté client : NETWORK_DISCONNECT_LOOPSHUTDOWN

• Dans les logs d’échec, NETWORK_DISCONNECT_LOOPSHUTDOWN apparaît avant 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")

• Après NETWORK_DISCONNECT_LOOPSHUTDOWN, le jeu tente automatiquement de se reconnecter au bout de 5 secondes
• Cette première déconnexion n’est pas initiée par le serveur de jeu, mais par CS2.exe lui-même
• La cause racine se trouvait donc côté client de jeu, et non côté serveur de jeu

La boucle levelload de Source 2 et l’ordre d’initialisation

• Le moteur Source 2 exécute une seule boucle active à la fois ; une boucle répète les tâches en arrière-plan et le traitement des entrées utilisateur jusqu’à ce qu’un objectif donné soit atteint
• Après le lancement de CS2.exe, la boucle finalement exécutée est la boucle game, chargée des interactions réelles avec le menu et du gameplay
• Dans la sortie console, l’état d’authentification Steam apparaît comme OK juste avant le passage à la boucle 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 est la boucle d’initialisation exécutée au démarrage de CS2 ; même sans véritable carte, elle semble charger les premiers écrans comme la vidéo d’introduction et le menu principal
• L’une des dernières tâches de levelload consiste à lancer la vérification Steam3 depuis CS2.exe en passant par Steam.exe

Cause directe du bug

• CS2 ne peut être considéré comme entièrement initialisé qu’après la fin réussie de la boucle levelload
• Si l’initialisation levelload se termine prématurément, la vérification Steam3 ne démarre pas
• Dans cet état, l’instance de CS2.exe est cassée, et elle ne se rétablit pas tant que CS2 n’est pas simplement relancé
• Le déroulé du bug est le suivant
  • Lancement de CS2.exe
  • Démarrage de la boucle levelload
  • levelload se termine prématurément avant de lancer la vérification Steam3
  • La boucle game se connecte au serveur de jeu avec un ID Steam non vérifié
  • Le serveur de jeu interroge Steam3
  • Après jusqu’à environ 2 min 50 s, il reçoit une réponse d’échec et déconnecte avec No user logon
• Ce problème est décrit ici avec les exemples et noms de CS2, mais des bugs équivalents existent aussi dans CS:GO et Counter-Strike: Source, seuls les noms techniques et les méthodes différant

Modes de connexion qui déclenchent le bug

• Le problème est une condition de concurrence (race condition) liée à la manière de lancer CS2
• La méthode qui déclenche presque à coup sûr le bug consiste à se connecter directement à un serveur de jeu alors que CS2 n’est pas ouvert
• Les modes de connexion risqués sont les suivants
  • Connexion à un serveur depuis un navigateur de serveurs externe alors que CS2 n’est pas lancé ou vient tout juste de démarrer
  • Rejoindre un ami depuis la liste d’amis Steam alors que CS2 n’est pas lancé ou vient tout juste de démarrer
  • Connexion directe depuis l’extérieur via le protocole de navigateur Steam, par exemple steam://connect/127.0.0.1:27015
• Si ces actions sont effectuées après le démarrage de CS2 mais avant son initialisation complète, la probabilité d’occurrence augmente
• La répartition des causes est résumée par l’analogie suivante : « 90 % la façon de démarrer Counter-Strike, 3 % la vitesse de l’ordinateur, 3 % la vitesse de l’utilisateur, 3 % l’état de la Lune, 1 % un vrai problème de configuration utilisateur »

Solution réelle

• Actions à ne pas faire
  • Réinstaller le jeu
  • Vérifier les fichiers du jeu
  • Relancer Steam
  • Redémarrer l’ordinateur
  • Désactiver le Wi-Fi
  • Se connecter à un serveur de jeu depuis l’extérieur avant le démarrage de CS2
• Il faut plutôt lancer CS2 d’abord, puis attendre suffisamment avant de se connecter à un serveur de jeu
• Le repère consiste à attendre que la console du jeu soit visible, ou à attendre 5 à 10 secondes après l’apparition de la vidéo d’introduction
• Pour s’en assurer, après avoir lancé CS2, on peut saisir status dans la console du jeu et vérifier la ligne suivante

[EngineServiceManager] @ Current  :  game

Résultat de la correction d’Esportal

• Si l’utilisateur en échec Bob a réussi la vérification 9 minutes après sa première tentative, c’est parce qu’il avait relancé CS2 et que le bug ne s’était pas produit cette fois-là par malchance
• Une fois l’ID Steam vérifié, il ne rééchoue pas plus tard dans la même instance de jeu, sauf si le client Steam est fermé
• Jusqu’au 10 janvier 2024, Esportal connectait les joueurs au serveur de matchmaking via steam://connect/<IP>:<Port> dès que le processus CS2.exe apparaissait, même avant son initialisation complète
• Après correction de ce comportement et déploiement auprès de tous les joueurs Esportal, les tickets utilisateurs liés au problème se sont arrêtés
• La part de No user logon dans les tickets quotidiens était montée jusqu’à 23 % le 2024-01-07, mais elle est tombée à 0 % du 2024-01-10 au 2024-01-12

[GN⁺]

Commentaires sur Hacker News

• Le schéma se rapproche davantage de ce que Steam appelle des Session Tickets, même si la réalité est un peu plus subtile
  Le client du jeu demande un ticket de session aux serveurs Steam, puis transmet au serveur de jeu un ticket prouvant qu’il est bien associé à un Steam ID donné
  Ensuite, le serveur de jeu doit vérifier en ligne via la Web API de Steam que le ticket n’a pas été utilisé plusieurs fois ni falsifié
  On dirait que le client CS2 gère mal la réponse différée dans le processus d’obtention du ticket de session
  Le flux est décrit en détail ici : https://partner.steamgames.com/doc/features/auth#3
  Si cela fonctionne comme dans le schéma de l’article, il est assez inquiétant qu’un attaquant puisse rivaliser avec la victime pour rejoindre le serveur avec son Steam ID

  • Oui, il s’agit très probablement de tickets de session en pratique, et l’article ne semble pas l’exprimer clairement
    Le problème semble venir du fait que le jeu s’interrompt avant de créer réellement le ticket de session, ou pendant qu’il attend une réponse lente des serveurs Steam, puis se connecte au serveur de jeu sans ticket
  • Oui, techniquement ce flux est exact, et je pensais que ce n’était pas très important pour l’explication du problème, mais cela aurait dû être formulé plus clairement

• L’article est excellent, mais l’enquête et la conclusion ne s’emboîtent pas complètement
  Dire « La façon dont Counter-Strike démarre : responsabilité à 90 % » tout en affirmant que des joueurs du monde entier ont eu le même problème en dehors d’Esportal et qu’il a été confirmé que cela venait de la maintenance nocturne à Washington, ce sont deux choses difficiles à concilier
  Si 90 % de la responsabilité venait de la manière dont il démarre, le problème ne se répartirait pas selon les horaires de maintenance
  Le point clé semble être « la vérification du Steam ID commence juste avant le démarrage de la boucle du jeu » et « si l’initialisation de levelload n’est pas terminée, la vérification Steam3 ne démarre pas car c’est la dernière étape »
  Autrement dit, si les serveurs steam3 deviennent très lents pendant la fenêtre de maintenance, ce processus s’allonge et il devient alors plus probable que le jeu soit lancé et interrompe la boucle entre-temps
  Donc « la façon dont Counter-Strike démarre » est aussi en cause, mais une formule comme « l’état de la lune : responsabilité à 3 % » désigne en pratique la fenêtre de maintenance, ce qui sonne un peu faux
  Le conseil pourrait aussi inclure « entre 13 h et 17 h CET, comme c’est la période de maintenance de Valve, attendez simplement quelques minutes de plus »
  Quoi qu’il en soit, j’ai déjà rencontré ce problème, et la solution consistant à « patienter un peu pour laisser le chargement se terminer » est de loin la plus pratique et la plus raisonnable que j’aie entendue jusqu’ici

  • Il y a des failles dans les détails de l’explication et de la conclusion, mais je ne suis pas certain non plus que cette interprétation soit entièrement juste
    Le même problème existait déjà dans CS:GO indépendamment des périodes de maintenance, alors que dans CS2 il n’a été observé que pendant ces périodes
    En fin de compte, la nature du bug était peut-être différente entre CS:GO et CS2, mais comme CS:GO a été remplacé par CS2, il n’y a plus aucun moyen de le prouver

• À l’époque d’avant Steam, j’avais créé un outil qui affichait la liste des joueurs actifs et des scores pour pouvoir voir le serveur sur lequel un ami était connecté et le rejoindre immédiatement
  En développant cet outil, j’ai envoyé un paquet erroné à un serveur de test, ce qui l’a fait tomber
  J’ai encore le code source écrit en Delphi, et si des bugs vieux de 10 ans existent encore, je me demande si cela pourrait toujours faire tomber les serveurs aujourd’hui

  • Tu peux essayer ? :D

• Le vrai bug, c’est que l’authentification terminée n’est pas une condition obligatoire au démarrage d’une partie multijoueur hors LAN

  • Ou alors le problème est aussi que le flux de vérification du ticket de session dépend d’une connexion entre le serveur de jeu et les serveurs d’authentification de Valve. Ces serveurs semblent parfois très lents
    Une méthode plus rapide et plus robuste serait que le client Steam récupère auprès de Valve un jeton signé valable quelques heures et le conserve, puis envoie ce jeton à chaque connexion à un serveur de jeu
    Le serveur de jeu pourrait alors le vérifier localement avec un certificat public émis par Valve et distribué avec le contenu du serveur

• Certains paragraphes donnent une impression de « chapeau sur chapeau »
  Il y a déjà un côté mème dans certains passages, et en rajoutant encore de la moquerie, un effet qui fonctionne mieux quand il reste subtil devient trop appuyé
  Comme d’autres l’ont dit, il vaudrait mieux aller plus vite à l’essentiel

• Lecture très amusante. Je me demande si on pourrait enquêter de la même manière sur les raisons pour lesquelles le client du jeu plante soudainement
  Je me demande aussi si la vérification d’intégrité de l’exécutable continue pendant l’exécution, et si l’échec de l’une d’elles en cours de route produit un message de déconnexion différent
  Cela semble mériter une récompense, un peu comme l’article qui analysait les temps de chargement bien trop longs de GTA V : https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

  • Je me demande de quels plantages soudains il s’agit exactement
    En théorie, on peut enquêter sur les crashs, mais Valve n’enregistre pas les rapports de crash sur disque, ils sont envoyés au serveur
    Si on ne les attrape pas en temps réel avec un débogueur attaché, l’analyse devient plus difficile, et c’est délicat à cause de VAC, même si ce n’est pas impossible. Il suffit de désactiver VAC

• Mettre au début de l’article un résumé pour les personnes arrivées là après avoir cherché une solution montre une vraie attention
  Mais juste après, il explique ce qu’il ne faut pas faire, et l’action réellement possible se retrouve cachée dans une phrase au milieu d’un texte long de plusieurs kilomètres
  Il vaudrait mieux inclure la méthode de contournement dans le résumé

  • C’est presque une blague cruelle. Résumé : ne faites pas ça, lisez plutôt tout l’article !
  • « texte long de plusieurs kilomètres », en unité de calcul, ça fait environ 25 pressions sur Page Down, et en unité libre, à peu près un CTRL+F
  • C’est juste, donc j’ai modifié le résumé pour qu’il soit meilleur

• Je dis ça avec mon goût pour l’écriture à la Strunk and White bien ancré dans la tête, donc n’hésitez pas à l’ignorer si vous voulez
  Si vous voulez un retour, je recommanderais de tailler beaucoup plus franchement dans le texte pour le rendre plus direct et plus concis
  On peut écrire un long article, mais au bout de quelques minutes, avec l’accumulation d’explications annexes et d’anecdotes, j’ai perdu assez vite le fil principal
  Avec en plus cette image faisant référence à Inception, cela donne davantage l’impression d’un assemblage de choses vaguement liées que d’un texte destiné à transmettre une information
  Il suffit de réfléchir à ce que vous voulez dire, de le dire, puis de revenir dessus pour vérifier que vous n’avez vraiment dit que cela
  Tout le reste relève moins de l’écriture que de la dactylographie. Si vous avez 3 ou 4 choses à dire, dites simplement ces 3 ou 4 choses

• L’article était excellent, mais il me reste quelques questions
  levelloadloop ne s’exécute-t-il qu’au lancement du jeu, et pas lors de la connexion à un serveur ni lors du chargement d’une carte ?
  Si le problème vient du fait que la boucle se termine avant le démarrage du processus d’authentification Steam, pourquoi le ralentissement causé par la maintenance devient-il important ?

  • Oui pour le point 1, cela ne s’exécute qu’au lancement du jeu
    Le nom de cette boucle semble venir de jeux solo comme Portal, où les niveaux s’enchaînent sans interruption, ce qui rend ce nom bien plus naturel dans ce contexte
    Pour le point 2, oui, il y a bien un trou dans l’explication, et je n’ai pas la réponse
    En revanche, il est certain que cette méthode corrige le problème. Il est très possible que les détails de la conclusion soient incomplets, mais je ne ressens pas le besoin d’approfondir davantage pour le moment

• Le texte du programme de récompense de Valve précise qu’il couvre « la plateforme Steam et les jeux actuels développés et édités par Valve »
  Il précise aussi qu’à partir du 14 juin 2023 à 10 h PDT, les nouveaux signalements concernant CS:GO sont hors périmètre, et que ceux concernant le CS2 Limited Test sont également hors périmètre à l’heure actuelle
  Valve est certes faible sur la sécurité, mais en lisant largement la description complète sur HackerOne, personnellement je considérerais cela dans le périmètre
  Le fait qu’ils n’aient pas mis à jour l’onglet « Scope » pour exclure csgo.exe signifie qu’on ne peut pas vraiment se fier à cet onglet seul
  Cela dit, Valve devrait vraiment mettre cette partie à jour

  • Comme Valve ne répond même pas à une simple demande demandant si c’est dans le périmètre, impossible de savoir
    Cela dit, je suis d’accord avec la conclusion, et cela me paraît cohérent