Welcome to the Cumulus Support forum.

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Cumulus MX V4 beta test release 4.0.0 (build 4017) - 17 March 2024

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

The handshake failed due to un unexpected packet format

Topics about the Beta trials up to Build 3043, the last build by Cumulus's founder Steve Loft. It was by this time way out of Beta but Steve wanted to keep it that way until he made a decision on his and Cumulus's future.

Moderator: mcrossley

Dinant
Posts: 91
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 »

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: 91
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 »

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: 91
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 »

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: 26702
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 »

Yes, it looks like the third party ftp component which MX uses will negotiate TLS 1.0 but no later version.
Steve
Dinant
Posts: 91
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 »

What is the name of the FTP component you using?
User avatar
steve
Cumulus Author
Posts: 26702
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 »

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: 91
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 »

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: 91
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 »

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: 26702
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 »

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: 91
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 »

I have tested MX with the newer dll. TLS 1.0 is still not working. Same error.
User avatar
steve
Cumulus Author
Posts: 26702
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 »

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: 12685
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: The handshake failed due to un unexpected packet format

Post 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?...
You do not have the required permissions to view the files attached to this post.
Dinant
Posts: 91
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 »

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: 91
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 »

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: 12685
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: The handshake failed due to un unexpected packet format

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