1

I'm trying to use FFMPEG to pipe a HLS stream to TVHEADEND. But I'm unable to make it work as it keeps getting some Host not found, No route to host and TLS handshake errors.

To test it out I run this command replacing privateurl.com with my private streaming URL.

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

This works perfectly on windows (FFMPEG build 3.4.2), but on my Debian Server (Proxmox) I'm unable to have a stable connection with the exact same command. I tested it with FFMPEG version 3.2.12-1~deb9u1 and with ffmpeg version 3.4.4 inside a LXC container with in both cases the same result. As HLS is made out of chunks of smaller ts streams it seems that it randomly is unable to connect to some of the chunks claiming different kind of errors that seem like a bad connection to the server, but why? Both Windows and Linux Server are connected to the same Router, and the Server is even connected directly via ethernet (Tried even changing the cable) but it still is unable to have a stable connection to the stream. Intermitently it is able to connect and stream a chunck, but then it stops randomly on other chunks. The error output of FFMPEG from the Server looks like this:

...
[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.
...

The same goes for VLC. On windows I play the stream and it works perfectly, without any errors. If I run VLC on the Server side, the stream intermitently works for short bursts, and the console gets spammed with TLS and No route to host errors like this:

...
[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
...

I tried using traceroute, tcptraceroute, ping to the privateurl.com and it's port, and as much as I try to get an error using those commands, it always works perfectly.

So right now I'm completely out of ideas of how to make this work or what to try out to find out what is causing the issue. To me it looks like the TLS stack in Linux is just broken or it's a FFMPEG error, but I just don't know why it works in Windows but not on my Linux Server.

Anybody has an idea?

5
  • Despite that traceroute and so are working, this "no route to host" indicates a network setting problem, and not a linux/ffmpeg problem. Could you strace your commands? So you would be able to see, what exactly it tries to connect. Maybe the protocol is here a little bit more complex.
    – peterh
    Oct 13, 2018 at 16:35
  • I have a feeling it might be due to IPv6. On the Proxmox server I have a static IPv4 IP, but no IPv6 set. It seems like the DNS though is returning IPv6 IPs. My best guess is that FFMPEG is trying to use the IPv6 IP fails, and randomly from whatever reason it uses IPv4. On my Windows PC I have IPv6 completely dissabled, that's why it works there properly. I'll try to disable IPv6 completely if that's possible on the Server and see if it gets fixed. Oct 13, 2018 at 17:16
  • Well, the poison of the ipv6 is coming for us. What I do to fight against the ipv6 poison are: 1) I compile it out from the kernel (all other ways to eliminate it are fake, you need kernel recompilation. Also the linux kernel core development is infected, and it is their black action) 2) if it doesn't go (for example, in paravirtualized vps hosting), then I use a trivial script running on all boot to remove all ipv6 addresses from all interfaces 3) I trick all my routers and dns servers to not resolve ipv6 addresses and to not forward any ipv6 packets.
    – peterh
    Oct 13, 2018 at 17:47
  • Probably in some years, the moment will come as I will need to give up the fight, but I will resist until the last shot.
    – peterh
    Oct 13, 2018 at 17:47
  • 1
    If you have no better option, then start a local, caching-only bind, it has an option to resolve only ipv4. In the resolv.conf, you can't exterminate the ipv6 resolution (also the glibc core development is infected, if you would ask them, "why you need to support, and make even obligatory to use this crap?", they wouldn't even understand your question and they would think, you are bad).
    – peterh
    Oct 13, 2018 at 17:52

1 Answer 1

0

So finally the mystery got solved. Disabling IPv6 fixed the problem.

I disabled IPv6 by adding to /etc/sysctl.conf

The lines:

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

Please note that this is more a workaround as a real fix. Configuring properly IPv6 should also fix this. But in my case disabling IPv6 was more than enough for now.

Thanks @peterh for extra input on this topic. I hope that there will be better error messages in the future to differentiate IPv4 from IPv6.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .