Chrome fails to establish a ssltcp connection
Reported by
hugo.sob...@gmail.com,
Nov 10 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 Steps to reproduce the problem: 1.chrome must be in a network with all udp blocked 2.server establish a webrtc call with ssltcp candidates in port 443 a=candidate:1 1 ssltcp 2130706431 13.69.192.240 443 typ host But chrome only gets the local IP in candidates (because stun server is not accessible via UDP): a=candidate:1368117595 1 udp 2122260223 172.24.42.2 63938 typ host generation 0 network-id 1 network-cost 10 a=candidate:1368117595 2 udp 2122260222 172.24.42.2 63939 typ host generation 0 network-id 1 network-cost 10 a=candidate:520629675 1 tcp 1518280447 172.24.42.2 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=candidate:520629675 2 tcp 1518280446 172.24.42.2 9 typ host tcptype active generation 0 network-id 1 network-cost 10 What is the expected behavior? Chrome must establish a ssltcp connection with 443 What went wrong? Chrome establish the connection for about 100 milliseconds and disconnects it. In Chrome logs we can see: [23344:6088:1110/115848:WARNING:tcpport.cc(408)] Jingle:Conn[085FB690:audio:xbEKHpp8:1:0:local:tcp:172.24.42.x:9->18RVMZlb:1:2130706431:local:ssltcp:13.69.192.x:443|---W|0|0|6520964870282674174|-]: Dropping connection as TCP socket bound to IP 83.240.179.x, different from the local candidate IP 172.24.42.x Did this work before? No Does this work in other browsers? Yes Chrome version: 54.0.2840.71 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 computer private IP: 172.24.42.x computer public IP: 83.240.179.x Server public IP: 13.69.192.x
,
Nov 14 2016
,
Nov 14 2016
,
Nov 15 2016
+honghaiz Have you ever seen this before? It appears that the TCP socket's bound address ends up as the PC's public address, which doesn't make much sense to me.
,
Nov 15 2016
That's strange. Can you set the webrtc native log level to INFO and upload a new log? The current log level is WARNING so we don't see any INFO logs in the native code.
,
Nov 15 2016
Which you can do using "chrome --enable-logging --vmodule=*/webrtc/*=1", by the way.
,
Nov 15 2016
That seems likely. From the log, it looks like this happens with all TCP/TURN ports, not just the SSL-TCP ports. Honghai, the main purpose of these checks is to ensure that we don't create two equivalent ports for the same network interface, correct? If so, this checking could be implemented in a different way that allows the bound address to mismatch the network address.
,
Nov 15 2016
I was trying to collect more information about this issue because the original log contains very little information about the native code. Now that the issue reporter provided more information, I think he/she can try to uninstall the TMG client to see if that resolves the issue.
,
Nov 15 2016
Unfortunately if I deactivate or uninstall the TMG client, it is not possible to access any external IP from this network. In other networks with TMG client deactivated it works.
,
Nov 16 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, Nov 11 2016