We have been using CR800 programs to send data via Passive FTP successfully for some time. Recently we attempted getting FTP with TLS turned on working but are having some issues.
What we did:
- In the Setting Editor we turned on TLS (=1)
- In the logger program we used FTP Put/Get Option = 12 (send via passive FTP with TLS)
- At the serve rend we are using Filezilla Server and have configured this to accept passive FTP using TLS Encryption and accept explicit FTPS. We created a self signed certificate in filezilla and told it to use this.
To monitor the program we looked at the server logs and also did an IP sniff in terminal emulator.
We see on both that the logger (client) tells the server to use TLS (AUTH TLS) and the server responds acknowledging it is going to use TLS but then we have failed comms and the server drops the connection. It kind of looks like the negotiation of the encryption or passing of default certificate is failing. Please be aware that we have assumed that this transaction will take place on standard FTP ports 20/21 as we have used Put/Get Option as 12 (explicit ftp). Our router is not allowing traffic from the standard Implicit ports (989/990)
* Last updated by: WeetbixKid on 4/24/2013 @ 3:14 AM *
Hello all,
Any answer??? I have exactly the same problem, the only difference is on our server which is on a linux system; ftp standard works fine with PutGetOption=2 in FTPClient function, but when I set PutGetOption=12, the transaction begins normally on port 21, but server disconnects because it is waiting some kind of validation from CR800...(certificate acknowledgement???).
Any help would be greatly appreciate...
(CR800 on OS27, GPRS connexion via COM110 modem)
Regards.
Sometimes, if the certificate used on the FTP server is complicated/concatenated (chained or multiple certificates), the datalogger can't parse through it completely before the link times out on the FTP server or the logger times out (70 seconds).
Our newest logger, the CR6 is able to parse though these without much issue.
Sorry that this does not resolve the issue. It is something we are currently working on with the datalogger OS.
To work around it, use a single non-chained certificate on the FTP server.