Cannot connect to BackBlaze B2 - connection reset by peer

[dkarelov]

Arch Linux, Duplicacy 2.1.1

Configuration was working perfectly fine, until at some moment a couple of weeks ago, all backups to B2 ended up with errors. Basically any connections to B2 now end up with errors:

➜duplicacy -d list -a -storage weekly Storage set to b2://weekly Reading the environment variable DUPLICACY_WEEKLY_B2_ID Reading b2_id from keychain/keyring Reading the environment variable DUPLICACY_WEEKLY_B2_KEY Reading b2_key from keychain/keyring Reading the environment variable DUPLICACY_WEEKLY_B2_ID Reading the environment variable DUPLICACY_WEEKLY_B2_KEY Reading the environment variable DUPLICACY_WEEKLY_PASSWORD Reading password from keychain/keyring URL request 'https://f002.backblazeb2.com/file/weekly/config' returned an error: Head https://f002.backblazeb2.com/file/weekly/config: read tcp 192.168.1.1:55844->206.190.215.16:443: read: connection reset by peer [...6 more requests...] URL request 'https://f002.backblazeb2.com/file/weekly/config' returned an error: Head https://f002.backblazeb2.com/file/weekly/config: read tcp 192.168.1.1:55872->206.190.215.16:443: read: connection reset by peer Failed to download the configuration file from the storage: Maximum backoff reached

Network connectivity is obviously fine. How to troubleshoot this?

[m-o-e]

Same here on OSX.

v2.1.0 works fine. v2.1.2 gives: Failed to load the Backblaze B2 storage at b2://xxx: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: write tcp ...: write: connection reset by peer

[m-o-e]

When I locally build from git tag v2.1.0 (using go1.11.2 darwin/amd64) then that version also fails to connect. 🤔

This seems to be something SSL related but I haven't managed to narrow it down.

[gilbertchen]

@m-o-e Can you run both versions with duplicacy -d list to see the differences?

[m-o-e]

@gilbertchen

v2.1.0

$ ~/bin/duplicacy_osx_x64_2.1.0 -d list
Storage set to b2://xxx
Reading the environment variable DUPLICACY_B2_ID
Reading the environment variable DUPLICACY_B2_KEY
Reading the environment variable DUPLICACY_B2_ID
Reading the environment variable DUPLICACY_B2_KEY
Reading the environment variable DUPLICACY_PASSWORD
Using 16384 iterations for key derivation
URL request 'HEAD https://f000.backblazeb2.com/file/xxx/nesting' returned status code 404
b2_download_file_by_name did not return headers
Chunk read levels: [1], write level: 1
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: 57feee2bd57626c6756e7176ba541ab1800febfd41ca4416aa14210f0977bd4d
Reading the environment variable DUPLICACY_PASSWORD
id: xxx, revisions: [], tag: , showFiles: false, showChunks: false
Listing revisions for snapshot xxx
Loaded file snapshots/xxx/1 from the snapshot cache
Snapshot xxx revision 1 created at 2018-04-08 15:45 -hash
Loaded file snapshots/xxx/15 from the snapshot cache
Snapshot xxx revision 15 created at 2018-04-15 17:54
...

v2.1.2

$ ~/bin/duplicacy_osx_x64_2.1.2 -d list
Storage set to b2://xxx
Reading the environment variable DUPLICACY_B2_ID
Reading the environment variable DUPLICACY_B2_KEY
Failed to load the Backblaze B2 storage at b2://xxx: Post https://api.backblazeb2.com/b2api/v1/b2_authorize_account: write tcp 10.0.0.7:58802->162.244.62.195:443: write: connection reset by peer

[gilbertchen]

I wonder if there is any firewall on your local machine that blocks the outgoing connections. B2 servers usually don't close the connection unexpectedly. There haven't been any code changes in the call to b2_authorize_account between 2.1.0 and 2.1.2 (the only change was related to the handling of application keys, but if you're using the master key there is no way the B2 servers can distinguish the call made by 2.1.0 and 2.1.2).

[dkarelov]

It seems I found a remedy in my case - it might be related to regulatory blocking of B2 ip ranges in some countries (Russia in particular). I solved it by providing a http proxy through environment variable: $ export http_proxy=http://proxy:port

Would it be possible to add a switch to duplicacy to set up the proxy directly? This would also allow to use SOCKS5, as so far only HTTP option available.

[m-o-e]

@gilbertchen You are right! It was a network problem in my case, too - sorry for the noise.

For the record: LittleSnitch behaves a little strange when it has been updated and there was no reboot, yet. Network access continues normally for existing binaries but newly added binaries (such as my own build of duplicacy) are silently denied. A reboot fixed it.

[sergeevabc]

Had no problems with initialization and backup to B2 via Restic today, yet Duplicacy 2.1.2 stuck at

$ duplicacy init *** b2://***
Enter Backblaze Account ID:***
Enter Backblaze Application Key:***
(long pause)
Failed to download the configuration file from the storage: Maximum backoff reached

[gilbertchen]

@sergeevabc can you run duplicacy -d init ... to see which url request failed?

[sergeevabc]

@gilbertchen, thanks for the tip, here goes the output

URL request 'https://f002.backblazeb2.com/file/B2MyDuplicacy/config' returned an error:
Head https://f002.backblazeb2.com/file/B2MyDuplicacy/config:
read tcp *.*.*.*:50588->206.190.215.16:443:
wsarecv: An existing connection was forcibly closed by the remote host.

It seems 206.190.215.16 is currently blacklisted in Russia, as @k3kc pointed out earlier.

Fortunately they have an official email for complaints (zapret-info@rkn.gov.ru), so I’ve just filled one.