Payload cannot be more then 32768 bytes.

Sep 10, 2012 at 5:04 PM

I've read thru the forum and see that others were also having this problem.  

I'm running the SSH.NET.2012.3.9 version which I downloaded from nuget.  I used dotPeek to take a look at the source and found the following

public SftpClient(ConnectionInfo connectionInfo)      : base(connectionInfo)    {     

this.OperationTimeout = new TimeSpan(0, 0, 0, 0, -1);     
this.BufferSize = 32730U;   

}

This 32730U value suggests to me that it includes the 1024 * 32 - 38 "fix" however I am still getting the error.

If I increase the value from 38 to 50 as I saw elsewhere in the forum the problem goes away.  To err on the side of caution though I changed the source to 1024 * 16 which also worked.

 

Sep 10, 2012 at 5:33 PM

I believe the compiler sums it up, you can also go to Source Code and view the latest there. You can see the revision for 2012.3.9 (same as on Download page). 

Here is the link to the proper revision: http://sshnet.codeplex.com/SourceControl/changeset/view/14873

Sep 10, 2012 at 6:08 PM

Thanks for the reply Kenneth.

Unfortunately, even after I applied the fix I am now getting a strange error when I attempt to upload to our production server. 

"A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied"

Any ideas what could cause this?

Sep 10, 2012 at 6:20 PM

Do you get any messages in Output window, such as: SendMessage to server ?

There is a TraceSource when compiled with DEBUG, with name SshNet.Logging, if you add some settings in App.config, look:

  1. http://msdn.microsoft.com/en-us/library/system.diagnostics.defaulttracelistener
  2. http://geekswithblogs.net/theunstablemind/archive/2009/09/09/adventures-in-system.diagnostics.aspx

I forgot how I did it heh...

Sep 10, 2012 at 8:48 PM

Here is the output from the trace.  Not sure exactly what this is telling me.  Does this offer any reason why I'd get the error I mentioned above?

SshNet.Logging Verbose: 1 : Initiating connect to '**REMOVED_MY_HOST**:13266'.

SshNet.Logging Verbose: 1 : Server version '2.0' on '1.36_sshlib GlobalSCAPE'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeInitMessage': 'SSH_MSG_KEXINIT'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeInitMessage': 'SSH_MSG_KEXINIT'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeDhGroupExchangeRequest': 'SSH_MSG_KEX_DH_GEX_REQUEST'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeDhGroupExchangeGroup': 'SSH_MSG_KEX_DH_GEX_GROUP'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeDhGroupExchangeInit': 'SSH_MSG_KEX_DH_GEX_INIT'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeDhGroupExchangeReply': 'SSH_MSG_KEX_DH_GEX_REPLY'.
SshNet.Logging Verbose: 1 : SendMessage to server 'NewKeysMessage': 'SSH_MSG_NEWKEYS'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'NewKeysMessage': 'SSH_MSG_NEWKEYS'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ServiceRequestMessage': 'SSH_MSG_SERVICE_REQUEST'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ServiceAcceptMessage': 'SSH_MSG_SERVICE_ACCEPT'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'BannerMessage': 'SSH_MSG_USERAUTH_BANNER'.
SshNet.Logging Verbose: 1 : SendMessage to server 'RequestMessageNone': 'SSH_MSG_USERAUTH_REQUEST'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'FailureMessage': 'SSH_MSG_USERAUTH_FAILURE'.
SshNet.Logging Verbose: 1 : SendMessage to server 'RequestMessagePassword': 'SSH_MSG_USERAUTH_REQUEST'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'SuccessMessage': 'SSH_MSG_USERAUTH_SUCCESS'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelOpenMessage': 'SSH_MSG_CHANNEL_OPEN : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelOpenConfirmationMessage': 'SSH_MSG_CHANNEL_OPEN_CONFIRMATION : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelRequestMessage': 'SSH_MSG_CHANNEL_REQUEST : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelSuccessMessage': 'SSH_MSG_CHANNEL_SUCCESS : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : SendMessage to server 'ChannelDataMessage': 'SSH_MSG_CHANNEL_DATA : #0'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'DisconnectMessage': 'SSH_MSG_DISCONNECT'.
SshNet.Logging Verbose: 1 : Disconnect received.
A first chance exception of type 'Renci.SshNet.Common.SshException' occurred in Renci.SshNet.DLL

Sep 11, 2012 at 5:23 AM

I see there is a caught exception (last line). Can you follow the steps in How to enhance debugging experience with SSH.NET to see what causes it? See under 

Breaking on exception - even the catched ones

Sep 11, 2012 at 5:32 PM

It broke on the partial void SocketWrite(byte[] data) method in the Session.NET.cs file with the following error:

A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied

That is the same error I specified above.  That method does not appear to be able to specify any type of address.

Any ideas?

Sep 11, 2012 at 9:24 PM

I was able to get in contact with the production FTP admin to see if he could offer any insight and this is what he said when I told him that SSH.NET uses scp for file transfer:

 I'm afraid that only the bare SFTP subprotocol is fully supported. There may be a way in the SSH.NET library to suppress the unique SCP portion and have it instead use SFTP only, but I'm not familiar with it.

Is it possible to get SSH.NET to use sftp and not scp?

Sep 12, 2012 at 6:09 AM

From what I can tell, SSH.NET uses the SFTP protocol when using SftpClient. When using ScpClient, it executes scp on the remote server and then does something else. You can see in ScpClient.[NET.].cs and SftpClient.[NET40.].cs and compare.

Doing some searching for the reported server versionstring, yielded "http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-bug-maxpkt.html

When using one SSH-2 server, identifying itself as "1.36_sshlib GlobalSCAPE", PuTTY reports "Incoming packet was garbled on decryption". This was originally reported as a bug in FileZilla, and turns out to be a bug in the server.

When PuTTY opens the data channel for the SFTP session, it sends SSH_MSG_CHANNEL_OPEN, and states a window size of 0x7FFFFFFF (2147483647) bytes but a maximum packet size of 0x4000 (32768). That is, the server is permitted to send almost any amount of data without requiring an SSH-level acknowledgment from PuTTY, but may not send an individual packet larger than 32768 bytes.

The server is disregarding the specified maximum packet size, and is sending a packet of 65548 bytes. PuTTY treats this as a decryption failure, since the most common reason for the packet length to be out of range is because there was a disagreement in the bulk encryption between client and server, causing the packet length field to decrypt to random garbage data. In fact that isn't the cause of the problem in this case, but PuTTY unfortunately can't determine that by itself.

With this information:

  1. Is it possible for you to identify the exact server type, name and version? I know they mention some on the threads linked to by mentioned link, but they are from 2008, and for the sake of accuracy, I want to be sure. :)
  2. Could you provide sample code that can reproduce this defect with mentioned server?
Sep 12, 2012 at 8:10 PM

Here's the info about the server.

GlobalSCAPE Secure FTP Server 3.3.10 Build 08.31.2009.3

Unfortunately I am not able to give you access to the production server but here is the test code that I've been using to reproduce this issue.  Its a modification of the upload/download unit test that comes with the source.

 

        [Test]
        public void Test_Sftp_Upload_And_Download_1MB_File()
        {
            using (var sftp = new SftpClient("host_removed", 13266, "user_removed", "pass_removed"))
            {
                sftp.Connect();

                string uploadedFileName = @"C:\philasd_2012_09_10.csv";
                string remoteFileName = "philasd_2012_09_10.csv";

                using (var file = File.OpenRead(uploadedFileName))
                {
                    sftp.UploadFile(file, remoteFileName);
                }

                sftp.Disconnect();
            }
        }

 

Sep 12, 2012 at 11:14 PM

One of the architects on the team found another article [1] that suggested that the packet size be reduced even more.  When he changed to 8 * 1024 the code started working.

I guess you could consider this a work around for the server bug.

Thanks for your help with this.

 

[1] - http://www.frostjedi.com/phpbb/viewtopic.php?f=46&t=11043

Sep 13, 2012 at 5:20 AM

Did you change Session.cs:MAXIMUM_PACKET_SIZE, MAXIMUM_PAYLOAD_SIZE, or simply SftpClient.cs:BufferSize, or another I don't know about yet?

Sorry, I get lost in this code sometimes and need it spelled out... :(

Sep 13, 2012 at 1:40 PM
Edited Sep 13, 2012 at 1:41 PM

I ran into this issue uploading to my SFTP server.  Going by another solution posted here I changed the SftpClient buffer size to match the FileStream buffer size and it works like a charm.  Changes in bold and underlined. 

 

 

using (var client = new SftpClient(privConnectInfo))
{
	client.BufferSize = (1024 * 16);
	client.Connect();
	if (client.IsConnected)
	{
		using (FileStream fs = new FileStream(fileToUpload.FullName, FileMode.Open, FileAccess.Read, FileShare.None, (1024*16)))
		{
			client.UploadFile(fs, targetFTPFile);
		}
	}	
}
Sep 13, 2012 at 3:05 PM
Edited Sep 13, 2012 at 3:05 PM

We changed only the client so

 

 

using (var client = new SftpClient(privConnectInfo))
{
	client.BufferSize = (1024 * 8);