Croc freezes/stalls during large file transfer #437
Comments
|
I cannot reproduce this bug. Is this on LAN? Or using public relay? |
Using a public relay. |
|
What is the speed of transfer? I wonder if there is a flaky connection at one your computers |
|
About 2MB/s. I have experienced a drop before when using this, although with smaller files, and it will cancel the transfer, whereas in this case it just hangs in the frozen state. I'm not exactly sure how stable the connections are required to be, or how flaky it has to be to get it to hang like this, but both connections are generally solid and I have no other issues using other tools, playing games, etc. |
|
I can also confirm this "bug" and noticed it a lot of times. Unfortunately I didn't find out a way to safely reproduce it yet. I was able to encounter the problem while running in debug mode on both sides. While on the sender side there is no useable debug message there is some debug output on the receiver side. Hope that helps a little bit... |
|
Thanks @jnko for confirming. All your computers and relay are using the latest version of croc?
Are you running multiple instances of croc to do this? I don't think this is the problem, but it is useful to know. |
I'm using VERSION: v9.4.2-49f50a5 on both machines. The sender also runs the relayserver in the same user context. There is no special high load or io on both machines, nor a flaky internet connection. Sometimes the testfiles will be transferred without problems, sometimes not. I've no clue what indicator will make this happen. My next idea is to test the trnasfer from/relay/to the same machine in order to to rule out that it has something to do with the internet connection or probably on two VMs within a isolated LAN. |
|
Have the same (or at least a similiar) problem on the newest version. We first tried with a 5.9gb file but that always failed, so we switched to smaller files which also fail 1-3 times per file (1.2gb). Here's the log if you need it logidk what is considered sensitive data |
|
Same issue with me. Use CROC between my Seedbox and my machine. It started happening occasionally late last year. Now it happens all the time, with any file over ~1Gb. Croc version v9.5.1-b0e7d4d on both sides. On the SeedBox I have Ubuntu and on my side I already tried with Linux and Windws version. |
|
Could be related to something I observed with SSH once. If packets run through only USB Ethernet interfaces, on a PFSense/BSD router, then occasionally, some packet corruption will cause some network failure that causes SSH to fail, despite SSH normally correctly rejecting and tolerating corrupt packets. Some (IIRC Intel NICs) have been historically preferred for a reason after all. I doubt such unusual issues would happen through the network hardware of ISPs or the typical internet. Thus, I suggest it may be worth checking what network hardware is between the computers and their ISPs (ie. what router are you using, what NICs is it using, etc). |
|
Have the same problem on the newest version. It seems the sender think that it had send all bytes, but the receiver lost some package. sender: ➜ ✗ croc send ./allinone.tar
Sending 'allinone.tar' (4.1 GB)
Code is: 1566-europe-costume-diamond
On the other computer run
croc 1566-europe-costume-diamond
Sending (->172.17.0.1:54446)
allinone.tar 100% |████████████████████| (4.1/4.1 GB, 14.899 MB/s)
2022/07/20 15:51:40 EOF
➜ ✗ md5sum allinone.tar
ee0f7ebfa8d0d4dd44035627dd6c600c allinone.tarreceiver: ➜ croc 1566-europe-costume-diamond
Accept 'allinone.tar' (4.1 GB)? (Y/n) y
Receiving (<-172.17.0.1:54420)
allinone.tar 98% |███████████████████ | (4.0/4.1 GB, 13.035 MB/s) [4m59s:6s]2022/07/20 15:51:40 EOF
➜ md5sum direct.txt direct.1.txt
➜ md5sum allinone.tar
921f9b428f7dd966de2c0c942d06ccb0 allinone.tar |
|
Yes. This bug is happening with me again (it happened on v9.5.1). The transfer starts well, but the connection gets significantly slower, with 50% of the transfer done, and I need to restart a few times to get it done. |
|
I just experienced this bug on the latest version (go version on linux and brew version on mac). Transfer rate was somewhere about 8 to 10 MB/s. At some point the ETA timer froze and nothing seemed to happen anymore. The problem was solved after both endpoints switched from WiFi to LAN. |
|
How reproducible is it? Does it stall everytime? I have never been able to reproduce this |
|
It is simply not re-produce able. Just select a bunch of large files on the one side and try to receive it on the other. In best over the internet, not localhost. It happens more or less often. Today I tried to transfer 16 files with 8.9GB in size, and it failed >25 times in series at all. Sorry, it's annoying, really. I already went over to just try to transfer just 3-6 large files at once and then another bunch. It fails less often but takes more time at all. The re-transfer of large files fails more often than the re-transfer of less. (sorry, nothing about to harm personally you but when I am in hurt and I need to transfer a large amount of data over the net, and it fails over and over again, you need to split it all up and try again and again and again ... you simply start to shout out loud some really nasty words. The deadline is already passed, it is still not working and.... just annoyed, I will give it up for today) |
|
Happens to me also. |
|
How reproducible is it? Are you using LAN or a public relay? |
|
Currently I'm in Munich in an airport lounge using the public relay server. |
|
I'm transfering now 1.2 GB files but had the same problem with 26 GB where the speed went down. |
|
Can you try to wget a large file and watch the transfer rate? With a public ISP like at an airport you never know if they are throttling you |
|
I tried https://speed.hetzner.de/10GB.bin with curl and the speed was always between 2.5 MB/s and 3 MB/s and no slowdown. |
|
another debug output, this time windows |
|
I'm also experiencing this, slows down, stalls, then waits for a long time before EOF. Will try resending with --debug. |
|
Stale issue message |
|
Today experienced similiar issue, tried to download a 40 GB file from a friend, abortet at 14% and now at 60%. Takes a long time to resume the download. We are both on Windows 10 with 64 bit |
|
is it reproducible? |
|
Unfortunately, we didnt find out what causes this bug, although it keeps happening. One thing that seems to cause it to stop is turning off the monitor |
Experiencing this almost every transfer. How can the monitor be turned off? |
|
I think in many cases, this is happening because people are sending files that are changing. if this is happening to you, please check to see if your file has changed in any way. croc will not send a file as it is being written. will close now because I have not been able to reproduce any of these. |
Describe the bug
Trying to transfer a large file (movie) that is around 20GB between two machines. Sometimes will transfer a few gigs before stalling, other times will transfer 10+gigs and then stall.
Everything looks normal, like it's still downloading, except the download speed will go to ~100kbps ish and then stop updating. Estimated time is also frozen and does not update. Will just sit there doing nothing indefinitely. On the sending machine, it looks like the speed is stuck at the normal rate, on the receiving machine the speed is as described above, and also frozen.
To Reproduce
Steps to reproduce the behavior:
Expected behaviour
I expect to start the transfer and it complete without stalling.
Version
croc version v9.4.2-49f50a5
Additional context
It has happened 3 times now during the transfer of this one movie file. Once at 17%, once at 25% and then finally once again at 95%.
This wouldn't be a big deal, as you can just resume and be on your way, but it seems like when transferring large files, the tool takes a very long time to load (which seems to be related to file size in my brief testing), so restarting the download can be time-consuming, and of course, it requires monitoring until the download is complete.
The text was updated successfully, but these errors were encountered: