Please read the posts in the Announcements section about the current status of Cumulus development now that I have retired

Please read this post before posting

Latest Cumulus release v1.9.4 (build 1099) - Nov 28 2014
Latest Cumulus MX release - v3.0.0 build 3043 Jan 20 2017. See this post 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.
Dinant
Posts: 52
Joined: Sat Aug 17, 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

Postby Dinant » Mon Apr 09, 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: 52
Joined: Sat Aug 17, 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

Postby Dinant » Mon Apr 09, 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: 52
Joined: Sat Aug 17, 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

Postby Dinant » Mon Apr 09, 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: 26569
Joined: Mon Jun 02, 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Postby steve » Mon Apr 09, 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
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876

Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job

Dinant
Posts: 52
Joined: Sat Aug 17, 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

Postby Dinant » Tue Apr 10, 2018 1:56 pm

What is the name of the FTP component you using?

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

Re: The handshake failed due to un unexpected packet format

Postby steve » Tue Apr 10, 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
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876

Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job

Dinant
Posts: 52
Joined: Sat Aug 17, 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

Postby Dinant » Tue Apr 10, 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: 52
Joined: Sat Aug 17, 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

Postby Dinant » Tue Apr 10, 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.Net.FtpClient/1.0.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: 26569
Joined: Mon Jun 02, 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Postby steve » Tue Apr 10, 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
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876

Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job

Dinant
Posts: 52
Joined: Sat Aug 17, 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

Postby Dinant » Tue Apr 10, 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: 26569
Joined: Mon Jun 02, 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: The handshake failed due to un unexpected packet format

Postby steve » Tue Apr 10, 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
-----
Hosting available for Cumulus web sites. See http://sandaysoft.com/forum/viewtopic.php?f=2&t=11876

Please read the posts in the Announcements section about the current status of Cumulus development since I have retired from my day job

User avatar
mcrossley
Posts: 5171
Joined: Thu Jan 07, 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

Postby mcrossley » Tue Apr 10, 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: 52
Joined: Sat Aug 17, 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

Postby Dinant » Wed Apr 11, 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: 52
Joined: Sat Aug 17, 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

Postby Dinant » Wed Apr 11, 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: 5171
Joined: Thu Jan 07, 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

Postby mcrossley » Wed Apr 11, 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. :(


Return to “Cumulus MX”

Who is online

Users browsing this forum: No registered users and 4 guests