2017-06-29 13:19 ACST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000670Other Unix PortBugpublic2017-04-25 19:34
ReporterLewisR 
Assigned Topsmedley 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
Summary0000670: tnftp breaks binary transfers
Descriptiontnftp-20170409.zip

Have not tested uploads, nor have I tested text transfers. Binaries fail, with Interrupted system call.
Additional Informationls
[...]
-rwxrwxrwx 1 ftp -A--N 11578584 Dec 31 11:22 updates_31st_december_
2016.zip
226 Transfer complete.
mget updates_*
mget updates_31st_december_2016.zip [anpqy?]? y
227 Entering passive mode (192,168,100,2,199,214)
150 Opening BINARY mode data connection for file updates_31st_december_2016.zip (11578584 bytes).
 14% |**** | 1599 KiB 1.50 MiB/s 00:06 ETAt
nftp.exe: Reading from network: Interrupted system call
  0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.

Resulting file:

 4-09-17 11:20 1,637,752 124 updates_31st_december_2016.zip

[j:\]unzip -t updates_31st_december_2016.zip
Archive: updates_31st_december_2016.zip
  End-of-central-directory signature not found. Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive. In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0003135

LewisR (developer)

Tested with explicitly setting binary mode; same result.

ASCII transfers in both directions seem to work just fine, however, as does paging using the configured PAGER (less, in my case).

~0003136

psmedley (administrator)

I wonder if I broke this by modifying the code for non-blocking - will try and investigate this evening

~0003137

psmedley (administrator)

Yep, seems messing around with O_NONBLOCK broke ftp downloads. http://smedley.id.au/tmp/tnftp-20170410.zip seems to address

~0003138

LewisR (developer)

Sorry, Paul, but this did not do it:

 4-10-17 4:59 1,799,788 124 tnftp.exe

mget blue*
mget bluelion-4.9.1-en.7z [anpqy?]? y
227 Entering passive mode (192,168,100,2,207,82)
150 Opening BINARY mode data connection for file bluelion-4.9.1-en.7z (846488957
 bytes).
  0% | | 4054 KiB 3.80 MiB/s 03:31 ETAt
nftp.exe: Reading from network: Interrupted system call
  0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.

Try again?

~0003139

psmedley (administrator)

i'll try with a bigger test file, the file I tried was quite small

~0003140

psmedley (administrator)

Last edited: 2017-04-11 19:18

View 2 revisions

mget *.zip
mget client-4.x.zip [anpqy?]? y
227 Entering Passive Mode (192,168,1,200,252,222).
150 Opening BINARY mode data connection for client-4.x.zip (20234082 bytes).
100% |***********************************| 19759 KiB 7.22 MiB/s 00:00 ETA
226 Transfer complete.
20234082 bytes received in 00:02 (7.21 MiB/s)

Any environment variables set or anything to modify tnftp from the default settings?

i'm just using:
tnftp 192.168.1.200 21

to connect to a local ftp server

~0003141

LewisR (developer)

First, the exe I'm using has an md5sum of:

2ee94ed85add1385fe2644e407615bc1

(just to be sure we're using the same build)

Next, I started tnftp from a prompt, then:

o hawking
<username>
<password>
cd /ftp/arcanoae/bluelion/betas

and the above.

Hawking is on the local LAN segment, so there's no firewall or NAT traversal to be made. I'll try with a smaller file...

Nope:

mget *2017-04*
mget rpm-yum-base-os2-i686-2017-04-08.exe [anpqy?]? y
227 Entering passive mode (192,168,100,2,220,20)
150 Opening BINARY mode data connection for file rpm-yum-base-os2-i686-2017-04-0
8.exe (44382826 bytes).
  0% | | 0 0.00 KiB/s --:-- ETAt
nftp.exe: Reading from network: Interrupted system call
  0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.
mget rpm-yum-base-os2-i686-2017-04-08.zip [anpqy?]? n
binary
200 OK
get rpm-yum-base-os2-i686-2017-04-08.zip
local: rpm-yum-base-os2-i686-2017-04-08.zip remote: rpm-yum-base-os2-i686-2017-0
4-08.zip
227 Entering passive mode (192,168,100,2,220,31)
150 Opening BINARY mode data connection for file rpm-yum-base-os2-i686-2017-04-0
8.zip (44343605 bytes).
 13% |**** | 5798 KiB 1.37 MiB/s 00:26 ETAt
nftp.exe: Reading from network: Interrupted system call
  0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.

Local filesystem is JFS, though that should not matter, in this case.

Smaller test:

-rwxrwxrwx 1 ftp -A--N 5426 Aug 8 2014 zwrotlogs.txt
226 Transfer complete.
get zwrotlogs.exe
local: zwrotlogs.exe remote: zwrotlogs.exe
227 Entering passive mode (192,168,100,2,220,87)
150 Opening BINARY mode data connection for file zwrotlogs.exe (87928 bytes).
100% |***********************************| 87928 1.94 MiB/s 00:00 ETA
226 Transfer complete, closing data connection.
87928 bytes received in 00:00 (1.71 MiB/s)

That works, as does:

get whois.exe
local: whois.exe remote: whois.exe
227 Entering passive mode (192,168,100,2,220,106)
150 Opening BINARY mode data connection for file whois.exe (135867 bytes).
100% |***********************************| 132 KiB 132.68 KiB/s --:-- ETA
226 Transfer complete, closing data connection.
135867 bytes received in 00:00 (132.68 KiB/s)

So, it would seem that there is some size thing happening somewhere. Both of those smaller binaries came down intact.

~0003142

psmedley (administrator)

Last edited: 2017-04-25 14:27

View 2 revisions

ok, finally got around to trying to reproduce and succeeded on a larger file :)
tnftp.exe: Reading from network: Interrupted system call

OK, please try http://smedley.id.au/tmp/tnftp-20170425.zip

read() was failing with EINTR - added some code to workaround this :)

~0003143

psmedley (administrator)

OK upload was similarly broken, zip refreshed with the fix

~0003144

psmedley (administrator)

hmmmm except the file ends up corrupt.... need to think more on this and why read() is reporting EINTR and how to prevent this... setting the socket non-blocking didn't help.

I changed:
        while (bufrem > 0) {
            inc = read(infd, buf, MIN((off_t)bufsize, bufrem));
            if ((inc <= 0) && (errno != EINTR))
                goto copy_done;
            bytes += inc;
            bufrem -= inc;

to:
        while (bufrem > 0) {
            inc = read(infd, buf, MIN((off_t)bufsize, bufrem));
            if (inc <= 0)
                goto copy_done;
            bytes += inc;
            bufrem -= inc;

thinking now, of course this corrupts the file as inc is later used to change the amount of data to still be read, I probably need to reset inc to 0 if EINTR is received. Will play more tomorrow, at least I know where it's failing :)
+Notes

-Issue History
Date Modified Username Field Change
2017-04-10 01:02 LewisR New Issue
2017-04-10 01:02 LewisR Status new => assigned
2017-04-10 01:02 LewisR Assigned To => psmedley
2017-04-10 01:09 LewisR Note Added: 0003135
2017-04-10 05:41 psmedley Note Added: 0003136
2017-04-10 18:33 psmedley Note Added: 0003137
2017-04-11 08:09 LewisR Note Added: 0003138
2017-04-11 19:03 psmedley Note Added: 0003139
2017-04-11 19:09 psmedley Note Added: 0003140
2017-04-11 19:18 psmedley Note Edited: 0003140 View Revisions
2017-04-13 06:48 LewisR Note Added: 0003141
2017-04-25 14:11 psmedley Note Added: 0003142
2017-04-25 14:27 psmedley Note Edited: 0003142 View Revisions
2017-04-25 19:23 psmedley Note Added: 0003143
2017-04-25 19:34 psmedley Note Added: 0003144
+Issue History