Yet another Fedora mirror timeout?

I frequently encounter cURL errors when updating the Fedora 42 repositories.

This usually happens more often with these repositories, but not exclusively:

  • Fedora 42 openh264 (From Cisco)
  • RPM Fusion for Fedora 42 - Nonfree - NVIDIA Driver

This is my basic DNF global configuration file.

[main]
max_parallel_downloads=10
#fastestmirror=True
timeout=5

I’ve already tried setting fastestmirror=True, but it had no effect. I also reduced the timeout so that I would not have to wait ages just for DNF to fail.
Only after a few attempts that the repositories are updated.

My Internet connection and DNS resolution have no issues.
When I run cURL manually on any of the mirror URLs, I sometimes I get a response and sometimes don’t.

$ curl "https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64"
<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Fri, 27 Jun 2025 23:37:23 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
 <files>
  <file name="repomd.xml">
   <mm0:timestamp>1742403219</mm0:timestamp>
   <size>3082</size>
   <verification>
    <hash type="md5">937f95b7143bb71933e4ab6b5812e853</hash>
    <hash type="sha1">aec176bc27ee516f0c0a1122e340f1e1956d83b9</hash>
    <hash type="sha256">7548e76a6e04a3cfce43b7baa7bb8940209d1e6d76bd4bd2575cb013a25f6617</hash>
    <hash type="sha512">7c8491f22120160160e71ddbe12b8a0fb9729100502c09034f75d432cc9e6fa39eaf0f48e06dcf28b129560fbbafac8b6473a86e515eb021abf81e3e09c371ef</hash>
   </verification>
   <resources maxconnections="1">
    <url protocol="https" type="https" location="US" preference="100">https://codecs.fedoraproject.org/openh264/42/x86_64/repodata/repomd.xml</url>
   </resources>
  </file>
 </files>
</metalink>

Adding a country=XX parameter to the URL yelds the same result: constant timeouts.

I also noticed many reports of cURL timeouts with Fedora. So, what is the issue with these Fedora mirrors?

Do things improve if you increase the timeout to say 30?

No. Actually, things get worse because it takes longer for DNF to fail.

What is your ISP, country, download/upload speed, and type of connection? Are you connected using wired Ethernet or Wi-Fi?

That being said, max_parallel_downloads=10 is probably excessive, and timeout=5 is too short. While some timeouts are normal, they shouldn’t occur too frequently in most cases and with most mirrors.

I would add time of day. Here in Canada, people are dropping TV subscriptions in favour of streaming video. I see slowdowns and connection issues shortly after local schools let kids out.

1 Like

Good point. Unfortunately, this issue is common in many countries, and some ISPs are brutal in how they oversell their connectivity, especially internationally.

Usually, when the repository cache update doesn’t time out, and DNF actually gets to download packages, max_parallel_downloads works fine.

As for timeout, my impression is that, when the mirror works, it responds in less than a second. If the waiting is longer than that, it will fail no matter what the timeout is set to. As I said, I reduced the timeout so that I wouldn’t have to wait ages just for DNF to fail.

When testing with “cURL”, there are some looping TLS errors. It seems the connection is stuck waiting for the server’s response.

$ curl -vvv "https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64"
15:35:08.835735 [0-x] == Info: [READ] client_reset, clear readers
15:35:08.836860 [0-0] == Info: Host mirrors.fedoraproject.org:443 was resolved.
15:35:08.836955 [0-0] == Info: IPv6: 2620:52:3:1:dead:beef:cafe:fed7, 2620:52:3:1:dead:beef:cafe:fed6, 2600:1f1e:fa1:6501:51f1:498d:2613:e54, 2600:1f1e:fa1:6501:f2c8:2eb:f406:8d4
15:35:08.837116 [0-0] == Info: IPv4: 38.145.60.20, 15.228.197.101, 8.43.85.67, 18.231.196.68, 8.43.85.73, 38.145.60.21
15:35:08.837227 [0-0] == Info: [HTTPS-CONNECT] added
15:35:08.837278 [0-0] == Info: [HTTPS-CONNECT] connect, init
15:35:08.837335 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
15:35:08.837407 [0-0] == Info:   Trying [2620:52:3:1:dead:beef:cafe:fed7]:443...
15:35:08.837519 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
15:35:08.837605 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset -> 1 socks
15:35:08.837705 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
15:35:08.837770 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
15:35:08.837837 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset -> 1 socks
15:35:08.988208 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
15:35:08.988254 [0-0] == Info: [SSL] cf_connect()
15:35:08.989168 [0-0] == Info: [SSL] No cached session ID for https://mirrors.fedoraproject.org:443
15:35:08.989202 [0-0] == Info: ALPN: curl offers h2,http/1.1
15:35:08.989309 [0-0] => Send SSL data, 5 bytes (0x5)
0000: .....
15:35:08.989353 [0-0] == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
15:35:08.989434 [0-0] => Send SSL data, 512 bytes (0x200)
0000: .......{L)[X.G...o..*.r...P|.....i.}.. .~H..R...nV..n`...E.[a...
0040: BO^...p.T.........,.0.......+./...#.'.................=.<.5./...
0080: ............k.j.g.@.9.8.3.2....._.........mirrors.fedoraproject.
00c0: org.........................................h2.http/1.1.........
0100: 1.....*.(.........................................+........-....
0140: .3.&.$... Cg.....'...^........I.{...:u..br......................
0180: ................................................................
01c0: ................................................................
15:35:08.990081 [0-0] == Info: [SSL] ossl_bio_cf_out_write(len=517) -> 517, err=0
15:35:08.990208 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
15:35:08.990295 [0-0] == Info: [SSL] populate_x509_store, path=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, blob=0
15:35:08.994605 [0-0] == Info:  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
15:35:08.994726 [0-0] == Info:  CApath: none
15:35:08.994771 [0-0] == Info: [SSL] SSL_connect() -> err=-1, detail=2
15:35:08.994849 [0-0] == Info: [SSL] SSL_connect() -> want recv
15:35:08.994927 [0-0] == Info: [SSL] cf_connect() -> 0, done=0
15:35:08.994981 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
15:35:08.995048 [0-0] == Info: [SSL] adjust_pollset, POLLIN fd=4
15:35:08.995108 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset -> 1 socks
15:35:09.038384 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
15:35:09.038456 [0-0] == Info: [SSL] cf_connect()
15:35:09.038504 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
15:35:09.038574 [0-0] == Info: [SSL] SSL_connect() -> err=-1, detail=2
15:35:09.038654 [0-0] == Info: [SSL] SSL_connect() -> want recv
15:35:09.038701 [0-0] == Info: [SSL] cf_connect() -> 0, done=0
15:35:09.038745 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
15:35:09.038812 [0-0] == Info: [SSL] adjust_pollset, POLLIN fd=4
15:35:09.038863 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset -> 1 socks
15:35:10.040084 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
15:35:10.040118 [0-0] == Info: [SSL] cf_connect()
15:35:10.040141 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
15:35:10.040178 [0-0] == Info: [SSL] SSL_connect() -> err=-1, detail=2
15:35:10.040225 [0-0] == Info: [SSL] SSL_connect() -> want recv
15:35:10.040265 [0-0] == Info: [SSL] cf_connect() -> 0, done=0

When I try curl -4, it works every time, but with the -6 option, it just hangs.
I suspected that cURL might be trying multiple IPv6 addresses, which is causing it to hang.

I changed the gai.conf file to prefer IPv4.

$ cat /etc/gai.conf 
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

With this, cURL works every time, but DNF keeps timing out.


Only After setting ip_resolve=4 in the dnf.conf file, DNF finally stopped timing out.

My take from all this is that Fedora IPv6 mirrors or my ISP’s IPv6 may have incomplete or flaky routes depending on the region.

1 Like