amtm Intermittent connection resets when checking for or downloading script updates

[grim42]

Since around the start of July I've been seeing intermittent but consistently repeatable errors when checking for updates ("u") in amtm, and when checking for/downloading updates within the scripts themselves.

The issue is due to the underlying curl invocation getting intermittent connection resets from raw.githubusercontent.com, around 10% of the time. I can reproduce this fairly consistently (using an arbitrary GitHub repo):

for i in {1..100}; do
    curl -fsSNL -o /dev/null --retry 3 https://raw.githubusercontent.com/dave14305/FlexQoS/master/flexqos.sh
done

curl: (35) Recv failure: Connection reset by peer
curl: (56) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

or with verbose output:

* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to raw.githubusercontent.com:443
* Closing connection
curl: (35) Recv failure: Connection reset by peer

* OpenSSL SSL_read: Connection reset by peer, errno 54
* Failed receiving HTTP2 data: 56(Failure when receiving data from the peer)
* Connection #0 to host raw.githubusercontent.com left intact
curl: (56) Recv failure: Connection reset by peer

Depending on where the failure occurs in the connection, this manifests as amtm showing "-> MD5 upd", "upd err", or simply "<-" for different scripts. This happens almost every time I run the "u" command. Some examples:


I suspect this is an issue with my ISP routing traffic to the GitHub Fastly cache and I'm talking to them about it. I can't reproduce this for other sites.

I'm wondering though whether there's anything I could do as a workaround in the interim? I had some success adding "--retry-all-errors" to the curl command line that is used by amtm (although modifying that locally causes amtm to see itself as having an MD5 mismatch). Would it be feasible to add that to amtm in general?

 

[eibgrad]

FWIW, I tried your loop here, both w/ Merlin and a Linux desktop. No issues.

If you suspect the ISP, perhaps route the Github public IP(s) through a VPN.

 

[grim42]

FWIW, I tried your loop here, both w/ Merlin and a Linux desktop. No issues.

If you suspect the ISP, perhaps route the Github public IP(s) through a VPN.

Thanks for the suggestion. I don't have a VPN handy but I am able to reproduce this running from my laptop when connected to wifi, and cannot reproduce it when I connect my laptop to a mobile data connection (ie. bypassing router and ISP).

I don't think it's anything to do with the router (since nothing changed there, and the nature of the failure seems to be site specific) so I'm assuming it's the ISP. Out of interest, I found a post on the Fastly community forum which seems to be a similar issue where Anycast multipath routing was suspected as the cause. I'm hoping my ISP can resolve it.

Aside from that though, would using curl's "--retry-all-errors" in amtm have any downsides? I'm thinking it could make the tool more resilient to intermittent connection problems in general. Right now it's detecting truncated responses as updates being available due to MD5 mismatches.