dtucker:

Supply the following if possible:

• Device problem occurs on: GL.inet AR150 (but not device specific).
• Software versions of OpenWrt/LEDE release, packages, etc: lede-17.01 branch, libcurl-7.52.1-6.
• Steps to reproduce: install https_dns_client package and try to use it. You will see all requests failing with "CURLINFO_RESPONSE_CODE: 0", suspiciously quick server times and a result "buflen 0".

From my comment in aarond10/https_dns_proxy#9
"""
The OpenWRT/LEDE problem is in libcurl.

On LEDE 17.01.2 with all updates, after annotating the callbacks with some logging and running it under strace I get the following debug log:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 6
[...]
connect(6, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("172.217.160.46")}, 16) = -1 EINPROGRESS (Operation in progress)
[..]
https_client.c:242 multi_sock_cb called, sock 6 what 2 # ie CURL_POLL_OUT
[...]
https_client.c:214 sock_cb called, fd 6 revents 2 # SSL socket gets written to
https_client.c:242 multi_sock_cb called, sock 6 what 4 # ie CURL_POLL_REMOVE

ie as soon as the socket gets written to, libcurl tells the app to stop monitoring the connection to the server and retrieve the results, which unsurprisingly are empty ("CURLINFO_RESPONSE_CODE: 0", suspiciously quick server times and a result "buflen 0").

This seems to be a known problem in libcurl <7.53.0 with mbedtls and nonblocking IO: curl/curl@b993d2c

If I build and install a libcurl with that patch then it works. I was also able to bodge it into working with the current library by adding a call to curl_multi_perform and looping until there were no more transfers. You could potentially detect that behaviour at runtime and enable the workaround but the performance would probably be pretty bad.
"""

For further info see:
aarond10/https_dns_proxy#12
lede-project/source#1627