1385030 - WebRTC TURN over HTTP Proxy requires local DNS resolution

Status: RESOLVED DUPLICATE of bug 1239006

(Core :: WebRTC: Networking, defect, P3)

Description

[Balwant Bisht]

Attachment: webrtc page.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

There are few cases

1) Firefox is running on a system behind HTTP proxy, TURNS url is passed to establish TURN/TLS relay
a) system can resolve TURN domain
b) system cannot resolve TURN domain

2) Firefox is running on a system behind proxy, TURN TCP url is passed to establish the TURN/TCP relay
a) system can resolve TURN domain
b) system cannot resolve TURN domain


Actual results:

1) a & b: Firefox not able to gather any candidate from TURN server and WebRTC connection failed

2a) Firefox able to connect with TURN/TCP relay

2b) Firefox not able to gather any candidate from TURN server and WebRTC connection failed


Expected results:

Firefox should connect using TURN/TCP or TURN/TLS in all cases via HTTP proxy server. In case of no domain resolution, Firefox should send CONNECT with hostname to proxy server and let it resolve the domain.

Comment 1

[Alex Chronopoulos [:achronop]]

Nils, could you verify or not the above description?

Comment 2

[Rob Swain]

Similar to bug #1202451: I was testing this scenario over the past few days at it is still present in both ff 54 and mozilla-central master code from yesterday.

I had two VirtualBox VMs, one with only an 'internal network' interface configured with a static LAN IP and the other with both an 'internal network' interface with static LAN IP and a NAT interface. On the second I installed a squid proxy that allowed HTTP and HTTPS tunnelling via HTTP CONNECT requests. I configured the Firefox on the first to use that squid proxy on the LAN IP of the proxy VM. As such, the Firefox VM did not have any DNS.

My observation was that when trying to use the TURN server via a domain name was that DNS failed which caused the candidate to be discarded. Looking in the code it looks like the code paths for resolution failure bail out before initialising the candidate. This would need to be changed but it looked a bit non-trivial as the initialisation uses information from a socket address structure which is populated only when knowing the IP of the remote candidate I think.

I added the domain and its IP into /etc/hosts as a quick test. In that case, the HTTP CONNECT was sent to the proxy and eventually Firefox could connect out to the TURN server but there was some credentials error which could have been my fault or could be a legitimate bug - noting it here in case it provides a lead during later investigations. The code also seemed to get stuck in a strange state whereby it would repeatedly log a call to one of the getaddr functions. I don't remember if it was nr_socket_wrapped_getaddr or nr_socket_proxy_tunnel_getaddr but I think it was one of those two.

Comment 3

[Ca N]

Testing with FF 55 shows similar issues as above commenters.  Stun/turn hostname doesn't seem to be able to resolve over web proxy.  My machine does not have functional DNS and is configured for web proxy over lan, no gateway to internet.

Comment 4

[Nils Ohlmeier [:drno]]

Yes our ICE can't differentiate right now between running with a HTTP proxy which can do the DNS resolution for us and the normal use case.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 6

[Pascal BORSCHNECK]

For information, I faced a similar problem with a bank partner and it's DNS corporate VERY limited to corporate server resolution.

Chrome: OK WebRTC sends the TURN resolution to the PROXY.
Firefox: seems to try to resolve it locally instead of using the PROXY !?!?

Note: copying this also to https://bugzilla.mozilla.org/show_bug.cgi?id=1239006

Comment 7

[albert.manukyan]

I faced a similar problem too with corporate partners with sev-reflective.

Chrome is ok and webrtc sends the TURN resolution.
FireFox stuck with ICE error and candidate distribution

Guys is there any activity on this ? Folks from FF when are you going to work on it?

Comment 8

[Byron Campen [:bwc]]

Once bug 1203503 lands, it might make sense to look at this.

Comment 9

[albert.manukyan]

any progress on 1203503 @Byron ?

Comment 10

[Nils Ohlmeier [:drno]]

(In reply to Byron Campen [:bwc] from comment #8)
> Once bug 1203503 lands, it might make sense to look at this.

I was actually hoping that we would solve this issue through bug 1203505. Not sure if it is too late for that.

Comment 11

[Byron Campen [:bwc]]

(In reply to Nils Ohlmeier [:drno] from comment #10)
> (In reply to Byron Campen [:bwc] from comment #8)
> > Once bug 1203503 lands, it might make sense to look at this.
> 
> I was actually hoping that we would solve this issue through bug 1203505.
> Not sure if it is too late for that.

This is probably going to require more work down in nICEr than bug 1203505, so it makes sense to keep them separate.