robinrodricks
FTPS Upload does not work on vsftpd 3.0.3
FTP OS: Embedded FTP Server: Vsftpd 3.0.3 Computer OS: Win 10 FluentFTP Version: 32.4.0
FTPS Connect works Download works Upload is does not work
Config: DataConnectionType = FtpDataConnectionType.PASV, EncryptionMode = FtpEncryptionMode.Explicit, SslProtocols = System.Security.Authentication.SslProtocols.Tls12, ValidateAnyCertificate = true,
If i do the same with FTP it works, but i need FTPS. With different FTP clients everything works on the same server.
Logs :
UploadAsync("/upload/get.txt", Overwrite, True)
FileExistsAsync("/upload/get.txt")
Command: SIZE /upload/get.txt
Response: 550 Could not get file size.
DirectoryExistsAsync("/upload")
GetWorkingDirectoryAsync()
Command: PWD
Response: 257 "/" is the current directory
Command: CWD /upload
Response: 250 Directory successfully changed.
Command: CWD /
Response: 250 Directory successfully changed.
OpenWriteAsync("/upload/get.txt", Binary)
OpenPassiveDataStreamAsync(EPSV, "STOR /upload/get.txt", 0)
Command: EPSV
Response: 229 Entering Extended Passive Mode (|||55548|)
Status: Connecting to 10.1.5.111:55548
Command: STOR /upload/get.txt
Response: 150 Ok to send data.
Status: FTPS Authentication Successful
Status: Time to activate encryption: 0h 0m 0s. Total Seconds: 0,052.
Status: Disposing FtpSocketStream...
Response: 426 Failure reading network stream.
Dispose()
Status: Disposing FtpClient object...
Command: QUIT
Response: 221 Goodbye.
Status: Disposing FtpSocketStream...
Status: Disposing FtpSocketStream...
Log from the Server if i try to upload "DATA connection terminated without SSL shutdown. Buggy client! Integrity of upload cannot be asserted."
@robinrodricks I know this has been closed, but I was encountering similar issues, and ended up having to do some sleuthing on this subject. I've outlined my findings below in case they're useful.
It looks like there was an old bug in the .NET implementation of the closing of an SslStream, which was addressed using the FtpSslStream.
However, in the CloseNotify method in SslDirectCall there's a check on sslStream.CanWrite. It looks like the Dispose() method of the FtpSocketStream, disposes of the m_netStream (at line 765) before it disposes of the m_sslStream field. This appears to set the CanWrite property to false meaning the close_notify is never sent in this case.
I'm not all that familiar with the area, but it looks to me like the close_notify needs to be sent prior to the disposal of the NetworkStream.
It's also worth noting that there appears to be a ShutdownAsync() method which handles the sending of the close_notify.
Edit - Sample vsftpd server log:
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FTP command: Client "::ffff:137.117.193.36", "EPSV"
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FTP response: Client "::ffff:137.117.193.36", "229 Entering Extended Passive Mode (|||10712|)"
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FTP command: Client "::ffff:137.117.193.36", "STOR /files/EDA25FC9EBD28459.tmp"
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FTP response: Client "::ffff:137.117.193.36", "150 Ok to send data."
Tue Jun 9 08:05:17 2020 [pid 111688] [ftpuser] DEBUG: Client "::ffff:137.117.193.36", "DATA connection terminated without SSL shutdown. Buggy client! Integrity of upload cannot be asserted."
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FTP response: Client "::ffff:137.117.193.36", "426 Failure reading network stream."
Tue Jun 9 08:05:17 2020 [pid 111689] [ftpuser] FAIL UPLOAD: Client "::ffff:137.117.193.36", "/files/EDA25FC9EBD28459.tmp", 88 bytes, 23.49Kbyte/sec
Tue Jun 9 08:05:28 2020 [pid 111688] [ftpuser] DEBUG: Client "::ffff:137.117.193.36", "Control connection terminated without SSL shutdown."
I am having the same issue using PASV mode for OpenPassiveDataStreamAsync. I can upload without errors using FileZilla.
I did a binary search on the versions and I found the place where upload was broken wrt. vsftpd and my program. It seems it started happening with version 32.0.0.
32.2.0 - Upload fails 32.1.0 - Upload fails 32.0.0 - Upload fails 31.3.2 - Upload succeeds 31.1.0 - Upload succeeds
UPDATE: Nevermind. It seems the difference probably is that 32.0.0 properly reports errors. With earlier versions the server still reports an error but the client does not raise any exceptions.
We have the same issue. Is there any update on solving this 'bug'. Or should we switch to an alternative server. Any recommendation for Debian ?
Same issue. id="FluentFTP" version="33.0.3" targetFramework="net451" Logs below:
> UploadFile("c:\somefile.dat", "somefile.dat", Overwrite, False, None)
> FileExists("somefile.dat")
> GetWorkingDirectory()
Command: PWD
Response: 257 "/xfer" is the current directory
Command: SIZE /xfer/somefile.dat
Response: 213 3590
> DeleteFile("somefile.dat")
Command: DELE somefile.dat
Response: 250 Delete operation successful.
> OpenWrite("somefile.dat", Binary)
Command: TYPE I
Response: 200 Switching to Binary mode.
> OpenPassiveDataStream(PASV, "STOR somefile.dat", 0)
Command: PASV
Response: 227 Entering Passive Mode (172,16,1,130,117,136).
Status: Connecting to *****/
Command: STOR somefile.dat
Response: 150 Ok to send data.
Status: FTPS Authentication Successful
Status: Time to activate encryption: 0h 0m 0s. Total Seconds: 0.2665214.
Status: Disposing FtpSocketStream...
Response: 426 Failure reading network stream.
Status: Failed to upload file.
The 3rd from last message is suspect. Why is the stream being Disposed?
I am having the same problem, but I think I can add some information. Files smaller than ≈16 kb work fine, but larger than 16kb gives 426 Failure reading network stream. On the server side, a zero size file is created. I have tried different values for TransferChunkSize and LocalFileBufferSize, I have tried setting strict_ssl_read_eof=NO on the server side like Sh4rpler suggested, but nothing works.
The interesting thing is that it works fine from my Mac, but not on Ubuntu. I have not yet tried on Windows, however.
I am moving the discussion here to #996 as we have many issues concerning incorrect SSL shutdown. Please follow this topic there.
