Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Native ICE TURN failover fails when the servers use different credentials

Abierto
#445 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@PerryLink ya está trabajando en esto.

Desde el 9/10/2026.

  • #446 de @PerryLink — abierto
  • #447 de @sashakosti — cerrado sin fusionar

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
66/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Área
networking

Línea de trabajo

Start at STUNRequestCallback_AllocateRelay in src/ice.cpp and trace where m_strTURNRealm, m_strTURNNonce and m_arrTURNKey are set during the 401 challenge and read when building the next Allocate. First fix is resetting those members before advancing to the next server; done means a second TURN server with different realm/credentials is reached with its own key after the first times out. Then evaluate the second part of the report: whether non-timeout error responses should also advance the server list instead of marking relay failed, and check existing TURN/ICE tests or a two-server repro for coverage.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I think I found a problem with TURN failover in the native ICE client.

If the first TURN server answers the Allocate with a 401 and then stops responding, the client times out and moves on to the second server. But it seems to keep the realm, nonce and key from the first server (m_strTURNRealm, m_strTURNNonce, m_arrTURNKey), so the request to the second server has the right username but the wrong realm and key. The second server answers 401, the client treats that as wrong credentials, and relay is marked as failed.

To reproduce, configure two TURN servers with different credentials or realms, where the first one answers the initial 401 challenge but drops the authenticated Allocate. With peers that can only connect through a relay, the connection fails. If the first server never answers at all, failover works fine.

Clearing m_strTURNRealm and m_strTURNNonce before trying the next server in STUNRequestCallback_AllocateRelay fixed it for me.

Related: the second server is only tried after a timeout. If the first server rejects the request, for example because of a wrong password, relay is marked as failed and the second server is never contacted. That means a backup server only helps when the first one is down, not when it is up and refusing us. Shouldn't an error response also fall through to the next server?

Lenguaje dominante
C++
Estrellas
10k
Forks
750
Merge medio
5 d 19 h
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ValveSoftware/GameNetworkingSockets

Todos los issues de ValveSoftware/GameNetworkingSockets

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.