Bug 258215 - make fetchindex (ports) is incredibly unreliable 3/20 tries succeeds
Summary: make fetchindex (ports) is incredibly unreliable 3/20 tries succeeds
Status: Closed FIXED
Alias: None
Product: Services
Classification: Unclassified
Component: FTP/WWW Sites & Mirrors (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: FreeBSD Mirror Admin
URL:
Keywords:
Depends on: 223065
Blocks:
  Show dependency treegraph
 
Reported: 2021-09-02 14:35 UTC by Dave Cottlehuber
Modified: 2021-10-31 04:52 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Cottlehuber freebsd_committer freebsd_triage 2021-09-02 14:35:14 UTC
Every few days, I run `make fetchindex`. All it needs to do is to fetch a single file that rarely changes of ~ 2.3Mb size:

fetch -am -o /dev/null https://www.FreeBSD.org/ports/INDEX-13.bz2

One might assume that this is a reasonably well understood task for a long running OS like FreeBSD, and quality hardware and we could expect it to be quite reliable.

Sadly not.

pcap from fetch & subsequent curl sessions are available here:

https://freeside.skunkwerks.at/~dch/tmp/fetchindex/

I will look through these tomorrow in hope of seeing something obvious.

This is not just me, it's been reported repeatedly for years on irc and elsewhere, and shows up fetching from Amsterdam, Frankfurt, and Finland datacentres where I have remote access.

Either something is terribly wrong with this single file, or something is terribly wrong with many files that we simply don't notice.

I'd be ok with the website issuing a 301 REDIRECT to some other site that doesn't fail so reliably, or changing `make fetchindex` to anything else that more reliable.


 
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        19% of 2353 kB 1106 kBps    04s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 476150/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        35% of 2353 kB  687 kBps    01s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 861173/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        47% of 2353 kB  399 kBps    03s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 1153578/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        56% of 2353 kB  913 kBps    01s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 1364130/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        61% of 2353 kB  917 kBps    01s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 1488619/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        74% of 2353 kB  959 kBps    02s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 1804063/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        89% of 2353 kB  986 kBps    02s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 2164481/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                        96% of 2353 kB 1023 kBps    02s
fetch: /usr/ports/INDEX-14.bz2 appears to be truncated: 2331457/2409956 bytes
*** Error code 1

Stop.
make: stopped in /usr/ports
dch@wintermute /u/ports> make fetchindex
/usr/bin/env  fetch -am -o /usr/ports/INDEX-14.bz2 https://www.FreeBSD.org/ports/INDEX-14.bz2
/usr/ports/INDEX-14.bz2                               2353 kB  651 kBps    04s


Finally it worked!

So I switched to using curl for simplicity sake, and ran tcpdump as well.


I should report that I am running FreeBSD 14.0-CURRENT right now, although it fails just as reliably on 13.0-RELEASE.

I am behind an OpenBSD 6.9 router, and wedged inside a consumer NAT device of morally repugnant origins, of which I have no control over.



curl reports:
 curl -4vsSLo /dev/null https://www.FreeBSD.org/ports/INDEX-14.bz2 || echo FAILED
*   Trying 96.47.72.84:443...
* Connected to www.FreeBSD.org (96.47.72.84) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /usr/local/share/certs/ca-root-nss.crt
*  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [112 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4348 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [556 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=www.freebsd.org
*  start date: Aug 13 20:33:25 2021 GMT
*  expire date: Nov 11 20:33:23 2021 GMT
*  subjectAltName: host "www.FreeBSD.org" matched cert's "www.freebsd.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
} [5 bytes data]
> GET /ports/INDEX-14.bz2 HTTP/1.1
> Host: www.FreeBSD.org
> User-Agent: curl/7.78.0
> Accept: */*
> 
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 02 Sep 2021 14:20:22 GMT
< Content-Type: application/octet-stream
< Content-Length: 2409956
< Connection: keep-alive
< Server: nginx/1.16.1
< Last-Modified: Thu, 02 Sep 2021 06:25:19 GMT
< ETag: "61306e4f-24c5e4"
< X-Varnish: 572002008
< Age: 0
< Via: 1.1 wfe0.nyi.FreeBSD.org
< X-Cache: MISS
< Accept-Ranges: bytes
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: default-src 'self' https://www.freebsd.org/ https://docs.freebsd.org/; style-src 'self' https://www.freebsd.org/ https://docs.freebsd.org/ 'unsafe-inline'; script-src 'self' https://www.freebsd.org/ https://docs.freebsd.org/ https://ssl.google-analytics.com/ga.js 'unsafe-inline' resource: data: blob:; img-src 'self' https://www.freebsd.org/ https://docs.freebsd.org https://ssl.google-analytics.com/ https://chart.googleapis.com/ data: blob:; upgrade-insecure-requests
< 
{ [15392 bytes data]
* TLSv1.2 (IN), TLS alert, close notify (256):
{ [2 bytes data]
* transfer closed with 1442505 bytes remaining to read
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
curl: (18) transfer closed with 1442505 bytes remaining to read
FAILED
Comment 1 Matthias Andree freebsd_committer freebsd_triage 2021-09-02 15:06:36 UTC
This also happens with a vanilla AVM Fritz!Box 7590 router on a reliable Telekom VDSL connected network in Germany with no other fishy stuff in between, and judging from other reports, I would say it's not necessarily something on your end.
Comment 2 Dave Cottlehuber freebsd_committer freebsd_triage 2021-09-20 19:58:07 UTC
do we have any developer info on freefall or elsewere, for how this is set up, to see if I understand it, and can address it somehow?
Comment 3 Philip Paeps freebsd_committer freebsd_triage 2021-10-31 04:52:53 UTC
Now that bug#223065 is fixed, I believe this one is fixed too.