Secure FTP failure with Verizon cellular

Question

I am trying to perform what seems to be a very simple operation: sending a very small text file to an FTP site. My code looks like this: try {

            Ftp _ftp = new Ftp();
            _ftp.Connect(Program.DefaultFTPAddress, 21, null, FtpSecurity.Unsecure);
            TlsParameters _parms = new TlsParameters();
            Certificate _cert = Certificate.LoadDer(@"/" + Program.DefaultCertName);
            _parms.Certificate = new CertificateChain();
            _parms.Certificate.Add(_cert);
            _parms.CertificateVerifier = CertificateVerifier.AcceptAll; // change for production
            _ftp.Secure(_parms);        
            _ftp.Login(Program.DefaultFTPUser, Program.DefaultFTPPwd);
            _ftp.PutFile(filePathName, @"/" + fileName);
            _ftp.Disconnect();
            File.Delete(filePathName);
            return true;

        }
        catch (Exception ex)
        {
            throw ex;
        }

It works fine when I am connected to the wireless network, but when I try to use the cell phone to connect, I get "An operation was attempted on something that is not a socket." Am I missing something here unique to going cellular, or is traffic being blocked by the cell provider? The actual exception is being thrown on the call to _ftp.Secure(_parms).

Answer 1

Are you running this in .NET Compact Framework? This error has been known to occur on this platform when the TCP socket underlying System.Net.Sockets.Socket object becomes unusable in a certain way due to some kind of failure.

As for the traffic being blocked by the cell provider - this is quite possible. Some of our users reported that some providers (namely AT&T in the US and O2 in the UK, as of 2009) employ some kind of firewall that blocks explicit FTP/SSL for some reason, although implicit FTP/SSL on port 990 works fine.

Update: It turned out this was not caused by Rebex FTP/SSL, FTP server or cell provider, but by using OpenNETCF's ConnectionManager class in a way that caused the connection to be terminated as soon as .NET's garbage collection was called. Because garbage collection is more likely to occur after a substantial number of objects has been allocated, this was almost guaranteed to occur after a successful SSL negotiation.

Comments

Running on a Windows Mobile 6.5 device using .NET CF 3.5 I have been assured by Verizon that no ports are being blocked. Given that, I must presume that the problem is the former - can you provide any insight into diagnosis of the failure details? The debug output looks like this (with 4 calls to the tlsdebug handler): Type: Negotiating Level: Important Source: Unspecified Type: UnexpectedException Level: Important Source: Unspecified Type: Alert Level: Important Source: Sent Type: Closed Level: Important Source: Unspecified

An operation was attempted on something that is not a socket

---

We believe the 'An operation was attempted on something that is not a socket' error is actually a bug in the .NET Compact Framework's System.Net.Sockets.Socket class. In some situations, its underlying handle will suddenly become 'not a socket', making all subsequent method calls on this object fail. Our clients have mostly observed this to occur when a connection or connectivity is lost in some ways. However, a proper behavior would be for the Socket object to throw a different exception, such as 'The socket has been closed', which is still an error, although less misleading.

However, let's get back to the cell provider for now - it's perfectly possible to block explicit FTP/SSL without blocking any ports. All that's needed for that is an FTP-aware firewall that handles unsecured FTP (on port 21) perfectly, while terminating the session as soon as SSL negotiation is attempted (still on port 21). That's exactly what we have observed with AT&T and O2.

Would it be possible to make sure this is not the case with Verizon as well? A simple test would be trying to use a third-party FTP/SSL client app to connect to the same FTP server. If it fails as well over cell phone, it would prove the problem is caused by the cell provider. If you don't have any FTP/SSL client app, try Total Commander 2.52 beta 3 (please note you have to unzip a proper cecmdssl.dll file into its application folder to enable FTP over SSL). Please let me know the results.

---

Total Commander connects just fine, so I have to believe it's something to do with the Rebex component. As listed above, the code is pretty straightforward - are there additional property settings I need to get this to work?

---

No, there are no additional settings. The code works over wireless network, so it should work over cell phone as well. Would it be possible to create a communication log using Ftp object's LogWriter property and mail it to us for analysis? At this point, we still don't know where exactly the failure occurs - the log would make that clear.

By the way, did you enable SSL in Total Commander, and was it actually used? If unsure, try connecting to ftp.rebex.net (username: "anonymous" password: "guest") and we'll check our server logs.

---

I did enable SSL in Total Commander, and just now connected using it to your ftp server. I generated a log file from my app. To what address may I send it? It shows a successful insecure connection, but throws the exception on sending the TLS packet.