I didn't see the edit, replied from my email client. Implicit SSL connections are by default on port 990. What you're seeing above, to put it simply, is System.Net.FtpClient sending encrypted communication to the server which is expecting plain text so all it sees is gibberish.
↧
New Post: Passing password before TLS AUTH?
↧
New Post: Passing password before TLS AUTH?
Yep i get it, thanks for help ;]
↧
↧
New Post: Passing password before TLS AUTH?
Another day, another struggle. I'm connecting to FTPs using Explicit, all is ok on my pc, but when running on machine in another net im getting:
"System.IO.IOException: The handshake failed due to an unexpected packet format."
I found your post:
"System.IO.IOException: The handshake failed due to an unexpected packet format."
I found your post:
Is the server you're connecting to setup to accept only SSL connections on port 21? If not you need to be using Explicit.I', already using Explicit, when switching to Implicit I am not able to connect on my pc (not tested on second one yet). FTP server is: ProFTPD 1.3.3a Server
↧
New Post: Passing password before TLS AUTH?
I can't tell you what the right answer is because I have no idea what the configurations on the servers are. All I can tell you is use Explicit on port 21 and the AUTH command will be used or use Implicit on port 990. Don't set the port number in System.Net.FtpClient unless you are using a non-standard configuration, it will automatically pick the right port otherwise.
If you want a better answer than that you need to show code and details on how the servers are configured so I can try to do more than guess.
If you want a better answer than that you need to show code and details on how the servers are configured so I can try to do more than guess.
↧
New Post: Passing password before TLS AUTH?
I will not be able to get config of server ;[. What i can write is: my code of use your lib. Logs from connections on your lib [good, and bad] and using FileZilla [again good from one net, and bad from another] So here it is:
CODE:
public string ProcessUpload(string fileUrl, string fileName)
GoodOne
BadOne
LOGS FROM FileZilla:
GoodOne
I will add Bad soon.
CODE:
public string ProcessUpload(string fileUrl, string fileName)
{
string result = "";
using (System.Net.FtpClient.FtpClient client = new System.Net.FtpClient.FtpClient())
{
try
{
client.Host = ftpHost;
client.ValidateCertificate += new System.Net.FtpClient.FtpSslValidation(myCertificateValidation);
client.Credentials = new NetworkCredential(ftpUsername, ftpPassword);
client.EncryptionMode = System.Net.FtpClient.FtpEncryptionMode.Explicit;
client.Connect();
client.DataConnectionEncryption = true;
DoUpload(client, "/", fileName);
}
catch (Exception ex)
{
result += ex.ToString();
}
finally
{
client.Disconnect();
}
}
return result;
}
static void myCertificateValidation(System.Net.FtpClient.FtpClient control, System.Net.FtpClient.FtpSslValidationEventArgs e)
{
e.Accept = true;
}
GoodOne
BadOne
LOGS FROM FileZilla:
GoodOne
I will add Bad soon.
↧
↧
New Post: Passing password before TLS AUTH?
This:
220 ProFTPD 1.3.3a Server (Faceaddicted.pl FTP Welcome.) [::ffff:192.168.0.2]
AUTH TLS
234 AUTH TLS successful
-- HERE --> Testing connectivity using Socket.Poll()...
-- HERE --> Read stale data off the socket, maybe our connection timed out.
-- HERE --> Testing connectivity using Socket.Poll()...↧
New Post: Passing password before TLS AUTH?
↧
Reviewed: System.Net.FtpClient 13.4.25.0 (may 09, 2013)
Rated 5 Stars (out of 5) - Great library and well documented!
Making a connection to an FTP server is usually a bit slower than using other ftp clients, but is very easy to use and supports nearly all commands you will need when working with FTPs
Recommended
↧
Source code checked in, #b8b1f11aac4df7edb5b6b08f6ec091f42f84a28d
Added debug output for the total time it takes to negotiate encryption with the server.
↧
↧
Updated Wiki: Documentation
API Overview
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
- You use X509Certificate2 objects, not the incomplete X509Certificate implementation.
- You do not use pem certificates, use p12 instead. See this Stack Overflow thread for more information. If you get SPPI exceptions with an inner exception about an unexpected or badly formatted message, you are probably using the wrong type of certificate.
- Slow SSL Negotiation *
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
- UNIX style file listings are NOT reliable. Most FTP servers respond to LIST with a format that strongly resembles the output of ls -l on UNIX and UNIX-like operating systems. This format is difficult to parse and has shortcomings with date/time values in which assumptions have to made in order to try to guess an as accurate as possible value. System.Net.FtpClient provides a LIST parser but there is no guarantee that it will work right 100% of the time. You can add your own parser if it doesn't. See the examples project in the source code.
- System.Net.FtpClient prefers machine listings (MLST/MLSD) which are an extension added to the protocol. This format is reliable and is always used over LIST when the server advertises it in its FEATure list unless you override the behavior with FtpListOption flags. With machine listings you can expect a correct file size and modification date (UTC). If you run across a case that you are not it's very possible it's due to a bug in the machine listing parser and you should report the issue along with a sample of the file listing (see the debugging example in the source).
- Name Listings (NLST) are the next best thing when machine listings are not available however they are MUCH slower than either LIST or MLSD. This is because NLST sends a list of objects in the directory and the server has to be queried for the rest of the information on file-by-file basis, such as the file size, the modification time and an attempt to determine if the object is a file or directory. Name listings can be forced using FtpListOption flags. The best way to handle falling back to NLST is to query the server features (FtpClient.Capabilities) for the FtpCapability.MLSD flag. If it's not there, then pass the necessary flags to GetListing() to force a name listing.
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
try {
// ftpClient.SomeMethod();
}
catch(IOException e) {
if(e.InnertException is SocketException) {
// the control connection was interrupted
}
}
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
- Bulk Downloads Important information about mirroring / recursion!!
↧
Updated Wiki: Documentation
API Overview
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
Slow SSL Negotiation
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
- You use X509Certificate2 objects, not the incomplete X509Certificate implementation.
- You do not use pem certificates, use p12 instead. See this Stack Overflow thread for more information. If you get SPPI exceptions with an inner exception about an unexpected or badly formatted message, you are probably using the wrong type of certificate.
Slow SSL Negotiation
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
- UNIX style file listings are NOT reliable. Most FTP servers respond to LIST with a format that strongly resembles the output of ls -l on UNIX and UNIX-like operating systems. This format is difficult to parse and has shortcomings with date/time values in which assumptions have to made in order to try to guess an as accurate as possible value. System.Net.FtpClient provides a LIST parser but there is no guarantee that it will work right 100% of the time. You can add your own parser if it doesn't. See the examples project in the source code.
- System.Net.FtpClient prefers machine listings (MLST/MLSD) which are an extension added to the protocol. This format is reliable and is always used over LIST when the server advertises it in its FEATure list unless you override the behavior with FtpListOption flags. With machine listings you can expect a correct file size and modification date (UTC). If you run across a case that you are not it's very possible it's due to a bug in the machine listing parser and you should report the issue along with a sample of the file listing (see the debugging example in the source).
- Name Listings (NLST) are the next best thing when machine listings are not available however they are MUCH slower than either LIST or MLSD. This is because NLST sends a list of objects in the directory and the server has to be queried for the rest of the information on file-by-file basis, such as the file size, the modification time and an attempt to determine if the object is a file or directory. Name listings can be forced using FtpListOption flags. The best way to handle falling back to NLST is to query the server features (FtpClient.Capabilities) for the FtpCapability.MLSD flag. If it's not there, then pass the necessary flags to GetListing() to force a name listing.
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
try {
// ftpClient.SomeMethod();
}
catch(IOException e) {
if(e.InnertException is SocketException) {
// the control connection was interrupted
}
}
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
- Bulk Downloads Important information about mirroring / recursion!!
↧
Released: System.Net.FtpClient 13.5.9.0 (May 09, 2013)
System.Net.FtpClient is now available via
nuget.
This is the first release of the new code base. It is not compatible with the old API, I repeat it is not a drop in update for projects currently using System.Net.FtpClient. New users should download this release. The old code base (Branch: System.Net.FtpClient_1) will continue to be supported while the new code matures.
This release is a complete re-write of System.Net.FtpClient. The API and code are simpler than ever before. There are some new features included as well as an attempt at better thread safety. Multiple transfers from a single FtpClient object are now supported and async methods are available for nearly every method in FtpClient.
Support for the FtpFile and FtpDirectory classes have been dropped in favor of the simpler FtpListItem objects. There are no plans to re-introduce these classes in the future.
Support for the Upload(), Download() and Append() methods has been dropped and there are no plans to re-introduce them. There are however plenty of examples using the OpenRead(), OpenWrite() and OpenAppend() methods.
The new CHM API reference includes examples for nearly every method in FtpClient including information about debugging and adding custom file listing parsers.
-- Updates 2012.10.02.01 --
Binary updated to latest revision, contains several bug fixes for IPv6 and full IPv6 support for control and data connections. Slight API change, EnableIPv6 property removed. If you connect to a IPv6 address everything is handled transparently behind the scenes. If you don't want use IPv6 consider doing DNS resolution yourself and only connecting to IPv4 addresses.
-- Updates 2012.10.02.02 --
1. Fixed problem with GlobalScape's secure FTP server and data connection SSL authentication.
2. Fixed problem with improper sequencing of PBSZ and PROT commands in regards to requirements outlined by RFC 2228
-- Updates 12.12.13.0 --
1. Fixed bugs with thread safe data channels, see commit notes.
2. Fixed bug in SSL validation behavior, you no longer are required to set the Accept property of the event args to True when the SSL certificate is valid.
3. SSL Bug fix in active mode transfers
4. Added support for client ssl certificates though this feature has not been tested or confirmed to be working. That doesn't mean it doesn't work, I just don't have a way to confirm that it indeed does and the person who requested it hasn't confirmed that it works for them.
-- Updates 13.01.25.0 --
1. Added support for NLST using the FtpListOptions.NameList flag. This approach to file listings is the slowest of the bunch however with the proper features on the server side it is the most accurate way to get a file listing with modification times and file size.
2. Fixed bug in MLSD parser where items would fail because the line didn't begin with ^type=
3. Added check to GetListing() when using LIST where if the modification date is in the future and the MDTM command is supported the server is queried again for the correct modification time. This is feature exists because unix style long listings omit the year in certain situations which can potentially cause a modification time to be off by a year.
4. Added support for parsing VAX/OpenVMS style directory listings. VAX/OpenVMS style paths are not supported however this limitation can be overcome by manually changing to the appropriate directories on the server instead of passing full paths to FtpClient method calls.
5. Fixed bug in CreateDirectory() where 2 attempts to create a directory were made because the path ended with a slash.
This code should be stable for most if not all people so I've changed the download status accordingly. As usual, if you find any bugs please report them or share your fixes. We may not be prompt in getting back to you 100% of the time but we indeed try to address problems in a timely manner.
-- Updates 13.4.25.0 --
Lots of changes... here's a copy and paste from the commit comments:
1. Added IFtpClient, IFtpListItem and IFtpReply interfaces to assist with MoQ unit testing. No testing has been done.
2. Fixed bug with restart (REST) sequencing in OpenRead()
3. More precise server feature matching to avoid false positives.
4. Bug fix in IIS listing date/time parser.
5. Reduced socket poll connection test to 500 miliseconds.
6. MLSD, MDTM and LIST with DOS format (IIS) dates are assumed to be UTC. UNIX and VAX LIST listings are assumed to be local. The basis for this change is that LIST on filezilla gives local date/time values however MDTM and MLSD on filezilla give UTC date/time values. This might become an adjustable property of FtpClient in the future since all servers won't behave the same in regards to timezones.
7. Changed date/time parsing code to assume UTC date/time values are being returned from the server. Made modification to Connect() method in effort to detect when there is a disruption immediately upon the initial connection, i.e., before the server greeting can be read. An IOException is thrown when this happens instead of an empty FtpCommandException (what previously happened).
8. Added code to FtpClient.Execute to detect stale data on the socket, generally due to a timeout + disconnection by the server. The server will sometimes send a disconnection notice that might be sitting in the buffer which breaks the Poll() connectivity test so the data is read and discarded. This still doesn't guarantee a graceful reconnection, you need to catch IOException's when you make calls to FtpClient's method and look for the InnerException to be a SocketException, i.e.,
try { conn.DoSomething() } catch(IOException e) { if(e.InnerException is SocketException) { // reconnect, DoSomething() again } }
9. Fixed bug in socket polling code that was used to test for connectivity. Added new SocketPollInterval property (default 15 seconds) that is used to determine how much time should pass since the last read/write before the socket is Poll()'d for connectivity. Polling is used in conjunction with Socket.Connected because Socket.Connected still returns true even when the remote host has closed the connection.
10. Slight refactoring of FtpSocketStream Connect() method to remove un-necessary exception handling. Added new SocketKeepAlive property that sets SocketOption.KeepAlive accordingly on the underlying stream sockets.
11. Added support for distribution of System.Net.FtpClient through nuget: https://nuget.org/packages/System.Net.FtpClient/
-- Updates 13.5.9.0 --
*Added debug output for the total time it takes to negotiate encryption with the server.
*Bug fix with FtpDataConnectionType.AutoActive where the control connection would be closed after the failed EPRT causing a null reference exception while trying to fall back to PORT.
*Added check to avoid null reference exception after failed EPSV command.
*Added check in OpenActiveDataStream to avoid null reference exception after failed EPRT command.
This is the first release of the new code base. It is not compatible with the old API, I repeat it is not a drop in update for projects currently using System.Net.FtpClient. New users should download this release. The old code base (Branch: System.Net.FtpClient_1) will continue to be supported while the new code matures.
This release is a complete re-write of System.Net.FtpClient. The API and code are simpler than ever before. There are some new features included as well as an attempt at better thread safety. Multiple transfers from a single FtpClient object are now supported and async methods are available for nearly every method in FtpClient.
Support for the FtpFile and FtpDirectory classes have been dropped in favor of the simpler FtpListItem objects. There are no plans to re-introduce these classes in the future.
Support for the Upload(), Download() and Append() methods has been dropped and there are no plans to re-introduce them. There are however plenty of examples using the OpenRead(), OpenWrite() and OpenAppend() methods.
The new CHM API reference includes examples for nearly every method in FtpClient including information about debugging and adding custom file listing parsers.
-- Updates 2012.10.02.01 --
Binary updated to latest revision, contains several bug fixes for IPv6 and full IPv6 support for control and data connections. Slight API change, EnableIPv6 property removed. If you connect to a IPv6 address everything is handled transparently behind the scenes. If you don't want use IPv6 consider doing DNS resolution yourself and only connecting to IPv4 addresses.
-- Updates 2012.10.02.02 --
1. Fixed problem with GlobalScape's secure FTP server and data connection SSL authentication.
2. Fixed problem with improper sequencing of PBSZ and PROT commands in regards to requirements outlined by RFC 2228
-- Updates 12.12.13.0 --
1. Fixed bugs with thread safe data channels, see commit notes.
2. Fixed bug in SSL validation behavior, you no longer are required to set the Accept property of the event args to True when the SSL certificate is valid.
3. SSL Bug fix in active mode transfers
4. Added support for client ssl certificates though this feature has not been tested or confirmed to be working. That doesn't mean it doesn't work, I just don't have a way to confirm that it indeed does and the person who requested it hasn't confirmed that it works for them.
-- Updates 13.01.25.0 --
1. Added support for NLST using the FtpListOptions.NameList flag. This approach to file listings is the slowest of the bunch however with the proper features on the server side it is the most accurate way to get a file listing with modification times and file size.
2. Fixed bug in MLSD parser where items would fail because the line didn't begin with ^type=
3. Added check to GetListing() when using LIST where if the modification date is in the future and the MDTM command is supported the server is queried again for the correct modification time. This is feature exists because unix style long listings omit the year in certain situations which can potentially cause a modification time to be off by a year.
4. Added support for parsing VAX/OpenVMS style directory listings. VAX/OpenVMS style paths are not supported however this limitation can be overcome by manually changing to the appropriate directories on the server instead of passing full paths to FtpClient method calls.
5. Fixed bug in CreateDirectory() where 2 attempts to create a directory were made because the path ended with a slash.
This code should be stable for most if not all people so I've changed the download status accordingly. As usual, if you find any bugs please report them or share your fixes. We may not be prompt in getting back to you 100% of the time but we indeed try to address problems in a timely manner.
-- Updates 13.4.25.0 --
Lots of changes... here's a copy and paste from the commit comments:
1. Added IFtpClient, IFtpListItem and IFtpReply interfaces to assist with MoQ unit testing. No testing has been done.
2. Fixed bug with restart (REST) sequencing in OpenRead()
3. More precise server feature matching to avoid false positives.
4. Bug fix in IIS listing date/time parser.
5. Reduced socket poll connection test to 500 miliseconds.
6. MLSD, MDTM and LIST with DOS format (IIS) dates are assumed to be UTC. UNIX and VAX LIST listings are assumed to be local. The basis for this change is that LIST on filezilla gives local date/time values however MDTM and MLSD on filezilla give UTC date/time values. This might become an adjustable property of FtpClient in the future since all servers won't behave the same in regards to timezones.
7. Changed date/time parsing code to assume UTC date/time values are being returned from the server. Made modification to Connect() method in effort to detect when there is a disruption immediately upon the initial connection, i.e., before the server greeting can be read. An IOException is thrown when this happens instead of an empty FtpCommandException (what previously happened).
8. Added code to FtpClient.Execute to detect stale data on the socket, generally due to a timeout + disconnection by the server. The server will sometimes send a disconnection notice that might be sitting in the buffer which breaks the Poll() connectivity test so the data is read and discarded. This still doesn't guarantee a graceful reconnection, you need to catch IOException's when you make calls to FtpClient's method and look for the InnerException to be a SocketException, i.e.,
try { conn.DoSomething() } catch(IOException e) { if(e.InnerException is SocketException) { // reconnect, DoSomething() again } }
9. Fixed bug in socket polling code that was used to test for connectivity. Added new SocketPollInterval property (default 15 seconds) that is used to determine how much time should pass since the last read/write before the socket is Poll()'d for connectivity. Polling is used in conjunction with Socket.Connected because Socket.Connected still returns true even when the remote host has closed the connection.
10. Slight refactoring of FtpSocketStream Connect() method to remove un-necessary exception handling. Added new SocketKeepAlive property that sets SocketOption.KeepAlive accordingly on the underlying stream sockets.
11. Added support for distribution of System.Net.FtpClient through nuget: https://nuget.org/packages/System.Net.FtpClient/
-- Updates 13.5.9.0 --
*Added debug output for the total time it takes to negotiate encryption with the server.
*Bug fix with FtpDataConnectionType.AutoActive where the control connection would be closed after the failed EPRT causing a null reference exception while trying to fall back to PORT.
*Added check to avoid null reference exception after failed EPSV command.
*Added check in OpenActiveDataStream to avoid null reference exception after failed EPRT command.
↧
Updated Release: System.Net.FtpClient 13.5.9.0 (May 09, 2013)
System.Net.FtpClient is now available via nuget.
This is the first release of the new code base. It is not compatible with the old API, I repeat it is not a drop in update for projects currently using System.Net.FtpClient. New users should download this release. The old code base (Branch: System.Net.FtpClient_1) will continue to be supported while the new code matures.
This release is a complete re-write of System.Net.FtpClient. The API and code are simpler than ever before. There are some new features included as well as an attempt at better thread safety. Multiple transfers from a single FtpClient object are now supported and async methods are available for nearly every method in FtpClient.
Support for the FtpFile and FtpDirectory classes have been dropped in favor of the simpler FtpListItem objects. There are no plans to re-introduce these classes in the future.
Support for the Upload(), Download() and Append() methods has been dropped and there are no plans to re-introduce them. There are however plenty of examples using the OpenRead(), OpenWrite() and OpenAppend() methods.
The new CHM API reference includes examples for nearly every method in FtpClient including information about debugging and adding custom file listing parsers.
-- Updates 2012.10.02.01 --
Binary updated to latest revision, contains several bug fixes for IPv6 and full IPv6 support for control and data connections. Slight API change, EnableIPv6 property removed. If you connect to a IPv6 address everything is handled transparently behind the scenes. If you don't want use IPv6 consider doing DNS resolution yourself and only connecting to IPv4 addresses.
-- Updates 2012.10.02.02 --
1. Fixed problem with GlobalScape's secure FTP server and data connection SSL authentication.
2. Fixed problem with improper sequencing of PBSZ and PROT commands in regards to requirements outlined by RFC 2228
-- Updates 12.12.13.0 --
1. Fixed bugs with thread safe data channels, see commit notes.
2. Fixed bug in SSL validation behavior, you no longer are required to set the Accept property of the event args to True when the SSL certificate is valid.
3. SSL Bug fix in active mode transfers
4. Added support for client ssl certificates though this feature has not been tested or confirmed to be working. That doesn't mean it doesn't work, I just don't have a way to confirm that it indeed does and the person who requested it hasn't confirmed that it works for them.
-- Updates 13.01.25.0 --
1. Added support for NLST using the FtpListOptions.NameList flag. This approach to file listings is the slowest of the bunch however with the proper features on the server side it is the most accurate way to get a file listing with modification times and file size.
2. Fixed bug in MLSD parser where items would fail because the line didn't begin with ^type=
3. Added check to GetListing() when using LIST where if the modification date is in the future and the MDTM command is supported the server is queried again for the correct modification time. This is feature exists because unix style long listings omit the year in certain situations which can potentially cause a modification time to be off by a year.
4. Added support for parsing VAX/OpenVMS style directory listings. VAX/OpenVMS style paths are not supported however this limitation can be overcome by manually changing to the appropriate directories on the server instead of passing full paths to FtpClient method calls.
5. Fixed bug in CreateDirectory() where 2 attempts to create a directory were made because the path ended with a slash.
This code should be stable for most if not all people so I've changed the download status accordingly. As usual, if you find any bugs please report them or share your fixes. We may not be prompt in getting back to you 100% of the time but we indeed try to address problems in a timely manner.
-- Updates 13.4.25.0 --
Lots of changes... here's a copy and paste from the commit comments:
1. Added IFtpClient, IFtpListItem and IFtpReply interfaces to assist with MoQ unit testing. No testing has been done.
2. Fixed bug with restart (REST) sequencing in OpenRead()
3. More precise server feature matching to avoid false positives.
4. Bug fix in IIS listing date/time parser.
5. Reduced socket poll connection test to 500 miliseconds.
6. MLSD, MDTM and LIST with DOS format (IIS) dates are assumed to be UTC. UNIX and VAX LIST listings are assumed to be local. The basis for this change is that LIST on filezilla gives local date/time values however MDTM and MLSD on filezilla give UTC date/time values. This might become an adjustable property of FtpClient in the future since all servers won't behave the same in regards to timezones.
7. Changed date/time parsing code to assume UTC date/time values are being returned from the server. Made modification to Connect() method in effort to detect when there is a disruption immediately upon the initial connection, i.e., before the server greeting can be read. An IOException is thrown when this happens instead of an empty FtpCommandException (what previously happened).
8. Added code to FtpClient.Execute to detect stale data on the socket, generally due to a timeout + disconnection by the server. The server will sometimes send a disconnection notice that might be sitting in the buffer which breaks the Poll() connectivity test so the data is read and discarded. This still doesn't guarantee a graceful reconnection, you need to catch IOException's when you make calls to FtpClient's method and look for the InnerException to be a SocketException, i.e.,
try { conn.DoSomething() } catch(IOException e) { if(e.InnerException is SocketException) { // reconnect, DoSomething() again } }
9. Fixed bug in socket polling code that was used to test for connectivity. Added new SocketPollInterval property (default 15 seconds) that is used to determine how much time should pass since the last read/write before the socket is Poll()'d for connectivity. Polling is used in conjunction with Socket.Connected because Socket.Connected still returns true even when the remote host has closed the connection.
10. Slight refactoring of FtpSocketStream Connect() method to remove un-necessary exception handling. Added new SocketKeepAlive property that sets SocketOption.KeepAlive accordingly on the underlying stream sockets.
11. Added support for distribution of System.Net.FtpClient through nuget: https://nuget.org/packages/System.Net.FtpClient/
-- Updates 13.5.9.0 --
*Added debug output for the total time it takes to negotiate encryption with the server.
*Bug fix with FtpDataConnectionType.AutoActive where the control connection would be closed after the failed EPRT causing a null reference exception while trying to fall back to PORT.
*Added check to avoid null reference exception after failed EPSV command.
*Added check in OpenActiveDataStream to avoid null reference exception after failed EPRT command.
This is the first release of the new code base. It is not compatible with the old API, I repeat it is not a drop in update for projects currently using System.Net.FtpClient. New users should download this release. The old code base (Branch: System.Net.FtpClient_1) will continue to be supported while the new code matures.
This release is a complete re-write of System.Net.FtpClient. The API and code are simpler than ever before. There are some new features included as well as an attempt at better thread safety. Multiple transfers from a single FtpClient object are now supported and async methods are available for nearly every method in FtpClient.
Support for the FtpFile and FtpDirectory classes have been dropped in favor of the simpler FtpListItem objects. There are no plans to re-introduce these classes in the future.
Support for the Upload(), Download() and Append() methods has been dropped and there are no plans to re-introduce them. There are however plenty of examples using the OpenRead(), OpenWrite() and OpenAppend() methods.
The new CHM API reference includes examples for nearly every method in FtpClient including information about debugging and adding custom file listing parsers.
-- Updates 2012.10.02.01 --
Binary updated to latest revision, contains several bug fixes for IPv6 and full IPv6 support for control and data connections. Slight API change, EnableIPv6 property removed. If you connect to a IPv6 address everything is handled transparently behind the scenes. If you don't want use IPv6 consider doing DNS resolution yourself and only connecting to IPv4 addresses.
-- Updates 2012.10.02.02 --
1. Fixed problem with GlobalScape's secure FTP server and data connection SSL authentication.
2. Fixed problem with improper sequencing of PBSZ and PROT commands in regards to requirements outlined by RFC 2228
-- Updates 12.12.13.0 --
1. Fixed bugs with thread safe data channels, see commit notes.
2. Fixed bug in SSL validation behavior, you no longer are required to set the Accept property of the event args to True when the SSL certificate is valid.
3. SSL Bug fix in active mode transfers
4. Added support for client ssl certificates though this feature has not been tested or confirmed to be working. That doesn't mean it doesn't work, I just don't have a way to confirm that it indeed does and the person who requested it hasn't confirmed that it works for them.
-- Updates 13.01.25.0 --
1. Added support for NLST using the FtpListOptions.NameList flag. This approach to file listings is the slowest of the bunch however with the proper features on the server side it is the most accurate way to get a file listing with modification times and file size.
2. Fixed bug in MLSD parser where items would fail because the line didn't begin with ^type=
3. Added check to GetListing() when using LIST where if the modification date is in the future and the MDTM command is supported the server is queried again for the correct modification time. This is feature exists because unix style long listings omit the year in certain situations which can potentially cause a modification time to be off by a year.
4. Added support for parsing VAX/OpenVMS style directory listings. VAX/OpenVMS style paths are not supported however this limitation can be overcome by manually changing to the appropriate directories on the server instead of passing full paths to FtpClient method calls.
5. Fixed bug in CreateDirectory() where 2 attempts to create a directory were made because the path ended with a slash.
This code should be stable for most if not all people so I've changed the download status accordingly. As usual, if you find any bugs please report them or share your fixes. We may not be prompt in getting back to you 100% of the time but we indeed try to address problems in a timely manner.
-- Updates 13.4.25.0 --
Lots of changes... here's a copy and paste from the commit comments:
1. Added IFtpClient, IFtpListItem and IFtpReply interfaces to assist with MoQ unit testing. No testing has been done.
2. Fixed bug with restart (REST) sequencing in OpenRead()
3. More precise server feature matching to avoid false positives.
4. Bug fix in IIS listing date/time parser.
5. Reduced socket poll connection test to 500 miliseconds.
6. MLSD, MDTM and LIST with DOS format (IIS) dates are assumed to be UTC. UNIX and VAX LIST listings are assumed to be local. The basis for this change is that LIST on filezilla gives local date/time values however MDTM and MLSD on filezilla give UTC date/time values. This might become an adjustable property of FtpClient in the future since all servers won't behave the same in regards to timezones.
7. Changed date/time parsing code to assume UTC date/time values are being returned from the server. Made modification to Connect() method in effort to detect when there is a disruption immediately upon the initial connection, i.e., before the server greeting can be read. An IOException is thrown when this happens instead of an empty FtpCommandException (what previously happened).
8. Added code to FtpClient.Execute to detect stale data on the socket, generally due to a timeout + disconnection by the server. The server will sometimes send a disconnection notice that might be sitting in the buffer which breaks the Poll() connectivity test so the data is read and discarded. This still doesn't guarantee a graceful reconnection, you need to catch IOException's when you make calls to FtpClient's method and look for the InnerException to be a SocketException, i.e.,
try { conn.DoSomething() } catch(IOException e) { if(e.InnerException is SocketException) { // reconnect, DoSomething() again } }
9. Fixed bug in socket polling code that was used to test for connectivity. Added new SocketPollInterval property (default 15 seconds) that is used to determine how much time should pass since the last read/write before the socket is Poll()'d for connectivity. Polling is used in conjunction with Socket.Connected because Socket.Connected still returns true even when the remote host has closed the connection.
10. Slight refactoring of FtpSocketStream Connect() method to remove un-necessary exception handling. Added new SocketKeepAlive property that sets SocketOption.KeepAlive accordingly on the underlying stream sockets.
11. Added support for distribution of System.Net.FtpClient through nuget: https://nuget.org/packages/System.Net.FtpClient/
-- Updates 13.5.9.0 --
*Added debug output for the total time it takes to negotiate encryption with the server.
*Bug fix with FtpDataConnectionType.AutoActive where the control connection would be closed after the failed EPRT causing a null reference exception while trying to fall back to PORT.
*Added check to avoid null reference exception after failed EPSV command.
*Added check in OpenActiveDataStream to avoid null reference exception after failed EPRT command.
↧
↧
Source code checked in, #3722b75b3598f6016bf7c9e640c422c412e3d436
Added new System.Net.FtpClient.FtpTrace static class to make transaction logging possible in the release or debug builds. FtpTrace writes to System.Diagnostics.Debug when DEBUG is defined so things are backwards compatible. In the future or in release builds, you can add your TraceListener derived objects using System.Net.FtpClient.FtpTrace.Add(TraceListener t).
↧
Source code checked in, #cff4904a3bc7ab352f0cff17ea32ad724a26a009
Updated debug example and documentation to reflect the new FtpTrace class.
↧
Updated Wiki: Home
Project Description
System.Net.FtpClient is a client implementation of the FTP protocol that is designed to be easy to use and easy to extend. Aside from normal FTP client features, it supports SSL/TLS connections for command and data channels and parsing various file listing formats. This project is being developed with C#.
Information
For those interested, System.Net.FtpClient is now available via nuget. The nuget package contains a release build of the library, the associated source code, the examples project, and the compiled help API reference. This package will be updated and pushed up to nuget.org with every future release.
The documentation page contains some important information/gotchas that you should be aware of. If you haven't already, please take a look at what's there. It might save us all some time and trouble down the road.
Bugs
In order to get help and in turn help others by getting bugs fixed please use the discussions section where we can talk and try to get to the bottom of any problems. If you're fairly certain you've found a bug in the System.Net.FtpClient code then make a detailed bug report in the Issue Tracker. It's worth taking a look over the Source Code section and reading the commit comments to see if a particular bug has already been addressed in a newer revision than what you might be using. Please do not use the release reviews to post about errors. If you want to leave a bad review then that is your prerogative but if you want to report an error do so through the proper channels so that we can discuss the problem in a public manner that helps everyone.
When you encounter a bug there are a few important things that you can include that will go a long way in helping to resolve the matter. Aside from a good description of how to reproduce the problem, include with your report the transaction log, the exact revision number, and the exact version of the server OS and ftp software tat you were connected to when the problem occurred. I realize that some of this information may not be available but if it is please be sure to include it.
Refer to Examples\Debug.cs for information on how to easily log the server transactions. The information provided is very valuable when tracking down the source of problems.
If you are having trouble opening the CHM, right click on it, select properties and choose "Un-block" from the General Tab. If you don't trust us and don't want to unblock the file then download the source code and dig through the Examples project which includes all of the examples used in the CHM.
System.Net.FtpClient is a client implementation of the FTP protocol that is designed to be easy to use and easy to extend. Aside from normal FTP client features, it supports SSL/TLS connections for command and data channels and parsing various file listing formats. This project is being developed with C#.
Information
For those interested, System.Net.FtpClient is now available via nuget. The nuget package contains a release build of the library, the associated source code, the examples project, and the compiled help API reference. This package will be updated and pushed up to nuget.org with every future release.
The documentation page contains some important information/gotchas that you should be aware of. If you haven't already, please take a look at what's there. It might save us all some time and trouble down the road.
Bugs
In order to get help and in turn help others by getting bugs fixed please use the discussions section where we can talk and try to get to the bottom of any problems. If you're fairly certain you've found a bug in the System.Net.FtpClient code then make a detailed bug report in the Issue Tracker. It's worth taking a look over the Source Code section and reading the commit comments to see if a particular bug has already been addressed in a newer revision than what you might be using. Please do not use the release reviews to post about errors. If you want to leave a bad review then that is your prerogative but if you want to report an error do so through the proper channels so that we can discuss the problem in a public manner that helps everyone.
When you encounter a bug there are a few important things that you can include that will go a long way in helping to resolve the matter. Aside from a good description of how to reproduce the problem, include with your report the transaction log, the exact revision number, and the exact version of the server OS and ftp software tat you were connected to when the problem occurred. I realize that some of this information may not be available but if it is please be sure to include it.
Refer to Examples\Debug.cs for information on how to easily log the server transactions. The information provided is very valuable when tracking down the source of problems.
If you are having trouble opening the CHM, right click on it, select properties and choose "Un-block" from the General Tab. If you don't trust us and don't want to unblock the file then download the source code and dig through the Examples project which includes all of the examples used in the CHM.
↧
Updated Wiki: Documentation
API Overview
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
Slow SSL Negotiation
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
The latest builds of System.Net.FtpClient log the time it takes to authenticate. If you think you are suffering from this problem then have a look at Examples\Debug.cs for information on retrieving debug information.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
The download includes a CHM API reference with examples for nearly all methods in FtpClient as well as information about debugging and adding custom file listing parsers. The source code contains an Examples project as well. Please refer to the CHM for help and if you have further questions post to the Discussions section of this site.
Client Certificates
When you are using Client Certificates, be sure that:
- You use X509Certificate2 objects, not the incomplete X509Certificate implementation.
- You do not use pem certificates, use p12 instead. See this Stack Overflow thread for more information. If you get SPPI exceptions with an inner exception about an unexpected or badly formatted message, you are probably using the wrong type of certificate.
Slow SSL Negotiation
System.Net.FtpClient uses SslStream under the hood which is part of the .net framework. SslStream uses a feature of windows for updating root CA's on the fly, at least that's the way I understand it. These updates can cause a long delay in the certificate authentication process which can cause issues in System.Net.FtpClient related to the SocketPollInterval property used for checking for ungraceful disconnections between the client and server. This MSDN Blog covers the issue with SslStream and talks about how to disable the auto-updating of the root CA's.
The latest builds of System.Net.FtpClient log the time it takes to authenticate. If you think you are suffering from this problem then have a look at Examples\Debug.cs for information on retrieving debug information.
File Listings
Some of you may already be aware that RFC959 does not specify any particular format for file listings (LIST). As time has passed extensions have been added to address this problem. Here's what you need to know about the situation:
- UNIX style file listings are NOT reliable. Most FTP servers respond to LIST with a format that strongly resembles the output of ls -l on UNIX and UNIX-like operating systems. This format is difficult to parse and has shortcomings with date/time values in which assumptions have to made in order to try to guess an as accurate as possible value. System.Net.FtpClient provides a LIST parser but there is no guarantee that it will work right 100% of the time. You can add your own parser if it doesn't. See the examples project in the source code.
- System.Net.FtpClient prefers machine listings (MLST/MLSD) which are an extension added to the protocol. This format is reliable and is always used over LIST when the server advertises it in its FEATure list unless you override the behavior with FtpListOption flags. With machine listings you can expect a correct file size and modification date (UTC). If you run across a case that you are not it's very possible it's due to a bug in the machine listing parser and you should report the issue along with a sample of the file listing (see the debugging example in the source).
- Name Listings (NLST) are the next best thing when machine listings are not available however they are MUCH slower than either LIST or MLSD. This is because NLST sends a list of objects in the directory and the server has to be queried for the rest of the information on file-by-file basis, such as the file size, the modification time and an attempt to determine if the object is a file or directory. Name listings can be forced using FtpListOption flags. The best way to handle falling back to NLST is to query the server features (FtpClient.Capabilities) for the FtpCapability.MLSD flag. If it's not there, then pass the necessary flags to GetListing() to force a name listing.
Handling Ungraceful Interruptions in the Control Connection
System.Net.FtpClient uses Socket.Poll() to test for connectivity after a user-definable period of time has passed since the last activity on the control connection. When the remote host closes the connection there is no way to know, without triggering an exception, other than using Poll() to make an educated guess. When the connectivity test fails the connection is automatically re-established. This process helps a great deal in gracefully reconnecting however it does not eliminate your responsibility for catching IOExceptions related to an ungraceful interruption in the connection. Usually, maybe always, when this occurs the InnerException will be a SocketException. How you want to handle the situation from there is up to you.
try {
// ftpClient.SomeMethod();
}
catch(IOException e) {
if(e.InnertException is SocketException) {
// the control connection was interrupted
}
}
FTP Proxy
A user of this project was kind enough to post an example of using System.Net.FtpClient with a FTP Proxy. The post can be found in the discussions section http://netftp.codeplex.com/discussions/391028.
Other Information
- Bulk Downloads Important information about mirroring / recursion!!
↧
↧
Source code checked in, #bff01d4d79943a5b1b5454bd858beb0deeedb7fd
Slight changes to the FtpTrace API, renamed Add/Remove methods to AddListener/RemoveListener.
↧
New Post: Passing password before TLS AUTH?
Firstly, thank you so much for help. I really appreciate that.
Now what happens: I run FileZilla on second PC and it fails also. Same error as with FtpClient. It seems that on that second PC is some kind of problem with Certifacates. That PC is in domain with lot of security stuff. I have informed Admin about that problem and I'm waiting for resolution from him.
Now what happens: I run FileZilla on second PC and it fails also. Same error as with FtpClient. It seems that on that second PC is some kind of problem with Certifacates. That PC is in domain with lot of security stuff. I have informed Admin about that problem and I'm waiting for resolution from him.
↧
Source code checked in, #ef3ddbb6c26d5ce55a3872927daf1885b510daa4
Changed packages scripts to run msbuild to ensure they always include an update binary of the associated build configurations.
↧