constant 'curl: (56) Recv failure' attempting to update with aurutils

jakyote · Yesterday 21:47:27

I've been trying to update my AUR pkgs for a couple weeks and keep getting a 'curl: (56) Recv failure: Connection reset by peer' error when aurutils is querying for updated pgkbuilds. At first it only happened around half the time but even when it managed to curl successfully it would later eventually fail while fetching the updated pkgbuilds with git, I left it for a couple days and tried again and have almost exclusively received curl 56 failures since. I've tried a few different things on two different systems every couple days attempting to resolve the issue (or wait for it to fix itself) with little change in behavior until i just tried connecting through my phone's data as a hotspot and it immediately worked with no issues (at least once anyway, i tried to run it again a few minutes later to sanity check but a snow storm rolled in and my data's not connecting to anything right now), so it seems to be a networking problem between my home network and the AUR rather than any configuration issue with my systems.

What I don't know is whether that issue is with my network configuration or if my IP is being limited by the AUR in some way, it doesn't seem to be an outright IP ban since i can still browse the aur and other archlinux pages just fine but i don't know if there's other kinds of IP restrictions that could be in place. While researching i found that people with satellite internet may have issues due to carrier-grade NAT assigning the same IP to multiple users, but i've had this service since November and haven't had any issues updating aur pkgs until the last couple weeks, and the only thing i've changed in my network since it was setup was configuring my router to use Google's DNS servers which i already tried removing to no effect. Disabling the firewall also has no effect and there's not much else relevant i can even configure with how limited this thing is.

Is there anything i can do to determine if this is something misconfigured on my end, the way my ISP is configured, or some restriction on my IP by arch's servers? And if it's a problem with my ISP is there anything i can do about it aside from a VPN? Or is it possible something else is going on entirely?

seth · Yesterday 22:52:31

seems to be a networking problem between my home network and the AUR

Can you reach aur.archlinux.org w/ openssl, https://bbs.archlinux.org/viewtopic.php … 5#p2269705 ?

jakyote · Today 00:27:54

Can you reach aur.archlinux.org w/ openssl

I don't really know what the results are supposed to look like but it seems like it worked to me

$ openssl s_client aur.archlinux.org:443

Connecting to 2604:cac0:a104:d::2
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E8
verify return:1
depth=0 CN=aur.archlinux.org
verify return:1
---
Certificate chain
 0 s:CN=aur.archlinux.org
   i:C=US, O=Let's Encrypt, CN=E8
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Feb 13 13:43:12 2026 GMT; NotAfter: May 14 13:43:11 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=E8
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDkDCCAxWgAwIBAgISBtd7R/KEmChjaAiUvukhHZT2MAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
ODAeFw0yNjAyMTMxMzQzMTJaFw0yNjA1MTQxMzQzMTFaMBwxGjAYBgNVBAMTEWF1
ci5hcmNobGludXgub3JnMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2OZ0INRb
MRhkXBuACPCoLu57AfdTMDnd0t0hBJjDvh5u6fs4wfqtzvJPPmNeJs0HC6yb8sup
sLrUc+OG1d2UtKOCAh8wggIbMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggr
BgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTtoKN+usMiWWu3pocakHgU
/2ZJBTAfBgNVHSMEGDAWgBSPDROi9i5+0VBsMxg4XVmOI3KRyjAyBggrBgEFBQcB
AQQmMCQwIgYIKwYBBQUHMAKGFmh0dHA6Ly9lOC5pLmxlbmNyLm9yZy8wHAYDVR0R
BBUwE4IRYXVyLmFyY2hsaW51eC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwLgYD
VR0fBCcwJTAjoCGgH4YdaHR0cDovL2U4LmMubGVuY3Iub3JnLzExOS5jcmwwggEN
BgorBgEEAdZ5AgQCBIH+BIH7APkAdgAOV5S8866pPjMbLJkHs/eQ35vCPXEyJd0h
qSWsYcVOIQAAAZxXc1lHAAAEAwBHMEUCICwUWOSQGD6/HJfkXsZk77fzZbzGpYnq
WmpSGZYXpltSAiEA8WHu9qxwth6BwvLo/UvJ0v8FyWZcro5z8jPNecYZ+CgAfwCl
yXiSXVdGF4KHDdiJZgtcVWSLfQBA8uwHaFHRiGkZ9wAAAZxXc1l1AAgAAAUAMhiP
8QQDAEgwRgIhAPzLmUJtlK29gxqS5Vu9Bo6/FYT9DrXwNBgCqqOMldOtAiEArRsI
paxHUzUpDWKjdMQxUMy0VJqjjxqLT/HzH7sNtXowCgYIKoZIzj0EAwMDaQAwZgIx
AKM0O7vzOvmxxVqXA2I9o2LDHWbogcW2aX7Qdn3sMACowfJXpr/zAVxs1JAWySlD
oAIxAL9rz04mzVozAHIxmC4edu1XyzUWbyNJEXcUYugCy97wlmyUNRxVGQc4hdBE
wF8OrA==
-----END CERTIFICATE-----
subject=CN=aur.archlinux.org
issuer=C=US, O=Let's Encrypt, CN=E8
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2411 bytes and written 1628 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 2AD563CCC36823841FD7BD6C2E12CC9BB576F8588FD3B4B6E42B30A33B9022CF
    Session-ID-ctx: 
    Resumption PSK: 9F43953490DC07B966CABFB2220DD7F15F1A6C0AD749B3DD88D4FD99E418F2C6E5549FA0E452BE2C048E1FC6F083E899
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 51 06 21 1e 0b a2 21 ea-1e e0 bc 7c d3 ac 09 99   Q.!...!....|....
    0010 - 3e 8d 8a 18 4d 62 e7 7c-f8 eb c5 73 38 4c f9 ab   >...Mb.|...s8L..
    0020 - 79 e4 6d 65 8d de 47 32-0d 46 95 32 70 16 58 dc   y.me..G2.F.2p.X.
    0030 - b0 b6 46 ab b7 73 1b 21-38 64 d0 31 b3 69 64 14   ..F..s.!8d.1.id.
    0040 - 3c 07 33 7f c0 c8 28 e0-f6 f3 dd 8d 8f 37 d0 a4   <.3...(......7..
    0050 - 9f 37 30 63 33 74 62 ca-2d d9 36 ca bd da b3 fa   .70c3tb.-.6.....
    0060 - 18 77 73 6f 25 85 87 05-70 6c 86 98 a8 39 96 41   .wso%...pl...9.A
    0070 - 3f db 2a 30 38 64 eb 02-03 75 c9 63 f3 c2 03 18   ?.*08d...u.c....
    0080 - 4d 7f eb b6 19 43 b2 4b-59 40 52 bb 49 98 2b a6   M....C.KY@R.I.+.
    0090 - 41 d8 a3 9e 1a 0b f4 34-da 17 35 35 39 67 7f e0   A......4..559g..
    00a0 - d0 9f 88 cd 81 0d 27 b5-cb 9c 85 e6 99 0b 43 9e   ......'.......C.
    00b0 - 90 a7 12 04 ef e3 41 e5-97 99 70 b4 ee c4 c2 c3   ......A...p.....
    00c0 - 45 80 46 6b e5 73 4d 5f-a9 21 32 ac 6d ce 1f 55   E.Fk.sM_.!2.m..U
    00d0 - e7 c7 1e d2 62 9b 60 3a-10 a1 aa 24 87 b8 66 0d   ....b.`:...$..f.
    00e0 - 57 c2 e9 61 08 9f c6 fd-8f 77 57 27 76 78 ed 9e   W..a.....wW'vx..

    Start Time: 1773447557
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 623FF706B33F5A770FC95F71EB5404EB162E1797AE220C496FBEA20AF003185E
    Session-ID-ctx: 
    Resumption PSK: 99762EFA65E7C67B9DEA7846F45D4C648D2E4E8AABBAAEAE9E817AAA18B5E9D9A11686D5A65875B9B5DEE40A1654E5A6
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 51 06 21 1e 0b a2 21 ea-1e e0 bc 7c d3 ac 09 99   Q.!...!....|....
    0010 - d9 e9 be df c5 cc b7 97-ef 41 0f cf 13 58 91 2e   .........A...X..
    0020 - 53 ae f9 33 ae b4 48 cd-f2 4f d2 9a b3 85 00 fb   S..3..H..O......
    0030 - e2 71 c2 c7 43 5e 3f 4e-5d 0b fb dc a4 b7 78 d2   .q..C^?N].....x.
    0040 - 8e af 23 45 0b 1d 61 bc-65 f7 b9 1c ff 3b 5e d9   ..#E..a.e....;^.
    0050 - fd 21 ea 92 a9 ae 56 1d-f0 24 e1 ba 9a 4d c6 4a   .!....V..$...M.J
    0060 - 64 bb a9 3b b6 30 19 3f-78 d6 3c 32 7f 14 d9 01   d..;.0.?x.<2....
    0070 - d2 37 29 b9 c8 79 ed 12-47 05 86 cf 2f 9c 62 eb   .7)..y..G.../.b.
    0080 - 65 0d ee f0 ec 15 ba 3b-31 2d 35 e5 2a 19 d5 a8   e......;1-5.*...
    0090 - af 50 5a 5b 94 8b 5a ea-ca 21 ae fa d0 f7 ae db   .PZ[..Z..!......
    00a0 - fb be a5 d1 39 41 79 13-46 51 60 a7 98 90 40 9f   ....9Ay.FQ`...@.
    00b0 - a2 c2 55 74 25 15 ac ec-fe 8c a5 4c 3b 53 3f 66   ..Ut%......L;S?f
    00c0 - 00 cc 80 bb 24 ff 1a 23-be 0f 03 77 d2 da e0 ca   ....$..#...w....
    00d0 - 1e f8 55 a3 0d c5 e6 e0-39 ea 1c ca 03 f9 b4 24   ..U.....9......$
    00e0 - e5 76 1d 68 6f 9c de 35-26 1b bc 4f 0b b2 1f c8   .v.ho..5&..O....

    Start Time: 1773447557
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

seth · Today 08:04:46

seems like it worked to me

Yup…

when aurutils is querying for updated pgkbuilds

The aur webpage otherwise works and you can also

curl -vL aur.archlinux.org > /dev/null

?
Can you

curl -A aurutils  -vL aur.archlinux.org > /dev/null

What is the actual curl command that causes this?
If it's coming from https://github.com/aurutils/aurutils/bl … ur-pkglist you can add "set -x" under the shebang to trace the script

Arch Linux

#1 Yesterday 21:47:27

constant 'curl: (56) Recv failure' attempting to update with aurutils

#2 Yesterday 22:52:31

Re: constant 'curl: (56) Recv failure' attempting to update with aurutils

#3 Today 00:27:54

Re: constant 'curl: (56) Recv failure' attempting to update with aurutils

#4 Today 08:04:46

Re: constant 'curl: (56) Recv failure' attempting to update with aurutils

Board footer