Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Native ICE TURN failover fails when the servers use different credentials

Aberta
  • Algo errado?
#445 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
Meio dia
Facilidade para iniciantes
66/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Domínio
networking

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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?

Linguagem predominante
C++
Estrelas
10k
Forks
747
Merge médio
5d 19h
PRs com merge (30d)
1

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ValveSoftware/GameNetworkingSockets

Todas as issues de ValveSoftware/GameNetworkingSockets

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.