The connection was closed by the server

Question

Hi,

we're working on a remote update feature with which an embedded software is supposed to be able to retrieve version updates from an update server. We've implemented the basic features with the Rebex libraries. Now we consistently run into this error:

SSH: Rebex.Net.SshException: The connection was closed by the server. Make sure you are connecting to an SSH or SFTP server.

Any help is greatly appreciated.

What we've tried / found out
- we're sure the device has internet access (e.g. pinging google works, tracert shows the target gets correctly resolved, telnet returns SSH-2.0...)
- we're sure its an actual SFTP server that does not block the calls (as far as the server is concerned nothing ever tried to communicate)
- whatever we could find on similar topics in this forum
- calling Rebex.Net.ConnectionManagement.ConnectionManager.TryConnect() returns false
- Connections generally worked for a while on different devices, but as soon as the connection failed on one, we cannot restore it anymore. Is there some kind of cache, we could kill?

Logs
(I tried to hide sensible data)

2025-01-23 15:04:49 Opening log file.
2025-01-23 15:04:49 INFO FileLogWriter(1)[116523074] Info: Assembly: Rebex.Common R5.10 for .NET Compact Framework 3.5
2025-01-23 15:04:49 INFO FileLogWriter(1)[116523074] Info: Platform: Windows CE 7.0.2877 32-bit; CLR: 3.5.14223.0
2025-01-23 15:04:49 DEBUG FileLogWriter(1)[116523074] Info: Culture: en; windows-1252
2025-01-23 15:05:26 INFO FileTransferClient(1)[132382830] Info: Connecting to : using Sftp.
2025-01-23 15:05:26 INFO FileTransferClient(1)[132382830] Info: Assembly: Rebex.Sftp R5.10 for .NET Compact Framework 3.5
2025-01-23 15:05:26 INFO FileTransferClient(1)[132382830] Info: Platform: Windows CE 7.0.2877 32-bit; CLR: 3.5.14223.0
2025-01-23 15:05:26 DEBUG FileTransferClient(1)[132382830] Info: Culture: en; windows-1252
2025-01-23 15:05:26 INFO FileTransferClient(1)[132382830] Info: Using proxy none.
2025-01-23 15:05:26 DEBUG FileTransferClient(1)[132382830] Proxy: Connecting to : (no proxy).
2025-01-23 15:05:26 DEBUG FileTransferClient(1)[132382830] Proxy: Connection established.
2025-01-23 15:05:29 ERROR FileTransferClient(1)[132382830] SSH: Rebex.Net.SshException: The connection was closed by the server. Make sure you are connecting to an SSH or SFTP server.
at Rebex.Net.SshSession.aplzc()
at Rebex.Net.SshSession.Negotiate()
at Rebex.Net.Sftp.whjoy.ahcku(ehmzn p0, Boolean p1)
at Rebex.Net.Sftp.hbhug(String p0, Int32 p1, SshParameters p2, ehmzn p3)
at Rebex.Net.Sftp.jpuyt(String p0, Int32 p1, SshParameters p2)
at Rebex.Net.FileTransferClient.Connect(String serverName, Int32 serverPort, FileTransferMode transferMode)
at ... our own code

2025-01-23 15:05:29 ERROR FileTransferClient(1)[132382830] Info: Rebex.Net.SshException: The connection was closed by the server. Make sure you are connecting to an SSH or SFTP server.
at Rebex.Net.SshSession.aplzc()
at Rebex.Net.SshSession.Negotiate()
at Rebex.Net.Sftp.whjoy.ahcku(ehmzn p0, Boolean p1)
at Rebex.Net.Sftp.hbhug(String p0, Int32 p1, SshParameters p2, ehmzn p3)
at Rebex.Net.Sftp.jpuyt(String p0, Int32 p1, SshParameters p2)
at Rebex.Net.FileTransferClient.Connect(String serverName, Int32 serverPort, FileTransferMode transferMode)
at ... our own code

Code
This is basically our code:

_client = new FileTransferClient();
_client.Settings.SslAcceptAllCertificates = true;
// This line is what's causing the error
_client.Connect(settings.FtpHost, settings.FtpPort, FileTransferMode.Sftp);

Answer 1

This looks like FileTransferClient was able to establish a connection to the server, but did not receive the "SSH-2.0..." string (instead, the connection was closed).

To make sure the issue is not in Rebex libraries, try whether you can reproduce the problem on the Windows Embedded Compact device using just .NET Compact Framework API alone, without using any Rebex code:

// These settings correspond to test.rebex.net:22, which
// should work for you as well if the device has internet
// connectivity. Then, try using your server.
string address = "194.108.117.16";
int port = 22;

using (var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
    // connect to the server
    socket.Connect(new IPEndPoint(IPAddress.Parse(address), port));

    // receive some data
    var buffer = new byte[1024];
    int bytesReceived = socket.Receive(buffer, 0, buffer.Length, SocketFlags.None);

    // here, bytesReceived is supposed to be a non-zero value
    Assert.NotZero(bytesReceived);
}

If Socket.Receives fails or returns zero, it means that no part of the server’s identification string has been received.

Comments

Thanks for the quick reply. I've tested the code you provided with different servers (our own, and also test.rebex.net), which work when I run the code on my Dev-PC, but on device the Socket throws an unspecified SocketException with any server.
We'll investigate some more, but suspicion now lies within the hardware of the embedded device.

---

I've been testing for a while now and found a few ways of how the problem could be resolved. However, it seems to always come back.

Here's what I tried:
 - flushing the dns cache by executing ipconfig /flushdns with the command line
 - clearing the device's internet cache and history
 - restarting the device
 - changing the device IP address to something arbitrary, and then restoring the initial IP
 - Any combination of the above

The problem temporarily goes away but resurfaces again soon after. Is there some kind of networking cache, or socket blockage I could resolve with Rebex? Could something like this be caused by us not properly cleaning up FileTransferClient?

Curios is also that the same error keeps happening, even if no network cable is connected.

---

What kind of devices do you use, and how are they connected to the network?

Unfortunately, Rebex libraries don't provide any APIs for managing the operating system's TCP/IP subsystem - except the Rebex.Net.ConnectionManagement.ConnectionManager API, which only makes it possible to initiate a GPRS, EDGE, LTE, ... connections and is not useful on devices connected via LAN or WiFi.

Also, even if FileTransferClient was not properly cleaning up its TCP connections (which is unlikely - just make sure to call Dispose method), that should not bring down the operating system's TCP subsystem - if a badly written app did that, it would actually be an extremely serious bug in the OS, and we are not aware of any such issue.

The problem you are describing does not even resemble anything our customers ever encountered on any Window CE platform during more than 20 years we have been supporting those. It looks like something is wrong with the network connectivity, but that's something that's beyond our reach.

Basically, if the problem can be reproduced even without using any Rebex library (using the sample code I posted at Jan 23, for example), it's unlikely we would be able to help resolving this issue without an ability to reproduce it. Rebex library assume a working OS and .NET with a working TCP/IP subsystem, and won't operate properly if this is not available. If we had access to an actual device and network where these issues occur, we might be able to look into it, but even that would be outside the scope of Rebex library support (it would be a matter for our consulting services - https://www.rebex.net/support/services/).