The bug report for network-manager about this issue is here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/123

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.

We backported that commit and the one it fixes without success.

Can you make a standalone libcurl-using example that reproduces the problem?

And maybe try the git master version in its entirety first to make sure that the problem is still there.

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.

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.

@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 .

The title says "wrong handling" of "broken IPv6". In what way is it broken?

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.

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?

It runs fine, first trying IPv6 and quickly failing, then using IPv4. With -6 it times out after two minutes.

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-event that 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?

$ curl --test-event -v http://www.archlinux.org/check_network_status.txt

Hah, that does get into a loop printing * call curl_multi_socket_action(socket 4).

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

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.