Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Both IFTP problems remain in build 50

vefatica

vefatica

May
13,137
180
Below, 2 different results from DIR and a failed transfer.
Code: 
v:\> ver

TCC  16.03.50  Windows 7 [Version 6.1.7601]

v:\> iftp "ftp://lucky.syr.edu/4plugins/test"

v:\> dir ftp:2*

 Directory of  ftp://lucky.syr.edu/4plugins/test/2*

2014-06-05  01:52  1,048,576  20.bin
2014-06-05  01:52  2,097,152  21.bin
2014-06-05  01:52  4,194,304  22.bin
2014-06-05  01:52  8,388,608  23.bin
2014-06-05  01:52  16,777,216  24.bin
2014-06-05  01:52  33,554,432  25.bin
2014-06-05  01:52  67,108,864  26.bin
2014-06-05  01:52  134,217,728  27.bin
2014-06-05  01:52  268,435,456  28.bin
2014-06-05  01:53  536,870,912  29.bin
  1,072,693,248 bytes in 10 files and 0 dirs

v:\> dir ftp:2*

 Directory of  ftp://lucky.syr.edu/4plugins/test/2*

2014-06-05  01:52  1,048,576  20.bin
2014-06-05  01:52  2,097,152  21.bin
2014-06-05  01:52  4,194,304  22.bin
2014-06-05  01:52  8,388,608  23.bin
2014-06-05  01:52  16,777,216  24.bin
2014-06-05  01:52  33,554,432  25.bin
2014-06-05  01:52  67,108,864  26.bin
2014-06-05  01:52  134,217,728  27.bin
2014-06-05  01:52  268,435,456  28.bin
  535,822,336 bytes in 9 files and 0 dirs

v:\> copy "ftp:20.bin"
ftp://lucky.syr.edu/4plugins/test/20.bin => V:\20.bin
TCC: FTP protocol error: 426 Data connection unexpectedly closed, file transfer
/4plugins/test/20.bin aborted by client. "/4plugins/test/20.bin"
  0 files copied  1 failed
 
And they also remain on my work computer. On both computers they are exactly as describer in earlier threads.
 
rconn said:
Not reproducible here with 16.03.50. I did 50 dir's and they all returned identical results, and 50 copies and they all copied the "20.bin" file.

Anybody else able to reproduce this?
Click to expand...
Try bigger files. As before, on one client, it starts failing with file sizes above 131072, on the other client, above 1984.
 
And (I didn't try this before) there are no errors if, with TCC v16, I use the IPWorks DLLs from the v15 installation.
 
And (for the sake of symmetry) v15 has the same errors when it's using the v16 IPWorks DLLs.
 
I noticed more. Here are the local results of the command
Code: 
do i=8 to 20 ( copy /q ftp:%i.bin ) & d *.bin
("d" is "*dir /a /p /m /k /h /ne"). There were no error messages until the file size is over 131072 but before that, some which appear to have succeeded, didn't really succeed, with only 1 packet (exactly 1460 bytes) making it to the destination file. The size of N.bin should be 2^N.
Code: 
TCC: FTP protocol error: 426 Data connection unexpectedly closed, file transfer
/4plugins/test/18.bin aborted by client. "/4plugins/test/18.bin"
TCC: FTP protocol error: 426 Data connection unexpectedly closed, file transfer
/4plugins/test/19.bin aborted by client. "/4plugins/test/19.bin"
TCC: FTP protocol error: 426 Data connection unexpectedly closed, file transfer
/4plugins/test/20.bin aborted by client. "/4plugins/test/20.bin"
2014-06-04  21:52  256  8.bin
2014-06-04  21:52  512  9.bin
2014-06-04  21:52  1,024  10.bin
2014-06-04  21:52  1,460  11.bin
2014-06-04  21:52  1,460  12.bin
2014-06-04  21:52  1,460  13.bin
2014-06-04  21:52  1,460  14.bin
2014-06-04  21:52  1,460  15.bin
2014-06-04  21:52  1,460  16.bin
2014-06-04  21:52  1,460  17.bin
 
Right after updating to version 51, I tried Vince's test using

do i=8 to 20 ( copy /q ftp:%i.bin ) & d *.bin

and all the files copied perfectly.
 
On the ones that didn't produce an error, but which resulted in only 1460 bytes in the destination file, the server logged that the transmission of **all** the bytes was successful.
 
vefatica said:
I noticed more. Here are the local results of the command
Code: 
do i=8 to 20 ( copy /q ftp:%i.bin ) & d *.bin
Click to expand...

And here's my local results of your command:

Code: 
[D:\takecommand16\tcc\temp]iftptest
iftp "ftp://lucky.syr.edu/4plugins/test"
do i=8 to 20 ( copy /q ftp:%i.bin )
dir /a /p /m /k /h /ne *.bin
 6/04/2014  21:52             256  8.bin
 6/04/2014  21:52             512  9.bin
 6/04/2014  21:52           1,024  10.bin
 6/04/2014  21:52           2,048  11.bin
 6/04/2014  21:52           4,096  12.bin
 6/04/2014  21:52           8,192  13.bin
 6/04/2014  21:52          16,384  14.bin
 6/04/2014  21:52          32,768  15.bin
 6/04/2014  21:52          65,536  16.bin
 6/04/2014  21:52         131,072  17.bin
 6/04/2014  21:52         262,144  18.bin
 6/04/2014  21:52         524,288  19.bin
 6/04/2014  21:52       1,048,576  20.bin

Ran it multiple times, on three different machines. This may be something unique to your ISP, or the result of a third-party app (or firewall?) on your systems.
 
On both computers where I can test, v16 is OK with the v15 IPWorks DLLs, and v15 produces the same errors using the v16 IPWorks DLLs.

All other ways I can use FTP ... FTP.EXE, browsers, CuteFTP, and TCC own non-IFTP support are OK.

It seems a stretch to suspect anything but the IPWorks DLLs and TCC interaction with them.

I already posted network captures showing peculiar behavior. Would you like me to post new ones with TCC 16's behavior with each set of IPWorks DLLs?

Here it is with the built-in non-IFTP support ... perfect.

Code: 
v:\> do i=8 to 24 ( copy "ftp://lucky.syr.edu/4plugins/test/%i.bin" )
ftp://lucky.syr.edu/4plugins/test/8.bin => V:\8.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/9.bin => V:\9.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/10.bin => V:\10.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/11.bin => V:\11.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/12.bin => V:\12.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/13.bin => V:\13.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/14.bin => V:\14.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/15.bin => V:\15.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/16.bin => V:\16.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/17.bin => V:\17.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/18.bin => V:\18.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/19.bin => V:\19.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/20.bin => V:\20.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/21.bin => V:\21.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/22.bin => V:\22.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/23.bin => V:\23.bin
  1 file copied
ftp://lucky.syr.edu/4plugins/test/24.bin => V:\24.bin
  1 file copied

v:\> d *.bin
2014-06-04  21:52  256  8.bin
2014-06-04  21:52  512  9.bin
2014-06-04  21:52  1,024  10.bin
2014-06-04  21:52  2,048  11.bin
2014-06-04  21:52  4,096  12.bin
2014-06-04  21:52  8,192  13.bin
2014-06-04  21:52  16,384  14.bin
2014-06-04  21:52  32,768  15.bin
2014-06-04  21:52  65,536  16.bin
2014-06-04  21:52  131,072  17.bin
2014-06-04  21:52  262,144  18.bin
2014-06-04  21:52  524,288  19.bin
2014-06-04  21:52  1,004,836  20.bin
2014-06-04  21:52  2,097,152  21.bin
2014-06-04  21:52  4,194,304  22.bin
2014-06-04  21:52  8,388,608  23.bin
2014-06-04  21:52  16,777,216  24.bin
 
vefatica said:
It seems a stretch to suspect anything but the IPWorks DLLs and TCC interaction with them.

I already posted network captures showing peculiar behavior. Would you like me to post new ones with TCC 16's behavior with each set of IPWorks DLLs?
Click to expand...

Until somebody else can reproduce this, it seems a stretch to think that there's this serious a bug in the ipworks dll's, and it only affects you. And the IFTP and non-IFTP copies use exactly the same code. I still think there's an additional factor here that you haven't yet mentioned. (Like a really short FTP timeout?)
 
How do I control "FTP timeout"? And why would the result (of any setting) be IPWorks DLL-specific?
 
Vince - for FTP Timeout:

Option then <enter>
Internet Tab
Timeouts are 3rd column, 2nd set of items...
 
In the OPTION dialog I had 5/5/30 for timeouts. Those are the settings for all my versions of TCC. I changed them to 180/180/180 as shown in an image in the help. It made no difference. [Really!, 180 seconds!] What are the defaults? What's recommended?

However, when I checked "Passive FTP" (which I have never used) the problems went away. In your tests, was "Passive FTP" checked? If so, try again with it unchecked?

Nevertheless, I am not a happy camper. The problem is specific to the newest IPWorks DLLs (**NO** other differences) and I don't like changing my settings to accommodate buggy software. Somebody should be looking for a bug.

The errors are certainly not related to anything outside the local computer. I get them on lucky when I connect to the FTP server at localhost (and get rather fast transfers!).
 
P.S. I have mine set to 180..... not sure what the default is.......
 
Do the timeout settings even work? I get this after 22 seconds regardless of what my settings are.
Code: 
v:\> iftp "ftp://izebug.syr.edu/4plugins/test"
TCC: Timeout. "izebug.syr.edu"
 
So I found Rex's and Jay's tests in the FTP log. Both were using "Passive FTP". Please try again without "Passive FTP".
 
rconn said:
There wouldn't be any point, as the firewall would block FTP with "Passive FTP" off.
Click to expand...
What firewall blocks active FTP? One of the points of your Windows firewall rules is to allow that. Active FTP is all I have ever used. Nearly all connections to lucky are from "JPUser@" and only about 5/13 of them use PASV. FTP.EXE can't even do passive FTP.
 
P.S. That's why TCC's firewall rules are inbound rules (recent thread on the subject) ... to allow, for example, TCC to open a port, listen on it, advertise it to the server, and have the server initiate the data connection to it. That's how active FTP works and your firewall rules make it allowed.
 
Every firewall I know of blocks the higher port #'s that active FTP requires. (And IIRC you rejiggered the TCC & TCMD firewall rules on your system to block the additional default access that the installer configures for TCC -- which seems kind of odd since you also turned off Passive FTP!)
 
rconn said:
Every firewall I know of blocks the higher port #'s that active FTP requires. (And IIRC you rejiggered the TCC & TCMD firewall rules on your system to block the additional default access that the installer configures for TCC -- which seems kind of odd since you also turned off Passive FTP!)
Click to expand...
The "TCC v16" inbound rule is an Enabled/Allow/Any/Any/Any/Any/Any/Any/Any rule; in particular, any port (inbound). I have disabled it at times to test something or to make a point, but it's generally enabled. When I disable it I can't do active FTP. Here's such an attempt.
Code: 
v:\> iftp /v "ftp://lucky.syr.edu/4plugins/test"
<pleasantries deleted>
v:\> dir ftp:
PWD
257 "/4plugins/test" is current directory.
PWD
257 "/4plugins/test" is current directory.
PWD
257 "/4plugins/test" is current directory.
PORT 74,79,84,76,230,212
200 PORT command successful.
LIST
150 Opening ASCII mode data connection for /bin/ls.
425 Cannot open data connection.
TCC: (Sys) The system cannot find the file specified.
"ftp:/4plugins/test/*"
  0 bytes in 0 files and 0 dirs
With the rule is enabled, TCC can use active FTP (period). I've posted many examples of it in this thread. It just seems buggy.
FTP.EXE, which is not even capable of passive FTP, has such a rule (resulting from a "Do you want to allow ..." prompt) the first time I used it. And FTP.EXE works. I have ALWAYS used active FTP.
Geez! Just try it!
 
To be more precise, with the firewall rule disabled, active FTP ...
Code: 
PORT 74,79,84,76,230,212 <---- TCC: "I'm listening on port 59092" (59092 = 230 * 256 + 212)
200 PORT command successful. <---- server: "Roger"
LIST <---- TCC: "Send me a directory listing"
150 Opening ASCII mode data connection for /bin/ls. <---- server: "OK, I'm trying"
425 Cannot open data connection. <---- server: "I can't connect to you on that port"
The firewall rule allows inbound traffic to the port on which TCC is listening.
 
rconn said:
Since there is no advantage to active FTP (and a lot of disadvantages), why are you so determined to use it?
Click to expand...
Because it has worked for me from twenty-some years ago right up to when it started to fail in TCC v16.

Why did you put active FTP in TCC?

Why are you so reluctant to test it? If it is broken, don't you want to know about it?

What disadvantages does it have other than the need for a firewall rule to allow it (which you have)?
 
Off-topic, but rather interesting.

You can use ControlPanel\InternetOptions to change IE's and Explorer's FTP to active (uncheck "Use passive FTP"). The first time you FTP with IE or Explorer, you're prompted to add a firewall rule to allow it.

(I didn't know this) If, in ControlPanel\InternetOptions, "Enable FTP folder view (outside of Internet Explorer)" is checked (I believe it's checked by default), you can
Code: 
v:\> explorer "ftp://lucky.syr.edu/4plugins/test"
or just type the URL in Explorer's location box.
upload_2014-6-12_15-10-54.png
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate