Fails to connect to host specified as IPv6 numerical address + zone id

[GitYuanQu]

duplicate with 3480.
I did this
[root@localhost src]# ls ../configure
../configure
[root@localhost src]# ./curl -V
curl 7.64.0-20181225 (x86_64-pc-linux-gnu) libcurl/7.64.0-20181225 OpenSSL/1.0.2p zlib/1.2.11 libssh2/1.7.0
Release-Date: 2018-12-25
Protocols: dict file ftp ftps gopher http https rtsp scp sftp smb smbs telnet tftp
Features: AsynchDNS Debug TrackMemory IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy
[root@localhost src]# ./curl --url sftp://root:sys2009health@[fe80::42f2:e9ff:fe30:c17%eth0]/home ../configure
curl: (3) URL using bad/illegal format or missing URL
curl: (6) Could not resolve host: ..
[root@localhost src]# ./curl --url sftp://root:SYS2009health@[2002:97b:c2bb:830:10:240:196:14]/home ../configure
curl: (60) SSL peer certificate or SSH remote key was not OK
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
curl: (6) Could not resolve host: ..
[root@localhost src]# ping6 2002:97b:c2bb:830:10:240:196:14
PING 2002:97b:c2bb:830:10:240:196:14(2002:97b:c2bb:830:10:240:196:14) 56 data bytes
64 bytes from 2002:97b:c2bb:830:10:240:196:14: icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from 2002:97b:c2bb:830:10:240:196:14: icmp_seq=2 ttl=64 time=1.71 ms
^C
--- 2002:97b:c2bb:830:10:240:196:14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1365ms
rtt min/avg/max/mdev = 0.341/1.027/1.714/0.687 ms
[root@localhost src]# ping6 fe80::42f2:e9ff:fe30:c17%eth0
PING fe80::42f2:e9ff:fe30:c17%eth0(fe80::42f2:e9ff:fe30:c17) 56 data bytes
64 bytes from fe80::42f2:e9ff:fe30:c17: icmp_seq=1 ttl=64 time=2.48 ms
64 bytes from fe80::42f2:e9ff:fe30:c17: icmp_seq=2 ttl=64 time=0.353 ms
^C
--- fe80::42f2:e9ff:fe30:c17%eth0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1466ms
rtt min/avg/max/mdev = 0.353/1.417/2.482/1.065 ms

I expected the following
expect file could uploaded success

curl/libcurl version
curl 7.64.0-20181225 (x86_64-pc-linux-gnu) libcurl/7.64.0-20181225 OpenSSL/1.0.2p zlib/1.2.11 libssh2/1.7.0
Release-Date: 2018-12-25
Protocols: dict file ftp ftps gopher http https rtsp scp sftp smb smbs telnet tftp
Features: AsynchDNS Debug TrackMemory IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

operating system
ALL

even I use release 7.64.1, it still failed.

next step, I will use current master to check this issue, thanks.

[GitYuanQu]

hey badger, and I need know what's your release plan, we will publish our GA build at 5/31, so could we use your new release if current master could solve this?

[bagder]

Our release plans are always public and planned long in advance. 7.65.0 will be released in 48 hours.

I believe this bug is already fixed, unless you can still reproduce this with the current source code I will close this duplicate as well.

[bagder]

Duplicate of #3408

[GitYuanQu]

Hi Bagder:

I have tried this as below:

[quyuan@localhost src]$ ./curl -V
curl 7.65.0-20190520 (x86_64-pc-linux-gnu) libcurl/7.65.0-20190520 OpenSSL/1.0.2r zlib/1.2.11 libssh2/1.8.2
Release-Date: 2019-05-20
Protocols: dict file ftp ftps gopher http https rtsp scp sftp smb smbs telnet tftp
Features: AsynchDNS Debug HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP TrackMemory UnixSockets


[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[fe80::20c:29ff:fe9c:409b%eth0]/home/ -T ../configure -k
curl: (7) Couldn't connect to server

with old release 7.60.0

[quyuan@localhost src]$ ./curl -V
curl 7.60.0 (x86_64-pc-linux-gnu) libcurl/7.60.0 OpenSSL/1.0.2r zlib/1.2.11 libssh2/1.8.2
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https rtsp scp sftp smb smbs telnet tftp
Features: AsynchDNS Debug TrackMemory IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[fe80::20c:29ff:fe9c:409b%eth0]/home/ -T ../configure -k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1162k    0     0  100 1162k      0  5559k --:--:-- --:--:-- --:--:-- 5839k
100 1162k    0     0  100 1162k      0  5559k --:--:-- --:--:-- --:--:-- 5559k

so it could be reproduced with current master codes, please take a look, thanks.

[bagder]

This is a different problem as is made quite clear in the output. Now it succeeds in parsing the URL but fails to connect. This is probably because the zone id isn't used correctly.

[GitYuanQu]

Hi Daniel, when will you resolve and publish it? we need know your plan to decide what should we do before 5/30.

[jay]

The zone id parsing fix will be in curl 7.65.0 to be released in one day. It's unclear to me whether that will solve your problem.

[bagder]

@GitYuanQu try out #3914 and help verify if that corrects the problem for you!

[GitYuanQu]

thanks Daniel and jay, I will try to verify this with #3914, thanks.

[GitYuanQu]

Hi Daniel, how could I get the code of #3914, could I get this from snapshot directly?

[bagder]

If you don't want to use git to get that code, you can for example use a daily snapshot from yesterday and then get #3914 as a regular patch and apply that manually and then rebuild.

[GitYuanQu]

Hi Daniel:
I only replace the code 'lib/url.c' with the submit (37f21ae (url: convert the zone id from a IPv6 URL to correct scope id)) code, unfortunately it still could not work, and below is output:

[quyuan@localhost src]$ ./curl -V
curl 7.65.0-20190520 (x86_64-pc-linux-gnu) libcurl/7.65.0-20190520 OpenSSL/1.0.2r zlib/1.2.11 libssh2/1.8.2
Release-Date: 2019-05-20
Protocols: dict file ftp ftps gopher http https rtsp scp sftp smb smbs telnet tftp
Features: AsynchDNS Debug HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP TrackMemory UnixSockets
[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[2002:97b:c2bb:830:10:240:196:13]/home -T ../configure -k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (79) Upload failed: Operation failed (4/-31)

[GitYuanQu]

sorry, use the wrong case, with the right case could be passed, but I still need investigation a little upper case then to close this.

[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[fe80::20c:29ff:fe9c:409b%eth0]/home/ -T ../configure -k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1156k 0 0 100 1156k 0 4860k --:--:-- --:--:-- --:--:-- 5140k
100 1156k 0 0 100 1156k 0 4860k --:--:-- --:--:-- --:--:-- 4860k

[GitYuanQu]

I have a little confused that why this case is failed?
[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[2002:97b:c2bb:830:10:240:196:13]/home -T ../configure -k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (79) Upload failed: Operation failed (4/-31)

[bagder]

#3914 only makes sure that the zone id in the URL is used in the connection to the host, so everything else remains as before. But without #3914 the zone wasn't used at all.

The "upload fail" is a separate issue.

[GitYuanQu]

this could be passed:
[quyuan@localhost src]$ ./curl --url sftp://root:SYS2009health@[2002:97b:c2bb:830:10:240:196:13]/home/ -T ../configure -k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1156k 0 0 100 1156k 0 4964k --:--:-- --:--:-- --:--:-- 4985k
100 1156k 0 0 100 1156k 0 4964k --:--:-- --:--:-- --:--:-- 4964k

[GitYuanQu]

ok, I know that, thanks Daniel, I will close this, thanks.

[GitYuanQu]

then my question is when will you will public this?

[GitYuanQu]

may be I need use your public build to verify this. so I need reopen this and check it with new release, then to close if could not reproduced.

[GitYuanQu]

Hi Daniel:
when will you publish the release of 7.65.0?

[dfandrich]

It was done an hour ago.