Issue metadata
Sign in to add a comment
|
webrtc - browser gets into a state where it is not giving me any ice candidates for calls that I make.
Reported by
dmcletc...@gmail.com,
Jun 2 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Steps to reproduce the problem: 1. this is an intermittent issue. I've been chasing it for a few days. I cannot reproduce it on my machine. I cannot reproduce it on demand. 2. I believe that it may be related to the PC losing / getting IP connectivity. 3. Something happens to the browser, and at the start of a webrtc call, I do not get any ice candidates. onIceCandidate is never called. ICEGatheringStateComplete is called, and the state is ICEGatheringStateComplete What is the expected behavior? after getting callbacks like setRemoteDescriptionOnSuccess, setLocalDescriptionOnSuccess , I expect to get onIceCandidate 5 to 20 times. I get it zero times. What went wrong? I did not get the ice candidate callbacks, so I don't have connectivity & I never had an audio/video/data call. once this fails, it will fail every time. subsequent calls fail. I am unable to complete a call. If I close the browser, and open it back up, it starts working again. (and of course, then I cannot get it to fail) The failure is intermittent & seems rare. the calling peer is an android tablet, and is on the same IP network. Did this work before? Yes it just broke in the last week or so. Chrome version: 51.0.2704.79 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 I'm developing an application, and I don't have a public site for you guys to visit. I don't have a way to reproduce the issue. I don't have a chrome_debug.log. I'm working on the chrome_debug.log. Is there anything that I could be doing in my javascript browser code to cause this?
,
Jun 3 2016
My coworker was running chrome from a console window, and we got this error message around the time of the error. It looks like chrome thinks that there are no network interfaces on the machine (this is a windows 10 machine, but I have seen this on a windows 7 machine). I have a chrome_debug.log. it's 300 MB, and it's full of information that we don't want to upload ... I will work on sending a good subset of the log.
,
Jun 3 2016
Here are some log files. subset_01 has this line, that appears relevant: [10040:9904:0603/124438:ERROR:network_interfaces_win.cc(245)] GetAdaptersAddresses failed: 111 subset_01 is (I believe) the part of the file when the call failed. I think that this is the failure to get ICE candidates: [8584:7220:0603/125707:WARNING:basicportallocator.cc(347)] Machine has no networks; no ports will be allocated [8584:7220:0603/125707:WARNING:basicportallocator.cc(347)] Machine has no networks; no ports will be allocated [8584:7220:0603/125707:WARNING:basicportallocator.cc(347)] Machine has no networks; no ports will be allocated [8584:7220:0603/125707:WARNING:basicportallocator.cc(347)] Machine has no networks; no ports will be allocated [8584:7220:0603/125707:WARNING:basicportallocator.cc(347)] Machine has no networks; no ports will be allocated [8584:7220:0603/125707:INFO:basicportallocator.cc(648)] All candidates gathered for audio:1:0 [8584:7220:0603/125707:INFO:p2ptransportchannel.cc(535)] P2PTransportChannel: audio, component 1 gathering complete [8584:7220:0603/125707:INFO:basicportallocator.cc(648)] All candidates gathered for audio:2:0 [8584:7220:0603/125707:INFO:p2ptransportchannel.cc(535)] P2PTransportChannel: audio, component 2 gathering complete [8584:7220:0603/125707:INFO:basicportallocator.cc(648)] All candidates gathered for data:1:0 [8584:7220:0603/125707:INFO:p2ptransportchannel.cc(535)] P2PTransportChannel: data, component 1 gathering complete [8584:7220:0603/125707:INFO:basicportallocator.cc(648)] All candidates gathered for video:1:0 [8584:7220:0603/125707:INFO:p2ptransportchannel.cc(535)] P2PTransportChannel: video, component 1 gathering complete [8584:7220:0603/125707:INFO:basicportallocator.cc(648)] All candidates gathered for video:2:0 [8584:7220:0603/125707:INFO:p2ptransportchannel.cc(535)] P2PTransportChannel: video, component 2 gathering complete The PC was online at the time. I could get to our local network & the internet from other chrome tabs.
,
Jun 3 2016
,
Jun 3 2016
It looks to me like I'm hitting this code:
result = GetAdaptersAddresses(AF_UNSPEC, flags, NULL, adapters, &len);
if (result != NO_ERROR) {
LOG(ERROR) << "GetAdaptersAddresses failed: " << result;
return false;
}
in https://github.com/scheib/chromium/blob/master/net/base/network_interfaces_win.cc
and getting ERROR_BUFFER_OVERFLOW from the windows call GetAdaptersAddresses() ... but I don't know that would be.
,
Jun 6 2016
It looks like perhaps windows is saying "buffer size N is enough" and then when buffer size N is used, it's not. There could be two fixes: 1. GetNetworkList could try with bigger buffer sizes more than once (say, up to 5 times as long as ERROR_BUFFER_OVERFLOW is returned). 2. P2PSocketDispatcherHost::DoGetNetworkList() should check the return code and do something smarter, perhaps call GetNetworkList again a littler later. At the very least, don't just SendNetworkList with an empty/invalid list.
,
Jun 6 2016
Feel free to share the work with Honghai, Zhi, and Vlad.
,
Jun 8 2016
Just to note, seems very likely that this is the same issue as https://bugs.chromium.org/p/webrtc/issues/detail?id=5872.
,
Jun 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ba6d6a649dd1db1125dc6b321f1ad159aac0412c commit ba6d6a649dd1db1125dc6b321f1ad159aac0412c Author: deadbeef <deadbeef@chromium.org> Date: Tue Jun 21 17:16:17 2016 If GetNetworkList fails, don't push down an empty network list. WebRTC would rather have a possibly-outdated network list than an empty one. So if GetNetworkList fails, we now just log an error instead of persisting the empty list. BUG= 616908 Review-Url: https://codereview.chromium.org/2078913004 Cr-Commit-Position: refs/heads/master@{#401021} [modify] https://crrev.com/ba6d6a649dd1db1125dc6b321f1ad159aac0412c/content/browser/renderer_host/p2p/socket_dispatcher_host.cc
,
Jun 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e5a246f582215340d3c71022a87d4c152a8269df commit e5a246f582215340d3c71022a87d4c152a8269df Author: deadbeef <deadbeef@chromium.org> Date: Tue Jun 21 22:13:36 2016 Call GetAdaptersAddresses in the way recommended by MSDN. Previously, we were calling GetAdaptersAddresses once to get the required buffer size, then a second time to fill the buffer. This method is "strongly discouraged" by MSDN. They recommend an initial size of 15KB to avoid calling GetAdaptersAddresses multiple times. We also were not calling GetAdaptersAddresses in a loop. In between two calls to GetAdaptersAddresses, the required size may increase. Instead of treating this as an error, we now increase our buffer size and try again. BUG= 616908 , 534463 Review-Url: https://codereview.chromium.org/2071273004 Cr-Commit-Position: refs/heads/master@{#401123} [modify] https://crrev.com/e5a246f582215340d3c71022a87d4c152a8269df/net/base/network_interfaces_win.cc
,
Aug 4 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rnimmagadda@chromium.org
, Jun 3 2016