Chrome and TURN/TCP over IPv6

[Lorenzo Miniero]

Hi all,

does Chrome support TURN/TCP over IPv6? It looks like it's not working for us.

I looked around in some older posts and found this: https://bugs.chromium.org/p/webrtc/issues/detail?id=2554

which, although apparently being closed, does seem to be in part in line with what we're experiencing. In fact, our TURN server (a coturn instance) resolves to both an IPv4 and an IPv6 address, and it does indeed look like Chrome is only trying to connect via IPv6. Anyway, it fails to do do that with transport=tcp. Forcing transport=udp gets it to work, but via IPv4 (which seems to contradict the above issue).

When I say it fails with TCP, I mean that we do see the TCP connection coming in both in the TURN server logs and on Wireshark, but then nothing happens (Chrome never sends any Allocate request), and after 45 seconds Chrome just hangs up the connection, as I guess some application level timeout kicks in. It doesn't look like an IPv6 connectivity or routing problem, because a test from the machine hosting the browser with turnutils_uclient trying to do the same thing works as expected, on both UDP and TCP.

Is this actually unsupported in Chrome right now, or are we doing something wrong?

Thanks,

Lorenzo

[Taylor Brandstetter]

I think you're running into this: https://bugs.chromium.org/p/webrtc/issues/detail?id=8972

A regression introduced in M62 started causing TCP sockets bound to temporary IPv6 addresses to be discarded. Fix is coming soon, will ship in M67.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c26f26c1-2b64-4455-81e6-4e96e85b9cfd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

Thanks for the pointer!

Lorenzo

Il giorno lunedì 19 marzo 2018 19:50:03 UTC+1, Taylor Brandstetter ha scritto:

I think you're running into this: https://bugs.chromium.org/p/webrtc/issues/detail?id=8972

A regression introduced in M62 started causing TCP sockets bound to temporary IPv6 addresses to be discarded. Fix is coming soon, will ship in M67.

On Sat, Mar 17, 2018 at 7:45 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

Hi all,

does Chrome support TURN/TCP over IPv6? It looks like it's not working for us.

I looked around in some older posts and found this: https://bugs.chromium.org/p/webrtc/issues/detail?id=2554

which, although apparently being closed, does seem to be in part in line with what we're experiencing. In fact, our TURN server (a coturn instance) resolves to both an IPv4 and an IPv6 address, and it does indeed look like Chrome is only trying to connect via IPv6. Anyway, it fails to do do that with transport=tcp. Forcing transport=udp gets it to work, but via IPv4 (which seems to contradict the above issue).

When I say it fails with TCP, I mean that we do see the TCP connection coming in both in the TURN server logs and on Wireshark, but then nothing happens (Chrome never sends any Allocate request), and after 45 seconds Chrome just hangs up the connection, as I guess some application level timeout kicks in. It doesn't look like an IPv6 connectivity or routing problem, because a test from the machine hosting the browser with turnutils_uclient trying to do the same thing works as expected, on both UDP and TCP.

Is this actually unsupported in Chrome right now, or are we doing something wrong?

Thanks,

Lorenzo

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

I forgot to mention, this bug only affects iOS and OS X.

[Lorenzo Miniero]

Il giorno lunedì 19 marzo 2018 19:52:31 UTC+1, Taylor Brandstetter ha scritto:

I forgot to mention, this bug only affects iOS and OS X.

Mh, not sure it's this then, as I'm a Linux user and so is the colleague that tested with me... We haven't tried from Windows machines though.

Lorenzo

 

On Mon, Mar 19, 2018 at 11:49 AM, Taylor Brandstetter <dead...@google.com> wrote:

I think you're running into this: https://bugs.chromium.org/p/webrtc/issues/detail?id=8972

A regression introduced in M62 started causing TCP sockets bound to temporary IPv6 addresses to be discarded. Fix is coming soon, will ship in M67.

On Sat, Mar 17, 2018 at 7:45 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

Hi all,

does Chrome support TURN/TCP over IPv6? It looks like it's not working for us.

I looked around in some older posts and found this: https://bugs.chromium.org/p/webrtc/issues/detail?id=2554

which, although apparently being closed, does seem to be in part in line with what we're experiencing. In fact, our TURN server (a coturn instance) resolves to both an IPv4 and an IPv6 address, and it does indeed look like Chrome is only trying to connect via IPv6. Anyway, it fails to do do that with transport=tcp. Forcing transport=udp gets it to work, but via IPv4 (which seems to contradict the above issue).

When I say it fails with TCP, I mean that we do see the TCP connection coming in both in the TURN server logs and on Wireshark, but then nothing happens (Chrome never sends any Allocate request), and after 45 seconds Chrome just hangs up the connection, as I guess some application level timeout kicks in. It doesn't look like an IPv6 connectivity or routing problem, because a test from the machine hosting the browser with turnutils_uclient trying to do the same thing works as expected, on both UDP and TCP.

Is this actually unsupported in Chrome right now, or are we doing something wrong?

Thanks,

Lorenzo

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Srividhya Sathiyanarayan]

Hi Lorenzo, Taylor,

I’m still encountering an issue with WebRTC over TCP/IPv6 while testing with my TURN server.
I am testing with a WebRTC-based client.

It works fine over TCP/IPv6 in Chrome on Linux.
But it fails with Error 701 – "Failed to Establish Connection" in both Mac Chrome and Windows Chrome (observed in chrome://webrtc-internals → icecandidateerror).

Other than my WebRTC client, I also tried Trickle ICE on Mac, and I still encounter the same Error 701.

I ran Chrome debug logs on Mac/Windows while running my client in IPv6 TCP, which show:
services/network/p2p/socket_tcp.cc:131 Error from connecting socket, result = -111 (ECONNREFUSED), destroying socket

For reference, I verified with the netcat tool from the Mac client machine: TCP/IPv6 connectivity works, so the network path is fine.
Also, TCP/IPv4 and UDP (both IPv4 and IPv6) work across all platforms without issues.

Is this a known issue with Chrome on Mac and Windows, or are we doing something wrong?
Any help would be greatly appreciated.

Thanks,
Srividhya