|
|
DescriptionDo 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}
Patch Set 1 #
Total comments: 4
Patch Set 2 : Rebase #
Messages
Total messages: 21 (10 generated)
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@webrtc.org changed reviewers: + henrika@webrtc.org
deadbeef@webrtc.org changed reviewers: + deadbeef@webrtc.org
lgtm. Though I'm not a webrtc/base owner, so you'll need another LGTM.
honghaiz@webrtc.org changed reviewers: + honghaiz@webrtc.org
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.
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).
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.
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@webrtc.org changed reviewers: + mflodman@webrtc.org, perkj@webrtc.org
Added more owners of webrtc/base - could one of you please review? Thanks!
rs lgtm
The CQ bit was checked by skvlad@webrtc.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_arm64_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
Message was sent while issue was closed.
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... ==========
Message was sent while issue was closed.
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} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/7502401788fcba5c9f81a9e4701e2f0831e78698 Cr-Commit-Position: refs/heads/master@{#14440}
Message was sent while issue was closed.
Committed patchset #2 (id:20001) manually as 7502401788fcba5c9f81a9e4701e2f0831e78698 (presubmit successful).
Message was sent while issue was closed.
Patchset #3 (id:40001) has been deleted |