Re: FTPAPI connection reset

[Charles Wilt <charles.wilt@xxxxxxxxx>]

On Thu, Mar 1, 2012 at 6:36 PM, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
>
> In the network? Really?

That's my guess, since as you point out it doesn't make sense for the
FTP Server software to be doing it.

>
> Why would you cut off a single TCP session?

Why wouldn't you?  :)  If you assume whatever is doing it doesn't
realize it's a command channel for an active FTP connection...then all
they'd see is a inactive session.

>
> I'm not sure how you could send a NOOP while a transfer is active.
> Won't the server be busy receiving the file at that point, and not ready
> to receive commands (aside from ABOR)?  Even if it spawns a new thread
> to handle the data connection, it still has to be in a state that's
> waiting for the transfer to complete in order to send the 226/250.
>
> If you allowed it to send other commands while the transfer is active,
> what would happen when the 226/250 response finally came through?  You
> wouldn't know which of your commands it was in response to.

My assumption is that you'd have to send the NOOP, wait for the reply
to it before continuing the transfer.

So threading would be contra-indicated.

However, on the i and from the RFC, a NOOP returns a 200 - OK, not a
226/250.  So I suppose you could distinguish them.

>
> That's very different from this circumstance, because the error is
> occurring when reading the file transfer reply, not when waiting for a
> user or sending a new command after a long inactivity.
>
> Sure... if a 3rd party (not the FTP server or client, but something
> else) disconnected the channel, that would happen.
>
> But... why?  Why would they ever do that?  Why would it care which
> individual TCP sessions are active or inactive?  It's hard to find any
> motivation for that.  And, at any rate, I don't see how I can code
> around it in FTPAPI.

Paranoids in charge of the routers and firewalls?  :)

I'm not making it up, I promise:
http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html
http://serverfault.com/questions/84310/how-to-prevent-tcp-connection-timeout-when-ftping-large-file
http://stackoverflow.com/questions/2665788/indy-ftp-large-files-and-nat-routers
https://www.smartftp.com/forums/index.php?/topic/12058-stopping-noop-command/

that last one's the "inverse proof" :)

Ironically enough, when we started seeing the issue, I had a vague
recollection of hearing about it before. And I would have sworn that
you were the one I'd heard about it from!

Charles
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------