Do not spam "Connect failed with 101/65" in logs.

Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org

Committed: https://crrev.com/7502401788fcba5c9f81a9e4701e2f0831e78698
Cr-Commit-Position: refs/heads/master@{#14440}

[skvlad, 2016-09-27 22:28:44]

Description was changed from

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
==========

to

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
==========

[skvlad, 2016-09-27 22:28:44]

skvlad@webrtc.org changed reviewers:
+ henrika@webrtc.org

[Taylor Brandstetter, 2016-09-28 17:24:15]

deadbeef@webrtc.org changed reviewers:
+ deadbeef@webrtc.org

[Taylor Brandstetter, 2016-09-28 17:24:15]

lgtm. Though I'm not a webrtc/base owner, so you'll need another LGTM.

[honghaiz3, 2016-09-28 19:36:29]

honghaiz@webrtc.org changed reviewers:
+ honghaiz@webrtc.org

[honghaiz3, 2016-09-28 19:36:30]

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc
File webrtc/base/network.cc (right):

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc#newcod...
webrtc/base/network.cc:842: if (socket->GetError() != ENETUNREACH
Should we log an error message if the query for both IPv4 and IPv6 failed?
That might provide some meaningful information when debugging networking issues.

[skvlad, 2016-09-28 21:22:55]

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc
File webrtc/base/network.cc (right):

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc#newcod...
webrtc/base/network.cc:842: if (socket->GetError() != ENETUNREACH
On 2016/09/28 19:36:30, honghaiz3 wrote:
> Should we log an error message if the query for both IPv4 and IPv6 failed?
> That might provide some meaningful information when debugging networking
issues.
> 

This would have to be elsewhere in NetworkManager - probably done only once
instead of every N seconds. The message I'm silencing wasn't useful for that as
it didn't say which of the two interfaces were unreachable - one (which is
expected) or both (which isn't).

[honghaiz3, 2016-09-28 21:33:05]

lgtm

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc
File webrtc/base/network.cc (right):

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc#newcod...
webrtc/base/network.cc:842: if (socket->GetError() != ENETUNREACH
On 2016/09/28 21:22:54, skvlad wrote:
> On 2016/09/28 19:36:30, honghaiz3 wrote:
> > Should we log an error message if the query for both IPv4 and IPv6 failed?
> > That might provide some meaningful information when debugging networking
> issues.
> > 
> 
> This would have to be elsewhere in NetworkManager - probably done only once
> instead of every N seconds. The message I'm silencing wasn't useful for that
as
> it didn't say which of the two interfaces were unreachable - one (which is
> expected) or both (which isn't).
Agree that can be done in a separate CL. Perhaps add a TODO here and/or file a
bug for that.

[skvlad, 2016-09-28 22:27:46]

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc
File webrtc/base/network.cc (right):

https://codereview.webrtc.org/2370383002/diff/1/webrtc/base/network.cc#newcod...
webrtc/base/network.cc:842: if (socket->GetError() != ENETUNREACH
On 2016/09/28 21:33:05, honghaiz3 wrote:
> On 2016/09/28 21:22:54, skvlad wrote:
> > On 2016/09/28 19:36:30, honghaiz3 wrote:
> > > Should we log an error message if the query for both IPv4 and IPv6 failed?
> > > That might provide some meaningful information when debugging networking
> > issues.
> > > 
> > 
> > This would have to be elsewhere in NetworkManager - probably done only once
> > instead of every N seconds. The message I'm silencing wasn't useful for that
> as
> > it didn't say which of the two interfaces were unreachable - one (which is
> > expected) or both (which isn't).
> Agree that can be done in a separate CL. Perhaps add a TODO here and/or file a
> bug for that. 
> 

Filed https://bugs.chromium.org/p/webrtc/issues/detail?id=6438.

[skvlad, 2016-09-28 22:28:26]

skvlad@webrtc.org changed reviewers:
+ mflodman@webrtc.org, perkj@webrtc.org

[skvlad, 2016-09-28 22:28:48]

Added more owners of webrtc/base - could one of you please review?

Thanks!

[perkj_webrtc, 2016-09-29 09:34:10]

rs lgtm

[skvlad, 2016-09-29 17:46:21]

The CQ bit was checked by skvlad@webrtc.org

[commit-bot: I haz the power, 2016-09-29 17:46:27]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-09-29 19:47:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-29 19:47:11]

Try jobs failed on following builders:
  android_arm64_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[skvlad, 2016-09-29 19:59:49]

Description was changed from

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
==========

to

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/7502401788fcba5c9f81a9e47...
==========

[commit-bot: I haz the power, 2016-09-29 19:59:50]

Description was changed from

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/7502401788fcba5c9f81a9e47...
==========

to

==========
Do not spam "Connect failed with 101/65" in logs.

WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).

If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).

This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.

BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org

Committed: https://crrev.com/7502401788fcba5c9f81a9e4701e2f0831e78698
Cr-Commit-Position: refs/heads/master@{#14440}
==========

[commit-bot: I haz the power, 2016-09-29 19:59:51]

Patchset 2 (id:??) landed as
https://crrev.com/7502401788fcba5c9f81a9e4701e2f0831e78698
Cr-Commit-Position: refs/heads/master@{#14440}

[skvlad, 2016-09-29 19:59:51]

Committed patchset #2 (id:20001) manually as
7502401788fcba5c9f81a9e4701e2f0831e78698 (presubmit successful).

[skvlad, 2016-09-29 20:14:06]

Patchset #3 (id:40001) has been deleted