Page 2 of 3
Re: The handshake failed due to un unexpected packet format
Posted: Mon 09 Apr 2018 11:31 am
by Dinant
steve wrote:What version of Windows are you using - 2003 as in your profile?
I am using Windows 2012 R2.
First I'll wait for my provider to answer my questions about TLS 1.0 not working.
In the meantime I've changed my profile!
Re: The handshake failed due to un unexpected packet format
Posted: Mon 09 Apr 2018 2:33 pm
by Dinant
I have an answer from my provider. Indeed they have disabled SSLv2 and SSLv3 but also TLS v1.0.
So they only support TLS 1.1 and TLS 1.2.
My provider uses proFTPD with the following line in the proFTPD config file:
TLSProtocol TLSv1.1 TLSv1.2
Tonight I'll do a test with WinSCP if TLS 1.1 and TLS 1.2 are both working on Windows 2012 R2 OS.
Re: The handshake failed due to un unexpected packet format
Posted: Mon 09 Apr 2018 5:07 pm
by Dinant
My Windows 2012 R2 server is capable of using SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2 only if it also enabled on the server side.
I have tested this with WinSCP.
So I think the existing version of MX (v3.0.0 build 3042) is capable of using SSLv3 and maybe TLS 1.0.
Re: The handshake failed due to un unexpected packet format
Posted: Mon 09 Apr 2018 7:15 pm
by steve
Yes, it looks like the third party ftp component which MX uses will negotiate TLS 1.0 but no later version.
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 1:56 pm
by Dinant
What is the name of the FTP component you using?
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 2:11 pm
by steve
System.net.ftpclient. There is apparently now a later version but with a different name, presumably it now supports 1.1 and 1.2
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 2:24 pm
by Dinant
I'll found some info on
https://archive.codeplex.com/?p=netftp under issues. Look for the item TLSv1.2 support.
Maybe TLS1.1 and TLS1.2 must be added to the SslProtocols?
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 2:39 pm
by Dinant
The version of System.Net.FtpClient.dll MX is using is 1.0.5281.14359.
On the
https://www.nuget.org/packages/System.N ... 5824.34026 it says there are two newer versions.
The latest version is 1.0.5824.34026. On that page there exists a Manual download link.
If you download that file and extract it. In the directory system.net.ftpclient.1.0.5824.34026\lib\net40 you may find a file System.Net.FtpClient.dll with version number 1.0.5824.34026. Maybe that one supports TLS 1.1.
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 3:15 pm
by steve
Yes, I saw that discussion about TLS 1.2, that user got it working by changing one line in the source code and rebuilding. It’s possible that might produce a version of the DLL which would work with MX. It’s also possible that the DLL in the download you mention might support 1.1 or 1.2, and might also work with MX.
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 5:36 pm
by Dinant
I have tested MX with the newer dll. TLS 1.0 is still not working. Same error.
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 5:49 pm
by steve
That doesn’t surprise me, I expect that line of code is still the same. Rebuilding the DLL from the source with that line changed stands more chance of working.
Re: The handshake failed due to un unexpected packet format
Posted: Tue 10 Apr 2018 11:05 pm
by mcrossley
The sample code for FluentFTP (which seems to be a fork/update of System.Net.FTClient) shows that if the .Net platform supports it (version 4.5) the client can enable TLS 1.1 & 1.2...
Code: Select all
// Override the default protocols. The example line sets the protocols
// to support TLS 1.1 and TLS 1.2. These are only available if the
// executable targets .NET 4.5 (or higher). The framework does not enable these
// protocols by default.
conn.SslProtocols = SslProtocols.Default | SslProtocols.Tls11 | SslProtocols.Tls12;
// Alternate example: Only support the latest level.
//conn.SslProtocols = SslProtocols.Tls12;
I couldn't find the post referencing the "line of code", but I've had a guess, and..
I've had a bash at compiling a version of the System.Net.FTClient DLL targeting .Net 4.5 with TLS 1.2 & 1.2 enabled by default using the example above to see if it works with MX, however I don't have time to test it. If you are feeling brave and you have .Net 4.5 maybe give it a try?...
Re: The handshake failed due to un unexpected packet format
Posted: Wed 11 Apr 2018 6:17 am
by Dinant
I have tested the new System.Net.FTClient DLL but it doesn't work. It produces the same error. I am using .NET Framework 4.7.1.
Re: The handshake failed due to un unexpected packet format
Posted: Wed 11 Apr 2018 7:21 am
by Dinant
Replacing the 2 files produces also an exception during the start of cumulus.
Code: Select all
Current culture: Dutch (Netherlands)
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl
y 'System.Net.FtpClient, Version=1.0.5281.14359, Culture=neutral, PublicKeyToken
=fa4be07daa57c2b7' or one of its dependencies. The located assembly's manifest d
efinition does not match the assembly reference. (Exception from HRESULT: 0x8013
1040)
at CumulusMX.Cumulus..ctor(Int32 HTTPport, Int32 WSport)
at CumulusMX.Program.Main(String[] args) in C:\Users\steve\Documents\Visual S
tudio 2015\Projects\CumulusMX\CumulusMX\Program.cs:line 101
Re: The handshake failed due to un unexpected packet format
Posted: Wed 11 Apr 2018 8:36 am
by mcrossley
OK, unless you are getting the exception I don't think it was picking up the new file.
I had a quick look this morning, I don't think MX can be made to use an updated DLL without MX being recompiled - because the public key of the assembly will change (or be removed
)when I compile it.
