Repository navigation
wrong handling of broken IPv6 #3585
Description
Curl behaves differently than before when a site cannot be reached via IPv6, but only IPv4. This causes network-manager (using libcurl) to loop forever and take 100% of one CPU. Please see https://bugs.archlinux.org/task/61688 for all the details.
In that report, it is stated that the change 4c35574 is the cause, see comment https://bugs.archlinux.org/task/61688#comment177215 .
Activity
buzo-ffm commentedon Feb 18, 2019
The bug report for network-manager about this issue is here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/123
bagder commentedon Feb 18, 2019
I think this problem (even if this report is doing a lot of wild guessing and drawing funny conclusions) is already addressed in git with 4015fae, since it seems similar to the symptoms in #3542.
heftig commentedon Feb 19, 2019
We backported that commit and the one it fixes without success.
bagder commentedon Feb 19, 2019
Can you make a standalone libcurl-using example that reproduces the problem?
bagder commentedon Feb 19, 2019
And maybe try the git master version in its entirety first to make sure that the problem is still there.
buzo-ffm commentedon Feb 19, 2019
The libcurl-using code is here within the #if WITH_CONCHECK blocks, but I don't know how to make a standalone example from it.
heftig commentedon Feb 19, 2019
The problem is still present as of commit 5908e90.
FTR, the URL in question here is http://www.archlinux.org/check_network_status.txt, so http2 is not involved.
heftig commentedon Feb 19, 2019
@buzo-ffm NM's connectivity code had lots of changes in master; we're actually running https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/nm-1-14/src/nm-connectivity.c .
bagder commentedon Feb 19, 2019
The title says "wrong handling" of "broken IPv6". In what way is it broken?
heftig commentedon Feb 19, 2019
I have a working dual stack setup here; dropping all IPv6 packets from www.archlinux.org (via
ip6tables -A INPUT -s 2a01:4f8:172:1d86::1/128 -j DROP) makes NM enter an infinite loop once it attempts to retrieve the URL.bagder commentedon Feb 19, 2019
If you, on the same machine with that filter enabled, run
curl -v http://www.archlinux.org/check_network_status.txt(built from the problematic commit), what happens then?heftig commentedon Feb 19, 2019
It runs fine, first trying IPv6 and quickly failing, then using IPv4. With
-6it times out after two minutes.bagder commentedon Feb 19, 2019
Unfortunately my dev machines don't have working IPv6 so I can't easily reproduce this setup.
With a debug build created with
configure --enable-debug, the curl command line tool gets an undocumented new option called--test-eventthat will make it run its normal operations internally with the event-based API (that NM is using) instead of the regular easy API that it otherwise uses. Any chance you can see if that reproduces it?heftig commentedon Feb 19, 2019
Hah, that does get into a loop printing
* call curl_multi_socket_action(socket 4).heftig commentedon Feb 19, 2019
buzo-ffm commentedon Feb 19, 2019
FWIW, my IPv6 is working fine, yet I am hit by this bug. The reason could be me having more than one default route:
default via fe80::**** dev enp0s31f6 proto ra metric 100 pref medium
default via fe80::**** dev wlp58s0 proto ra metric 600 pref medium
default via fd28:**** dev buzo metric 1024 pref low
heftig commentedon Feb 19, 2019
Since curl moves on to IPv4 quite quickly if the initial attempt at IPv6 takes too long, I guess just having a slow enough connection to the server is enough to trigger this.
singlesocket: fix the 'sincebefore' placement