Welcome to the new home of the Cumulus Support forum.

Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3044 7 December 2018. See the Wiki for download

The handshake failed due to un unexpected packet format

Discussion of version 3 of Cumulus, which runs on Windows, Linux, and OS X. All Cumulus MX queries in here, please.

Moderator: mcrossley

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Mon 09 Apr 2018 11:31 am

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!

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Mon 09 Apr 2018 2:33 pm

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.

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Mon 09 Apr 2018 5:07 pm

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.

User avatar
steve
Cumulus Author
Posts: 26714
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Post by steve » Mon 09 Apr 2018 7:15 pm

Yes, it looks like the third party ftp component which MX uses will negotiate TLS 1.0 but no later version.
Steve

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Tue 10 Apr 2018 1:56 pm

What is the name of the FTP component you using?

User avatar
steve
Cumulus Author
Posts: 26714
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Post by steve » Tue 10 Apr 2018 2:11 pm

System.net.ftpclient. There is apparently now a later version but with a different name, presumably it now supports 1.1 and 1.2
Steve

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Tue 10 Apr 2018 2:24 pm

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?

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Tue 10 Apr 2018 2:39 pm

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.

User avatar
steve
Cumulus Author
Posts: 26714
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Post by steve » Tue 10 Apr 2018 3:15 pm

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.
Steve

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Tue 10 Apr 2018 5:36 pm

I have tested MX with the newer dll. TLS 1.0 is still not working. Same error.

User avatar
steve
Cumulus Author
Posts: 26714
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Post by steve » Tue 10 Apr 2018 5:49 pm

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.
Steve

User avatar
mcrossley
Posts: 5232
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2
Operating System: Stretch Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: The handshake failed due to un unexpected packet format

Post by mcrossley » Tue 10 Apr 2018 11:05 pm

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?...
You do not have the required permissions to view the files attached to this post.

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Wed 11 Apr 2018 6:17 am

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.

Dinant
Posts: 54
Joined: Sat 17 Aug 2013 9:11 am
Weather Station: Davis Vantage Pro2
Operating System: Windows 2012 R2
Location: Markelo
Contact:

Re: The handshake failed due to un unexpected packet format

Post by Dinant » Wed 11 Apr 2018 7:21 am

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


User avatar
mcrossley
Posts: 5232
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2
Operating System: Stretch Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: The handshake failed due to un unexpected packet format

Post by mcrossley » Wed 11 Apr 2018 8:36 am

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. :(

Post Reply