Overloading of network stack with requests (TLS and DNS). But you have a FritzBox, and this is interesting situation.
I though all FritzBoxes should not have this issue. 
Could you enable the debug log level in the FileZilla settings and provide an excerpt when uploads start to fail?
Also, did you try to upload with uplink?
Maybe it’s an old model? But dns requests aren’t a problem since the satellites sends IP adresses so the uplink doesn’t request any dns resolutions anymore.
Yes, the satellite returns only IPs,
Also. now I see a lot of errors such as:
1:09:16.788 DEBUG Failed uploading piece to node
Piece ID: ABAEKNRRNWXYWUDWF247WN5DPLWJEW555BND2ERUVNWN25NQZE5Q
Node ID: 12BPvyQwxZLxqzUaBCddFS77rj3uHjykpcGsiZMtuhHPcKjKdpX
Node Address: ***.***.***.***:20001
error: protocol: storage node overloaded, request limit: 5
...
11:09:43.022 DEBUG Upload to storage node failed
Node ID: 1wp8Nha8fkKTPXhuiJa49caZ3WyAa3VVD2C2CyTswxnSRs2x9k
error: protocol: storage node overloaded, request limit: 5
11:11:20.142 DEBUG Failed dialing for putting piece to node
Piece ID: JGR2Y5RILP5LVSNEDAARREIKX6JLDULWVB5D24YFZMMKUGY4JXGQ
Node ID: 123HeGHa9aSxsVxE7XLRFEAc7MFmpMj39p2Mqb96momG8nyEgZH
error: piecestore: rpc: dial tcp ***.***.***.***:28967: connectex: No connection could be made because the target machine actively refused it.
11:13:07.029 DEBUG Failed uploading piece to node
Piece ID: 3KTLGM2SQXGBS6TU7MZKDWWPUAGB7G5SW7FVO4NAOGYWT4Q7TQRA
Node ID: 1SDMVQTBHQvieiwqrrjeKx7QV7pANoedBRhdSjhvD2E6wtiESG
Node Address: ***.***.***.***:28967
error: protocol: storage node overloaded, request limit: 1
We must remove the request limit from storagenodes I think. Too many operators use it
11:14:54.248 DEBUG Upload to storage node failed
Node ID: 1itF8F3p3MZCaK9cDHbRQNaU3tHNzJL1BzQcviSZBKfaYAc5y5
error: context canceled; protocol: expected piece hash; context canceled; EOF
11:14:54.248 DEBUG Upload to storage node failed
Node ID: 1xA929xMLF4dipLfzJEEfRvCGFLJA7xHWasupKToj5CQ8PVKKE
error: context canceled; protocol: expected piece hash; context canceled; EOF
11:14:54.248 DEBUG Upload to storage node failed
Node ID: 12suuS3r493e1DqP8JxkWWeRg8w4sSiC9XTicddUoCnvwd7jbA3
error: context canceled; protocol: expected piece hash; context canceled; EOF
11:14:54.248 DEBUG Upload to storage node failed
Node ID: 12dPTXQhoFjMjC9FxRdqTt6PMEnwY2rBTM43zMyaDc1vivQW7k1
error: context canceled; protocol: expected piece hash; context canceled; EOF
Those ones on old version of storagenode software (seems do not used autoupdater, shame on them)
Yeah but wouldn’t that cause a problem for everyone? I just uploaded 2.7GB from Germany and didn’t encounter any restarts of the upload.
So statistically it should affect more than just a single tester and certainly not affect him on almost every bigger upload while it never affects me.
It could affect you, if your setup is not fast enough to request another 110 nodes during upload.
Perhaps the minimum level for upstream bandwidth.
I see a few differences between your setups:
| User | ISP connect | Router | Upstream bandwidth | Downstream bandwidth | Problems with upload? |
|---|---|---|---|---|---|
| @kevink | cable modem from ISP | FritzBox | 50 | xxx | No |
| @jammerdan | FritzBox | FritzBox | 40 | xxx | Yes, stuck with long files |
| @silaxe | cable modem | Linksys EA7500 | 20 | 400 | Yes, failed with “successful puts (72) less than success threshold (80)” |
Maybe yours ISPs are different too.
Now it went through after 3 hrs. This is weird.
First of all I gonna do a full restart of the box and the computer later to start with and try from different location.
I guess one could test that theory by using a VM limited to a 10Mbps network connection? If it’s only the upload bandwidth causing problems, this should show it.
Of course if it’s (also) the router, that wouldn’t make a difference then.
Ive uploaded a 6gig file with no restarts or any issues. Using a wireless connection.
Uploaded it 2 times
2020-11-13 09:23:33 1524 2 Command: put “D:\Downloads\Windows 10 X64}\windows10.iso” “/test2/windows10.iso”
2020-11-13 10:03:59 1524 2 Status: File transfer successful, transferred 6,142,656,512 bytes in 2425 seconds
It is very rare for domestic users to have symmetrical bandwidth, so if that is indeed the route of the problem then it’s a biggy.
Also, most users will have ISP-supplied routers.
My router is not supplied from an ISP. It’s a UniFi DreamMachine Pro which should cope with a lot more than I can ever throw at it.
Hello,
The page not working for me… I write email and click to “Try Tardigrade” but nothing happen
Andoid, chrome
W10 chrome and firefox without adblock
I generate api key before 10 days without problem… But now i have problem to listing bucket… So i try new api key
Can you be clearer about your issue it seems you contradicted your own problem. Or I just don’t understand.
Before 10 days i generate api key… Everything ok… Today in the filezilla i cannot listing bucket… Ok i upload only test data to tardigrade…
So i try generate new api key on fz.tardigrade.io but i cannot generate new api key
Does it give an error? Did you change the password you orginally used to set up?
I just tested the site and I got a new API after putting an email in and setup in filezilla without an issue.
This error is on filezilla
I have cached password and i dont change it
| Status: | Connecting to europe-west-1.tardigrade.io… |
|---|---|
| Response: | fzStorj started, protocol_version=2 |
| Command: | host europe-west-1.tardigrade.io:7777 |
| Command: | key ******************************************************************************************************* |
| Command: | pass ********** |
| Status: | Retrieving directory listing of “/”… |
| Command: | list “/” |
| Error: | Failed to retrieve directory listing |
… so after a lot of try (10 - 15)… the bucket is listed
| Status: | Connecting to europe-west-1.tardigrade.io… |
|---|---|
| Response: | fzStorj started, protocol_version=2 |
| Command: | host europe-west-1.tardigrade.io:7777 |
| Command: | key ******************************************************************************************************* |
| Command: | pass ********** |
| Status: | Retrieving directory listing of “/”… |
| Command: | list “/” |
| Status: | Directory listing of “/” successful |
but next try to connect is failed again 
on list “/”
Maybe a port is getting blocked are you blocking any ports?
I cannot see a FW but this is output from portquery
But i dont know why once a bucket was listed :o
=============================================
Starting portqry.exe -n europe-west-1.tardigrade.io -e 7777 -p BOTH …
Querying target system called:
Attempting to resolve name to IP address…
Name resolved to 146.148.29.23
querying…
TCP port 7777 (unknown service): LISTENING
UDP port 7777 (unknown service): LISTENING or FILTERED
portqry.exe -n europe-west-1.tardigrade.io -e 7777 -p BOTH exits with return code 0x00000002.
maybe i have problem with passwords 
i go to create a tardigrade account its better for me.
Thanks for your time 
I have tried to limit the bandwidth with --bwlimit in the rclone, it’s doesn’t give me errors like “not enough nodes”
But you are right - it should be limited on router (or in VM/docker)
this is useless. All data transfers are happening between the FileZilla (uplink) and nodes, so connection to the satellite doesn’t matter. It’s only address book, audit, repair and payment service.
I limited upstream bandwidth to 20Mbps, but the file is uploaded anyway. It was in 5 times slower, however it’s uploaded.