Closed usatek closed 6 years ago
Thank you for the report.
This is the same problem as https://github.com/Genymobile/gnirehtet/issues/79.
What is your device?
I am using Lg G6, do you thing that it is device related issue? I will check it tomorrow on other devices. Thanks for issue link, I will check it.
I think I understand the problem.
TCP connections ack packets received from the client immediately, and store them into its buffers.
This makes the client think that the connection is super-fast, while it may be actually slower (the data is typically written slower to the network socket). As a consequence, the TCP connection buffers fill up until saturation, so packets are dropped, slowing down uploads dramatically.
To (probably) fix the problem, data should be acked only once written to the network socket.
I quickly tried a fix, but details are a bit more complicated than I thought. I'll will work on it when I have some time.
We managed to copy images. We made workaround for now. But it is not good way. We copy only one file during FTP connection. Ater copy we disconnect FTP client and connect it again to copy another file. This slow as a lot but at least we are able to copy files. Of course we have to do this only in USB connection, in WiFi, we dont have to do this.
Problem still exists, our workaround is no good option. Your cfix would be very helpful.
@usatek I implemented (quick&dirty) in the Rust version what I had in mind to fix the issue.
Could you test this version, please, to (in)validate that it works as expected?
gnirehtet-rust-linux64-issue84.zip
(sha256: 375d3be0b67322f0781ffe51942cc932ec2f8f568dd4fac7407bf8930392be9b)
gnirehtet-rust-win64-issue84.zip
(sha256: 08c99484dd636d09e10e265b1b00a54dce632ac66dfdbf04ff406795afa4ff3a)
It still not working, but thanks for quick try. Only one photo has been copied, and during this copy comunication hangs. The rest is skipped because of the suspension of FTP communication.
Ok, could you post the logs, please, to see if the behavior is the same?
logFile.txt I added log file from last attempt. I tried to copy three files. First file hangs communication. I have enough for today. I will come back to this tomorrow. Have a nice weekend.
OK thank you. The file is 19 lines long, is it complete?
Ignoring packet 1462048573; expecting 1462048573
Ahah, I didn't update the log for message numbers :)
There is no "Not enough space, dropping packet", so it's not the same problem. Probably my changes introduced a bug somewhere.
Yes log was a lot shorter. I tried other FTP apps today and effect was the same. They copy one or two files from all list an they hang. We found one app in google play which offers reverse tethering communication over USB. It copy all files But it is paid app. There is free demo "Reverse tethering NoRoot Free". I wonder how they do it. I will try to check communication between my app and FTP through gnirehtet on Wireshark app tomorrow, maybe there I will see something what will be helpful for you.
I'm back from my holidays.
I reproduce the problem using netcat as follow on a Nexus 5X.
On the host computer, I listen on port 1234, and use pv
to limit the bandwidth:
nc -l -p 1234 | pv -L 500k > /tmp/myfile
On the device (with gnirehtet enabled), I connect to the host TCP socket:
adb shell '/data/local/tmp/nc 192.168.0.2 1234 < /sdcard/myfile'
With the current dev
version of gnirehtet, after ~9M, the connection hangs. But with the version provided here, I can't make the connection hang.
@usatek I attempted to upload a file over http (using http://dl.free.fr), this version works, while connection hangs on the current dev
branch. So at least, it fixes something.
However, it seems it have problems specifically with FTP. I tested the open anonymous-writable speedtest.tele2.net
from here), but I can't even start uploading the file (while it – sometimes – works when connected via wifi). It blocks even before uploading, so it may be a problem different from yours.
What FTP client do you use? What FTP server?
Hi, We use Apache-Common-Net library. We tested this error on other FTP apps from google play, but I think that most of them use the same library as we. We tested it on other FTP servers. The result was the same, connection was hanged after one file when we have a connection through gnirehtet. If we use Wi-Fi all files are copied without any problem. We checked Apache-Common-Net library, after file copy this library tryies to get response from FTP server if this server is ready to copy another file, and after sending request it is waiting for response from FTP server. But the response never comes. We can set timer on socket to terminate connection after some period time and try to connect again and copy next file. But this method is very slow and on some FTP servers we quickly get max user response on connnection, because on the FTP server side, maintaining the connection has been set for a long time
2018-02-25 18:04 GMT+01:00 Romain Vimont notifications@github.com:
@usatek https://github.com/usatek I attempted to upload a file (over http), this version https://github.com/Genymobile/gnirehtet/issues/84#issuecomment-366272417 works, while connection hangs on the current dev branch. So at least, it fixes something.
However, it seems it have problems specifically with FTP. I tested the open anonymous-writable speedtest.tele2.net from here https://stackoverflow.com/a/29104430/1987178), but I can't even start uploading the file (while it – sometimes – works when connected on wifi). It blocks even before uploading, so it may be a different error from yours.
What FTP client do you use? What FTP server?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Genymobile/gnirehtet/issues/84#issuecomment-368325616, or mute the thread https://github.com/notifications/unsubscribe-auth/AiSb7cmnrUztJ3ED1m2qoUZZMXZah9e1ks5tYZKvgaJpZM4SHi3I .
Thank you for the details.
So I wrote a test application using Apache-Common-Net, it helped a lot to reproduce and investigate the problem. I now understand why my quick&dirty patch (this version) breaks the connection (at the very end): as soon as FIN
is received, all pending data are ignored.
I will think how to solve it properly.
@usatek I am working on a proper fix.
Could you confirm that this binary fixes the problem for you, please?
gnirehtet-rust-linux64-issue84-v2.zip
(sha256: 33d34d6c88e11b6eee1e3785bd395574ae88ca13c1eff003bb1db04ed4d464e1)
gnirehtet-rust-win64-issue84-v2.zip
(sha256: 2d0ace3ce7b722ac5cf24f7a8db4f003cee6218fae3cc8a1d8df183354736f87)
I commited the fix on dev
. It works for me, so I'm closing.
Feel free to reopen if you still encounter problems.
I have made a test, all files are copied now on net drive or FTP server very fast. Excelent job, thanks for quick response and for this fix:)
It's in the v2.2 release: https://github.com/Genymobile/gnirehtet/releases/tag/v2.2
I am trying to use gnirehtet to copy images to FTP using apacheCommonsNet library ver 3.6. When I try to copy files I usually get one uncompleted file. Log from bash shows a lot of "Ignoring packet". I dont have this problem with apacheCommonsNet when I use WiFi. Can it be problem with gnirehtet?