PASV mode possibly buggy in in build 988

Here's the situation:

1. I log into a site, succesfully
2. I transfer a file in PASV mode, succesfully
3. SmartFTP issues the next PASV command, SEEMINGLY succesful
4. SmartFTP issues the STOR command, and then waits for the timeout interval to pass and closes the connection.

This problem sub-sides temporarily if I hit the "STOP" button prior to the timeout, and re-initiate the transfer. (PASV is issued again, and the STOR starts transferring) Once that transfer completes, I have to hit stop again and restart the transfer such that the PASV command is issued again otherwise the connection will timeout.

(** See the log snippet below for sample problem. **)

This says to me that something is happening too quickly. (ports aren't available as quickly as SmartFTP thinks they are on the client and/or the server?)

A possible solution to this problem would be a COMMAND TIMEOUT interval which is shorter than the CONNECTION TIMEOUT interval such that a command can be retried X number of times before it is determined as "failed" and proceeds to the next item in the que or fails entirely.

This peticular solution would increase SmartFTP's connection reliability substantially for people who do alot of content transfers to and from quota based ftp sites which require connection persistance via the session que.


--------------------------------------------------
227 Entering Passive Mode (xxx,xxx,200,148,64,16).
Opening data connection to 24.26.200.148 Port: 16400
STOR xxx.xxx
150 Data connection accepted from xxx.xxx.40.177:58741; transfer starting for xxx.xxx
226-Using U/D Ratio 2/1. Current credit 6 MBytes, counting bytes per session.
5485842 bytes transferred. (73.6 KB/s) (00:01:12)
226 File received ok.
SIZE xxx2.xxx
213 5485842
Remote file exist check: 'xxx2.xxx'.
SIZE xxx2.xxx
550 No such file or directory.
PASV
227 Entering Passive Mode (xxx,xxx,200,148,199,172).
Opening data connection to xxx.xxx.200.148 Port: 51116
STOR xxx2.xxx
Timeout (120s).
Active Help: https://www.smartftp.com/support/kb/45
Client closed the connection.

Hi,

Do you use a firewall? Can you post a log with the "stop" button/re-initiate the transfer sequence please? Which version of SmartFTP do you use?

Olivier

SmartFTP v1.5.988.47

Please forgive me, I meant to post this in the bug reports section, not support.

This is on dedicated server w/o a firewall. (well, correct that, i firewall 135,137,139,445 TCP & UDP and other typical exploitable windows ports, but nothing in the dynamic range)

See the asterisks below for where I press stop, as the STOP is really not indicated in the session log by, say an, ABOR because the file transfer never starts.

--------------------------------------------------

Remote file exist check: 'xxx1.xxx'.
SIZE xxx1.xxx
550 No such file or directory.
PASV
227 Entering Passive Mode (xx,xx,200,148,38,254).
Opening data connection to xx.xx.200.148 Port: 9982
STOR xxx1.xxx
150 Data connection accepted from xx.xx.40.177:61989; transfer starting for xxx1.xxx
226-Using U/D Ratio 2/1. Current credit 1 MBytes, counting bytes per session.
2727311 bytes transferred. (73.9 KB/s) (00:00:36)
226 File received ok.
xxx1.xxx
213 2727311
Remote file exist check: 'xxx2.xxx'.
SIZE xxx2.xxx
550 No such file or directory.
PASV
227 Entering Passive Mode (xx,xx,200,148,218,155).
Opening data connection to xx.xx.200.148 Port: 55963
STOR xxx2.xxx

***** THIS IS WHERE I PRESS STOP *****

Remote file exist check: 'xxx2.xxx'.
SIZE xxx2.xxx
550 No such file or directory.
PASV
227 Entering Passive Mode (xxx,xxx,200,148,146,197).
Opening data connection to xx.xx.200.148 Port: 37573
STOR xxx2.xxx
150 Data connection accepted from xx.xx.40.177:62297; transfer starting for xxx2.xxx
226-Using U/D Ratio 2/1. Current credit 4 MBytes, counting bytes per session.
5253248 bytes transferred. (72.8 KB/s) (00:01:10)

Here's a CSV export of an Ethereal dump from a failed session. Below we can see the end of the last file transfer, verification of the last transfer, check for existing file on next transfer, and a failed PASV TCP connection.

I'm guessing that this may have something to do with SmartFTP jumping the gun a little bit on the STOR command as you can see below.

---------- Here's the packet capture with a play by play ----------

Here is the last packet of the last file transferring.

"2", "0.065151", "216.17.131.130", "xxx.xxx.xxx.xxx", "TCP", "2012 > 3389 [PSH, ACK] Seq=0 Ack=0 Win=64596 Len=66"
"3", "0.152805", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "TCP", "1849 > ftp [ACK] Seq=0 Ack=0 Win=65456 [TCP CHECKSUM INCORRECT] Len=0"


Server responds that it receives the file "OK".

"4", "0.229543", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "FTP", "Response: 226 File received ok."


SmartFTP asking to confirm this OK transfer by verifing the size.

"5", "0.234764", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "FTP", "Request: SIZE 07-filename.xxx"


Server responding with the verified size.

"7", "0.317585", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "FTP", "Response: 213 6040055"


SmartFTP checking to see if the next file exists.

"8", "0.326098", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "FTP", "Request: SIZE 08-filename.xxx.mp3"


Server confirms file does not exist.

"11", "0.408290", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "FTP", "Response: 550 No such file or directory."


SmartFTP asks for a PASV port to connect with.

"12", "0.412465", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "FTP", "Request: PASV"

Server gives SmartFTP PASV port 49088

"14", "0.490725", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "FTP", "Response: 227 Entering Passive Mode (xx,xx,200,148,191,192)."

(don't ask me how 191,192=49088)


SmartFTP attempts TCP connection connection to 49088
"15", "0.492915", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "TCP", "1853 > 49088 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460"


Hey, wait a minute, here SmartFTP is requesting the next FTP command on PORT 21 before we even get the ACK back for the DATA port connection... WTF?

"16", "0.493563", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "FTP", "Request: STOR 08-filename.xxx.mp3"

Oh, there's that stupid ACK for that SYN packet. Still seems a little outta order for my liking..

"19", "0.574870", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "TCP", "49088 > 1853 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460"


Something breaks here, not sure if the checksum really has anything to do with it, but none the less, we should be starting a transfer here, and it doesn't.

"20", "0.574892", "xxx.xxx.xxx.xxx", "xx.xx.200.148", "TCP", "1853 > 49088 [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0"

Server's ACK packet to SmartFTP's ftp STOR request.

"21", "0.732462", "xx.xx.200.148", "xxx.xxx.xxx.xxx", "TCP", "ftp > 1849 [ACK] Seq=120 Ack=132 Win=63850 Len=0"

This is starting to look like a crappy FTP daemon or a crappy ftp daemon configuration on the server side as it seems to die on other clients as well, please delete and/or lock this thread.