Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Native ICE TURN failover fails when the servers use different credentials

Aperta
  • Qualcosa non va?
#445 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@PerryLink ci sta già lavorando.

Dal 9/10/2026.

  • #446 di @PerryLink — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
66/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Ambito
networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
C++
Stelle
10k
Fork
747
Merge medio
5g 19h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ValveSoftware/GameNetworkingSockets

Tutte le issue di ValveSoftware/GameNetworkingSockets

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.