WebRTC: ICE candidates are still generated for VPN interface after it's disconnected
Reported by
loins...@gmail.com,
Jun 28 2016
|
|||||||||||||||||
Issue descriptionChrome Version : 51.0.2704.106, 53.0.2781.0 URLs (if applicable) : https://meetnow.myrpp.com/726859 OS version : Mac OS 10.11.5 Hardware : MacBook Pro (Retina, 15-inch, Mid 2015) Camera and mic : built-in FaceTime HD Additional software : Pulse Secure 5.1.5 (https://www.pulsesecure.net) Network (such as Cable/DSL/Dial up etc): Cable (Xfinity HSI) Audio/Video format (if applicable): n/a Special chrome flags (if applicable): n/a Behavior in Safari (if known): n/a Behavior in Firefox (if known): unknown Video issue, Audio issue, both, neither? both (ICE connectivity) Flash or HTML5? HTML5 What steps will reproduce the problem? (1) system with Pulse Secure VPN software installed but no VPN active (2) (optional) place a WebRTC call and observe the generated ICE candidates (3) bring up the VPN (4) (optional) place a WebRTC call and observe the generated ICE candidates (5) bring down the VPN (confirm that "netif -i" no longer lists the interface) (6) place a WebRTC call and observe the generated ICE candidates What is the expected result? (2) no ICE candidates are generated for the VPN interface (4) valid ICE candidates are generated for the VPN interface (6) no ICE candidates are generated for the VPN interface What is the actual result? (2) as expected (4) as expected (6) TCP host ICE candidates are generated for the former VPN interface address (10.10.0.161 in my enclosed example files). ICE candidate generation stalls, apparently waiting for binding and allocation requests sent on the former VPN interface to time out. The problem persists until the VPN is re-activated or until Chrome is quit and re-launched, at which point behavior returns to that of step "2".
,
Jul 11 2016
[triage]: Blum, looks like a product question. CC:ing some other appropriate people.
,
Jul 12 2016
From my experience with different VPNs, they tend to disconnect and re-connect from time to time for various reasons. How could we differentiate a case where a VPN has disconnected and is in re-connect state from a case where the VPN has been brought down by purpose? Wrt. (6) in actual result, am I assuming correctly that only generating the ICE candidates for the VPN interface stalls and other candidates are generated as expected?
,
Jul 28 2016
> From my experience with different VPNs, they tend to disconnect and re-connect from > time to time for various reasons. How could we differentiate a case where a VPN has > disconnected and is in re-connect state from a case where the VPN has been brought > down by purpose? I'd propose that any interface that is down, even temporarily, shouldn't be used to generate ICE clients while in a down state. > Wrt. (6) in actual result, am I assuming correctly that only generating the ICE > candidates for the VPN interface stalls and other candidates are generated as > expected? Yes, but it delayed the completion of candidate generation overall, which is particularly problematic for my application which interfaces with an element (MCU) that doesn't support trickle ICE, so the failure to complete candidate generation in a timely manner leads to the failure of the call.
,
Aug 9 2016
[triage] loinsrch@ in step 5, how long do you wait before doing step 6? I'm wondering if there is a delay before Chrome detects the interface is down.
,
Sep 9 2016
[triage] loinsrch@: Can you answer comment #5? CC list: how do we proceed with this bug?
,
Sep 9 2016
> [triage] loinsrch@ in step 5, how long do you wait before doing step 6? Even hours after the VPN has gone down, Chrome continues to attempt to generate candidates for that interface. It appears that Chrome must be quit and restarted to learn the correct state of the interface.
,
Sep 17 2016
Thank you for providing more feedback. Adding requester "jansson@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 19 2016
+honghai who knows this area of the code best
,
Sep 19 2016
,
Sep 20 2016
I think this was caused by that the controlling side never released ports and it has been fixed in my CL: https://codereview.webrtc.org/2171183002/. That CL was in Chrome 54. Can you verify it with Chrome 54?
,
Sep 20 2016
I will mark this as fixed. Please re-open it if this is still an issue in Chrome 54.
,
Sep 21 2016
I tested with Canary 55.0.2866.0, and I still see the candidates generated for the VPN interface after it's down.
,
Sep 21 2016
,
Oct 6 2016
,
Oct 19 2016
Update: I retested with Chrome 54.0.2840.59 under both macOS 10.11.6 and Windows 7. I was able to reproduce this problem as observed/reported before on the Mac but did not observe the issue on the Windows system, which may indicate that the issue is macOS-specific.
,
Oct 19 2016
Update 2: I updated my Pulse Secure VPN software for macOS to the latest version now available - 5.2.5 (869) - and I no longer observe the issue. I.e., I no longer see ICE candidates generated for the downed VPN interface and associated delay with reaching ICEGatheringStateComplete. It would appear that Pulse fixed something on their side. I appreciate the group's consideration of and attention to this issue.
,
Oct 19 2016
,
Oct 19 2016
Thanks for the updates; I'm glad the problem could get resolved.
,
Nov 15 2016
[bulk-edit : please ignore if not applicable] Could you please set the correct milestone for this issue?
,
Nov 15 2016
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by yini...@chromium.org
, Jun 29 2016