Splitting the socks5 request is causing issues when running against Tor.
It causes Tor to fail with an address unknown error. Assembling the
request and sending it in its entirety solves the issue.
An strace of torsocks, that functions correctly when used with xbps, shows
that the request is being sent all at once:
recvfrom(3, "\5\0", 2, 0, NULL, NULL)
sendto(3, "\5\1\0\3>lysator7eknrfl47rlyxvgeamrv7ucefgrrlhk7rouv3sna25asetwid.onion\0P", 69, 0, NULL, 0)
recvfrom(3, "\5\0\0\1\0\0\0\0\0\0", 10, 0, NULL, NULL)
Closes: #54 [via git-merge-pr]
Connect to the addresses from `getaddrinfo(3)`,
alternating between address family,
starting with ipv6 and wait `fetchConnDelay`
between each connection attempt.
If a connection is established within the attempts,
use this connection and close all others.
If `connect(3)` returns `ENETUNREACH`, don't attempt more
connections with the failing address family.
If there are no more addresses to attempt,
wait for `fetchConnTimeout` and return the first established
connection.
If no connection was established within the timeouts,
close all sockets and return -1 and set errno to
`ETIMEDOUT`.
When trying to compile the file ftp.c, I get errors related with
warnings that were marked to be reported as error.
This was the original message:
```
fetch/ftp.c:444:8: error: this statement may fall through [-Werror=implicit-fallthrough=]
type = 'D';
~~~~~^~~~~
fetch/ftp.c:445:2: note: here
case 'D':
^~~~
fetch/ftp.c: In function ‘ftp_request’:
fetch/ftp.c:342:3: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
for (i = 0; i <= len && i <= end - dst; ++i)
^~~
fetch/ftp.c:342:24: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
for (i = 0; i <= len && i <= end - dst; ++i)
~~~~~~~~~^~~~~~~~~~~~~~~~~
```
The default CA file set by FreeBSD is only available when using the
LibreSSL provided CA file, and we've decided to use the CA path
by default.
Discussed with @dominikh.
While xbps_fetch_file() creates the .part file and for whatever reason
it did not finish properly to rename the file, it could request the server
to restart the download with offset set to file size, resulting in HTTP 416
return code.
Handle this case by checking if the server returns 416 and then checking
if the returned file size matches the requested offset and just rename
the file.
Thanks to @beefcurtains for the test case.
