gnirehtet with apacheCommonsNet #84
Comments
|
Thank you for the report. This is the same problem as #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?
|
|
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 |
|
OK thank you. The file is 19 lines long, is it complete? 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 device (with gnirehtet enabled), I connect to the host TCP socket: With the current |
|
@usatek I attempted to upload a file over http (using http://dl.free.fr), this version works, while connection hangs on the current However, it seems it have problems specifically with FTP. I tested the open anonymous-writable 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
<#84 (comment)>
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
<#84 (comment)>,
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 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?
|
The TCP connection acked packets received from the device immediately after it stored them into its buffers, but before they were written to the network socket. This made the client wrongly assume that the connection was super-fast, so the upload bandwidth was totally uncorrelated to the network socket bandwidth. As a consequence, the client filled the buffers up to saturation, leading to packet drops, that slowed down uploads dramatically. To make the client adapt the bittrate according to the associated network socket, do not ack the data immediately, but only once it is actually written to the network socket. See issues: - <#84> - <#79>
|
I commited the fix on 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?
The text was updated successfully, but these errors were encountered: