- La antigua desconexión
No user logon de Counter-Strike también se reproduce en CS2, y si te conectas al servidor demasiado rápido justo después de iniciar el juego, puede que no comience la validación del Steam ID
- La clave es que durante el inicio de
CS2.exe, el bucle levelload termina antes de tiempo antes de completar la validación de Steam3, y el servidor procesa la conexión con un Steam ID no validado
- En los logs de Esportal, incluso para usuarios normales se registró
STEAM USERID validated aproximadamente 1 minuto y 20 segundos después de conectarse, y en usuarios afectados la desconexión llegó 2 a 3 minutos después con STEAMAUTH failure code 8 y NETWORK_DISCONNECT_STEAM_LOGON
- Reinstalar el juego, verificar archivos, reiniciar Steam, reiniciar la PC o desactivar el WiFi no corrige la causa raíz; hay que abrir primero CS2 y esperar de 5 a 10 segundos en el menú principal
- Esportal corrigió el 10 de enero de 2024 el comportamiento de ejecutar
steam://connect/<IP>:<Port> antes de que CS2.exe terminara de inicializarse por completo, y después de eso la proporción de tickets relacionados cayó a 0%
El problema repetido de No user logon
- La desconexión
No user logon de Counter-Strike es conocida como un problema que ocurre aleatoriamente durante la partida, y fue reportada repetidamente en varios foros y en los foros oficiales de soporte de Valve desde 2008 hasta 2023
No user logon y No steam logon, que aparece en algunas publicaciones, podrían ser técnicamente nombres distintos para la misma causa raíz- Las soluciones ampliamente difundidas en internet no arreglan la causa raíz
- Reinstalar el juego
- Verificar los archivos del juego
- Reiniciar Steam
- Reiniciar la computadora
- Desactivar el WiFi
- CS2 reemplazó a CS:GO el 27 de septiembre de 2023, y los usuarios normales ya no pueden jugar CS:GO
- El alcance del programa de bug bounty de HackerOne de Valve no incluía
cs2.exe, y los reportes del CS2 Limited Test también aparecían como fuera de alcance
Aumento repentino de reportes en Esportal
- Esportal ya había sufrido este problema en CS:GO, y según sus registros la primera vez fue el 2019-11-15 19:15:32 CET, mientras que el último caso en CS:GO fue el 2023-09-26 21:38:01 CET, un día antes de que fuera reemplazado por CS2
- Al principio de CS2 parecía que el problema había desaparecido, pero en la primera semana de enero de 2024 aumentaron los reportes de usuarios
- 2024-01-03: 6% de los tickets diarios
- 2024-01-05~06: 18%
- 2024-01-07: 23%
- 2024-01-08: 10%
- 2024-01-09: 9%
- Los reportes se concentraban sobre todo entre las 13:00 y 17:00 CET, lo que corresponde a 04:00 a 08:00 en Washington, donde está Valve
- Antes, los reportes se distribuían de forma uniforme a lo largo del día, pero el problema observado recientemente se concentraba en una franja horaria específica
- Jugadores fuera de Esportal también sufrían el mismo problema, así que no era un problema exclusivo de una plataforma concreta
Síntomas: validación tardía de Steam y skins que desaparecen
- El error
No user logon observado ocurría 2 a 3 minutos después de que el jugador se conectaba al servidor del juego, y ese intervalo de tiempo era bastante constante
- Un colega comentó: “durante unos minutos después de entrar al juego, en CS2 no se ven las skins”, y jugadores fuera de Esportal también reportaron la ausencia de skins
- Como las skins están vinculadas a la propiedad del Steam ID, si las skins personales no aparecen de inmediato, es posible que el jugador todavía no haya sido autenticado correctamente a través de Steam
- En los logs de usuarios normales,
STEAM USERID validated aparecía aproximadamente 1 minuto y 20 segundos después de la conexión
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")
- En logs antiguos, previos al 3 de enero de 2024, la validación de Steam terminaba 2 a 3 segundos después de la conexión
- Durante el horario nocturno de Washington era posible reproducirlo directamente, mientras que durante el horario diurno de Washington no se reproducía
NETWORK_DISCONNECT_STEAM_LOGON y failure code 8
- En los logs de usuarios afectados, la conexión se cortaba con
NETWORK_DISCONNECT_STEAM_LOGON justo después de 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")
- Se estima que
NETWORK_DISCONNECT_STEAM_LOGON es el identificador interno del mensaje No user logon que ve el usuario
- Se encontró la cadena
STEAMAUTH: Client %s received failure code %d en libengine2.so, y se comparó junto con sv_steamauth.cpp del código filtrado de CS:GO y resultados de ingeniería inversa
- La función correspondiente en CS2 desconecta al cliente según el valor de
eAuthSessionResponse
1: k_EAuthSessionResponseUserNotConnectedToSteam7: k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed8: k_EAuthSessionResponseAuthTicketInvalid
- Todo indica que el failure code
8 corresponde a k_EAuthSessionResponseAuthTicketInvalid, que aparece cuando falla la validación de Steam3
Flujo de validación de Steam3
- El cliente del juego
CS2.exe entrega su Steam ID al conectarse a un servidor de juego
- El servidor del juego consulta a los servidores de Steam3 para verificar si ese Steam ID es válido y si posee el juego
- Mientras espera la respuesta de validación, el jugador puede seguir jugando en el servidor, pero puede que no vea sus skins personales
- Si los servidores de Steam3 responden “yes”, el servidor del juego confía en esa información y puede aplicar datos personales como las skins
- Si los servidores de Steam3 responden “no”, el servidor del juego desconecta al cliente con
NETWORK_DISCONNECT_STEAM_LOGON
- Durante el horario nocturno de Washington, cuando las respuestas de Steam3 se volvían lentas, completar la validación tomaba alrededor de 1 minuto y 20 segundos
Validación de confianza de CS2.exe y el cliente de Steam
- Que un Steam ID sea válido no basta para demostrar que esa instancia de
CS2.exe pertenece al juego de la cuenta de Steam iniciada en la misma máquina
CS2.exe debe conectarse con Steam.exe en la misma máquina para confirmar que el Steam ID enviado coincide con la cuenta de Steam actualmente iniciada- Cuando
Steam.exe confirma esa coincidencia, los servidores de Steam3 guardan temporalmente que ese Steam ID es válido para CS2
- Entre las posibles razones por las que Steam3 puede responder “no”, las dos más cercanas al problema real se reducen a estas
- La instancia de
CS2.exe no es de confianza
- Los servidores de Steam3 todavía no conocen la información del Steam ID para esa instancia de
CS2.exe
Pista del lado del cliente: NETWORK_DISCONNECT_LOOPSHUTDOWN
- En los logs de error aparece primero
NETWORK_DISCONNECT_LOOPSHUTDOWN antes de 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")
- Después de
NETWORK_DISCONNECT_LOOPSHUTDOWN, el juego intenta reconectarse automáticamente 5 segundos después
- Esa primera desconexión no la inicia el servidor del juego, sino
CS2.exe mismo
- Por eso, la causa raíz no estaba en el servidor, sino del lado del cliente del juego
El bucle levelload de Source 2 y el orden de inicialización
- El motor Source 2 ejecuta un solo bucle activo a la vez, y cada bucle repite tareas en segundo plano y manejo de entrada del usuario hasta completar un objetivo específico
- El último bucle que se ejecuta tras iniciar
CS2.exe es el bucle game, encargado de la interacción real del menú y del gameplay
- En la salida de consola, justo antes de cambiar al bucle
game, el estado de autenticación de Steam aparece como 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 es el bucle de inicialización que se ejecuta al iniciar CS2, y aparentemente carga pantallas iniciales como el video de introducción y el menú principal, incluso si no se trata de un mapa real- Una de las últimas tareas de
levelload es iniciar la validación de Steam3 desde CS2.exe a través de Steam.exe
Causa directa del bug
- CS2 solo puede considerarse completamente inicializado cuando el bucle
levelload termina con éxito
- Si la inicialización de
levelload se interrumpe antes de completarse, la validación de Steam3 no llega a empezar
- Una instancia de
CS2.exe en ese estado queda rota, y no se recupera simplemente hasta volver a reiniciar CS2
- El flujo del bug es el siguiente
- Inicia
CS2.exe
- Comienza el bucle
levelload
levelload termina antes de tiempo antes de iniciar la validación de Steam3- El bucle
game se conecta al servidor con un Steam ID no validado
- El servidor del juego consulta a Steam3
- Hasta aproximadamente 2 minutos y 50 segundos después, recibe una respuesta de fallo y desconecta con
No user logon
- Aunque aquí se describe usando el ejemplo y los nombres de CS2, existe un bug equivalente en CS:GO y Counter-Strike: Source; solo cambian el nombre técnico y la implementación
Formas de conexión que disparan el bug
- El problema es una condición de carrera (race condition) según la forma en que se inicia CS2
- La manera de provocar el bug casi con total seguridad es conectarse directamente a un servidor de juego cuando CS2 no está abierto
- Las formas de conexión más riesgosas son estas
- Conectarse a un servidor desde un navegador de servidores externo cuando CS2 no se está ejecutando o acaba de arrancar
- Unirse a un amigo desde la lista de amigos de Steam cuando CS2 no se está ejecutando o acaba de arrancar
- Conectarse directamente desde fuera usando el protocolo del navegador de Steam, como
steam://connect/127.0.0.1:27015
- Si haces alguna de esas acciones antes de que CS2 termine de inicializarse por completo, la probabilidad aumenta todavía más
- La proporción de causas se resume con la analogía: “90% la forma de iniciar Counter-Strike, 3% la velocidad de la computadora, 3% la velocidad del usuario, 3% la fase de la luna y 1% un problema real de configuración del usuario”
La solución real
- Cosas que no debes hacer
- Reinstalar el juego
- Verificar los archivos del juego
- Reiniciar Steam
- Reiniciar la computadora
- Desactivar el WiFi
- Conectarte a un servidor de juego desde fuera antes de que CS2 arranque
- En su lugar, primero hay que iniciar CS2 y esperar lo suficiente antes de conectarse a un servidor de juego
- La referencia es esperar hasta que aparezca la consola del juego o, después de ver el video de introducción, esperar 5 a 10 segundos
- Para comprobarlo con certeza, después de iniciar CS2 puedes escribir
status en la consola del juego y revisar la siguiente línea
[EngineServiceManager] @ Current : game
Resultado de la corrección en Esportal
- La razón por la que el usuario afectado
Bob logró validar con éxito 9 minutos después del primer intento es que reinició CS2, y esa vez el bug no se activó por mala suerte
- Una vez que un Steam ID queda validado, no vuelve a fallar más tarde dentro de la misma instancia del juego, a menos que se cierre el cliente de Steam
- Hasta el 10 de enero de 2024, Esportal hacía que el servidor de matchmaking conectara al jugador mediante
steam://connect/<IP>:<Port> en cuanto aparecía el proceso CS2.exe, incluso antes de que terminara su inicialización completa
- Después de corregir ese comportamiento y desplegarlo para todos los jugadores de Esportal, se detuvieron los tickets de usuarios relacionados
- La proporción de tickets diarios por
No user logon había subido hasta 23% el 2024-01-07, pero cayó a 0% entre el 2024-01-10 y el 2024-01-12
1 comentarios
Opiniones de Hacker News
El flujo del diagrama se parece más a lo que Steam llama Session Tickets, y en realidad es un poco más sutil.
El cliente del juego le pide a los servidores de Steam un ticket de sesión y luego le entrega al servidor del juego un ticket que prueba que es un Steam ID específico.
Después, el servidor del juego debe verificarlo en línea con la Web API de Steam para confirmar que el ticket no se haya usado varias veces ni haya sido manipulado.
Suena como si el cliente de CS2 no estuviera manejando correctamente la respuesta demorada en el proceso de obtener un ticket de sesión.
El flujo está detallado aquí: https://partner.steamgames.com/doc/features/auth#3
Si funcionara como en el diagrama del artículo, sería bastante preocupante, porque un atacante podría competir por entrar a un servidor usando el Steam ID de la víctima.
El problema parece estar en que el juego se interrumpe antes de crear realmente el ticket de sesión, o mientras espera una respuesta lenta del servidor de Steam, y se conecta al servidor del juego sin ticket.
El artículo es excelente, pero el proceso de investigación y la conclusión no encajan del todo.
Decir “Cómo arranca Counter-Strike: 90% de responsabilidad” y, al mismo tiempo, decir que jugadores de todo el mundo tienen el mismo problema también fuera de Esportal y que se confirmó que era por el mantenimiento de medianoche en Washington, difícilmente pueden ser ambas cosas ciertas.
Si el 90% de la responsabilidad fuera la forma de ejecución, el problema no se habría distribuido alrededor del horario de mantenimiento.
La clave parece estar en “la verificación del Steam ID empieza justo antes de que arranque el game loop” y “si la inicialización de levelload no termina, la verificación de Steam3 queda como último paso y no se inicia”.
Es decir, si durante el horario de mantenimiento los servidores steam3 se vuelven muy lentos, este proceso se alarga y aumenta la posibilidad de iniciar el juego en ese intervalo y cortar el loop.
Por eso, “Cómo arranca Counter-Strike” también es correcto, pero una expresión como “estado de la Luna: 3% de responsabilidad” en la práctica apunta al horario de mantenimiento, así que queda un poco desalineada.
También sería bueno que el consejo incluyera algo como “entre las 13 y 17 h CET es horario de mantenimiento de Valve, así que espera unos minutos más”.
En cualquier caso, he sufrido este problema, y la solución de “espera un poco a que termine de cargar” es la más práctica y razonable que he oído hasta ahora.
En CS:GO el mismo problema también ocurría sin relación con el horario de mantenimiento, y en CS2 solo se observó durante el horario de mantenimiento.
Al final, puede que la naturaleza del bug fuera distinta entre CS:GO y CS2, pero como CS:GO fue reemplazado por CS2, ya no hay forma de demostrarlo.
Hace tiempo, cuando Steam no existía, hice una herramienta que mostraba la lista de jugadores activos y puntajes para poder ver en qué servidor estaba conectado un amigo y entrar directamente.
Mientras la hacía, envié un paquete incorrecto al servidor que estaba usando para pruebas y el servidor se cayó.
Todavía tengo el código fuente escrito en Delphi, y si aún quedan bugs de hace 10 años, me pregunto si eso todavía podría tumbar servidores.
El bug real es que completar la autenticación no sea un requisito obligatorio para iniciar multijugador que no sea LAN.
Una forma más rápida y robusta podría ser que el cliente de Steam obtenga de Valve un token firmado válido por algunas horas, lo guarde y envíe ese token cada vez que se conecte a un servidor de juego.
El servidor del juego podría validarlo localmente con un certificado público emitido por Valve y distribuido junto con el contenido del servidor.
Algunos párrafos se sienten como “ponerle un sombrero a un sombrero”.
Encima de un párrafo que ya era medio meme, se acumula más sarcasmo, y algo que funciona mejor cuando es sutil termina sintiéndose excesivo.
Como dijeron otros, sería mejor llegar más rápido al punto.
Lo leí con mucho gusto. Me pregunto si se podría investigar de la misma forma por qué el cliente del juego crashea de repente.
También me pregunto si la verificación de integridad del ejecutable se ejecuta incluso durante la partida, y si cuando una de esas verificaciones falla durante la ejecución aparece otro mensaje de desconexión.
Parece algo digno de recompensa, como el artículo que analizaba el problema de los tiempos de carga demasiado largos de GTA V: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
En teoría los crasheos se pueden investigar, pero Valve no guarda los reportes de crasheo en disco, los envía al servidor.
Si no los capturas en tiempo real con un debugger conectado, el análisis es más difícil, y por VAC se vuelve delicado, aunque no imposible. Basta con desactivar VAC.
Me parece considerado que al inicio del artículo haya un resumen para quienes llegan buscando cómo resolver el problema.
Pero justo después dice “lo que no debes hacer”, y la acción realmente útil queda escondida en una frase a mitad de un texto kilométrico.
Sería mejor incluir la solución alternativa en el resumen.
Lo digo porque tengo metido en la cabeza el gusto por la escritura al estilo Strunk and White, así que puedes ignorarlo si quieres.
Si quieres feedback, recomiendo editarlo con mano dura para que sea mucho más directo y conciso.
Se puede escribir un texto largo, pero después de unos minutos, con tantas explicaciones adicionales y anécdotas acumuladas, perdí bastante rápido el hilo principal.
Con la imagen de referencia a Inception incluida, se siente más como una acumulación de cosas sin mucha relación entre sí que como un texto informativo.
Piensa qué quieres decir, dilo y luego vuelve a revisar si de verdad dijiste solo eso.
Lo demás se parece más a practicar mecanografía que a escribir. Si tienes 3 o 4 cosas que decir, simplemente di esas cosas.
El artículo fue excelente, pero me quedan algunas preguntas.
¿levelloadloop se ejecuta solo al iniciar el juego, y no al entrar a un servidor ni al cargar un mapa?
Si el problema es que el loop termina antes de que empiece el proceso de autenticación de Steam, ¿por qué importa la lentitud causada por el mantenimiento?
El nombre de este loop parece estar relacionado con juegos single-player como Portal, y en esos juegos, donde se cambia de nivel sin interrupciones, ese nombre resulta mucho más natural.
En la 2 sí hay un hueco en la explicación, y no sé la respuesta.
Pero es seguro que este método arregla el problema. Es muy probable que los detalles de la conclusión estén incompletos, pero por ahora no siento necesidad de profundizar más.
El texto del programa de recompensas de Valve dice que incluye “la plataforma Steam y los juegos actuales desarrollados/publicados por Valve”.
También dice que desde el 14 de junio de 2023 a las 10:00 a. m. PDT los nuevos reportes de CS:GO están fuera de alcance, y que los reportes de CS2 Limited Test también están fuera de alcance actualmente.
Es cierto que Valve es flojo en seguridad, pero si leo de forma amplia toda la descripción de HackerOne, personalmente lo consideraría dentro del alcance.
Como no actualizaron la pestaña “Scope” para excluir
csgo.exe, significa que no se puede confiar solo en esa pestaña.Aun así, Valve debería actualizar esa parte, por favor.
Pero coincido con la conclusión, y tiene sentido.