Obtendo erro de conexão freqüente: sem rota para host e erros de handshake da sessão TLS com HLS. Mas funciona no Windows!

1

Estou tentando usar o FFMPEG para canalizar um fluxo HLS para o TVHEADEND. Mas não consigo fazê-lo funcionar, pois ele continua recebendo alguns erros de Host Host Not Found, No Route to Host e TLS Handshake.

Para testá-lo, executo esse comando substituindo o privateurl.com por meu URL de streaming privado.

ffmpeg -user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100Safari/537.36" -i "https://privateurl.com:8443/stream/stream.m3u8" -c copy -f mpegts test.ts

Isso funciona perfeitamente no windows (FFMPEG build 3.4.2), mas no meu servidor Debian (Proxmox) eu não consigo ter uma conexão estável com o mesmo comando exato. Eu testei com FFMPEG versão 3.2.12-1 ~ deb9u1 e com ffmpeg versão 3.4.4 dentro de um contêiner LXC com em ambos os casos o mesmo resultado. Como o HLS é feito de pedaços de fluxos ts menores, parece que ele é aleatoriamente incapaz de se conectar a alguns dos fragmentos que reivindicam diferentes tipos de erros que parecem ser uma conexão ruim com o servidor, mas por quê? Tanto o Windows quanto o Linux Server estão conectados ao mesmo Roteador, e o Servidor está até conectado diretamente via ethernet (Tentei até trocar o cabo), mas ainda assim não é possível ter uma conexão estável com o fluxo. Intermitentemente, é capaz de conectar e transmitir um chunck, mas depois pára aleatoriamente em outros trechos. A saída de erro do FFMPEG do Servidor se parece com isto:

...
[tls @ 0x7f49f08eea40] The specified session has been invalidated for some reason.
[tcp @ 0x55efbe455aa0] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[hls,applehttp @ 0x7f49f08ee160] Opening 'https://privateurl.com:8443/stream/stream_982112.ts' for reading
[tcp @ 0x55efbe02fbc0] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[tcp @ 0x55efbe503280] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[tls @ 0x55ba15827580] The TLS connection was non-properly terminated.
...

O mesmo vale para o VLC. No windows eu jogo o stream e funciona perfeitamente, sem erros. Se eu executar o VLC no lado do servidor, o fluxo funciona intermitentemente para rajadas curtas, e o console recebe spam com TLS e sem rota para hospedar erros como este:

...
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
[00007fec88000ef0] gnutls tls client error: TLS handshake error: Error in the push function.
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
[00007fec88000ef0] gnutls tls client error: TLS handshake error: Error in the push function.
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
...

Eu tentei usar traceroute, tcptraceroute, ping para o privateurl.com e é port, e por mais que eu tente obter um erro usando esses comandos, ele sempre funciona perfeitamente.

Então, agora estou completamente sem idéias de como fazer isso funcionar ou o que tentar descobrir o que está causando o problema. Para mim, parece que a pilha TLS no Linux está quebrada ou é um erro FFMPEG, mas eu simplesmente não sei porque funciona no Windows, mas não no meu servidor Linux.

Alguém tem uma ideia?

    
por Robert Koszewski 13.10.2018 / 14:19

1 resposta

0

Então, finalmente, o mistério foi resolvido. A desativação do IPv6 corrigiu o problema.

Eu desativei o IPv6 adicionando /etc/sysctl.conf

As linhas:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

Por favor, note que esta é mais uma solução alternativa como uma correção real. Configurando corretamente o IPv6 também deve corrigir isso. Mas no meu caso, desabilitar o IPv6 foi mais do que suficiente por enquanto.

Obrigado @peterh por uma contribuição extra sobre este tópico. Espero que, no futuro, haja melhores mensagens de erro para diferenciar o IPv4 do IPv6.

    
por 14.10.2018 / 20:02