PLS62-W FTPS Delays | Telit Cinterion IoT Developer Community
July 14, 2020 - 4:46am, 1620 views
We are using the built-in FTP client in the PLS62-W modem, and have recently switched to FTPS from FTP.
To improve throughput, we are using multiple concurrent sessions. The example below shows two concurrent sessions, each sending 5 files from the modem's flash file system.
Both sessions seem to start up OK, but we receive no response from the modem after 2 minutes, at which point we try to close the connection. The serial port then becomes unresponsive for 7 minutes, after which the modem reports the sessions have failed.
Is this expected behaviour? We are in good coverage, so taking 9 minutes to eventually fail is not optimal behaviour. We also lost the ability to use the serial port for file writes and network monitoring during this time.
Would it help to reduce the TCP retry limit? Or is there something else we should do when giving up on an FTP connection?
00:04 AT^SISS=1,"srvType","Ftp"
00:04 AT^SISS=1,"conId","1"
00:04 AT^SISS=1,"address","ftps://*****"
00:05 AT^SISS=1,"cmd","fput"
00:05 AT^SISS=1,"files","68-10.log,68-11.log,68-12.log,68-13.log,68-14.log"
00:05 AT^SISS=1,"user","*****"
00:05 AT^SISS=1,"passwd","*****"
00:05 AT^SISO=1
00:05 ^SIS: 1,0,2100,"Ftp open(*****:990)"
00:06 AT^SISS=2,"srvType","Ftp"
00:06 AT^SISS=2,"conId","1"
00:07 AT^SISS=2,"address","ftps://*****"
00:08 AT^SISS=2,"cmd","fput"
00:08 AT^SISS=2,"files","68-15.log,68-16.log,68-17.log,68-18.log,68-19.log"
00:08 AT^SISS=2,"user","*****"
00:08 AT^SISS=2,"passwd","*****"
00:08 AT^SISO=2
00:08 ^SIS: 2,0,2100,"Ftp open(*****:990)"
00:08 ^SIS: 1,0,2100,"SSL-Info: TLS, 3.3, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
00:08 ^SIS: 1,0,2100,"SSL-Cert: C=XX;O=*****;CN=*****"
00:08 ^SIS: 1,0,2100,"220 (vsFTPd 3.0.2)"
00:11 ^SIS: 1,0,2100,"FTP Login OK"
00:11 ^SIS: 1,0,2100,"fput 68-10.log,68-11.log,68-12.log,68-13.log,68-14.log"
00:11 ^SIS: 2,0,2100,"SSL-Info: TLS, 3.3, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
00:11 ^SIS: 2,0,2100,"SSL-Cert: C=XX;O=*****;CN=*****"
00:12 ^SIS: 2,0,2100,"220 (vsFTPd 3.0.2)"
00:13 ^SIS: 2,0,2100,"FTP Login OK"
00:15 ^SIS: 2,0,2100,"fput 68-15.log,68-16.log,68-17.log,68-18.log,68-19.log"
02:05 AT^SISC=1
09:26 OK
09:26 ^SIS: 1,0,100,"isRunning --> FALSE"
09:26 ^SIS: 1,0,2100,"226 Transfer complete."
09:28 ^SIS: 2,0,2100,"FPUT : 68-15.log 102662 bytes"
09:28 ^SIS: 2,0,100,"IOError -149, Unknown during socket:: write \0a"
Hello,
Could you provide some more information? How does it work in case of one session only? How big are the files and how long does it take to send them? It looks like you close the connection before the files are uploaded. Is it the same when you close after the upload is finished? Could you check the firmware version with ATI1 command?
Thanks and best regards,
Bartłomiej
We have seen this happen with a single session sending a single file. The files are generally around 120 KB. Sending a single file normally takes around 15 seconds.
We've also seen the case where the modem does not appear to recover after the AT^SISC=1 command until we reset it.
The ATI1 response is:
Cinterion
PLS62-W
REVISION 02.000
A-REVISION 01.000.04
Thank you
Hello,
I tried ftps uploads with this module and wasn't able to reproduce your problem. How frequently does it happen in your case?
In my tests SISC was always returning immediately in normal cases. Only while I was closing the connection before successfull upload, it was taking a few seconds.
I don't know the details of implementation but there's some communication with the FTP server on the control channel when the connection is being closed and probably some more when the client aborts the upload (in case it takes too long for example). So I think that there might be 2 reasons for the delay in closing the connection: network issues (in case of weak signal for example) and server issues (might be overloaded and not reply on time). For test you could also check with some other network operator or ftp server.
Regards,
Bartłomiej
Hi Bartłomiej,
It seems to happen infrequently, but we are sending around 1 file per minute, so the chances are increased.
I left the unit running last night with a 1 hour timeout on the FTP, and this timeout was triggered (meaning the FTP session didn't finish for at least an hour).
Apart from trying different servers, what do you suggest for closing down such an FTP session? We don't really want to use AT^SISC in case it causes the AT command interface to become unresponsive.
Also, are there other ways to try and limit the connection time? We've tried AT^SCFG="Tcp/OT","120" to limit the maximum time, but this hasn't made a difference.
Lastly, I have just been informed that the FTPS session is not encrypting the file data (it is using PROT C). Is there any way to get the modem to encrypt the file data?
Thanks again
Hello,
If it takes so long it can really be a problem. It is possible that this would never happen with some other network operator or FTP server. It is possible that it is cused by MNO network issues. But anyway it should not take so long on the device either. So I think that you could report it to your contact person in Gemalto/Thales M2M or distributor as a potential defect.
As a workaround you could try with another operator or FTP server. Or you could try disconnecting the network or data service on another interface.
The built-in FTP client is not configurable, so if data is not encrypted you can't change it. As an alternative you would have to use the custom implementation of FTP either with AT commands and transparent connection or with Java MIDlet. Some time ago I prepared a demo MIDlet for FTP (https://iot-developer.thalesgroup.com/showcase/java-explicit-ftps-implementation-bouncycastle). It can encrypt both control and data channel and with additional BoucyCastle library it can also use esxplicit version of FTPS. But it is a demo and especially if BounceCastle is to be used, it ***** to be optimized because this lib is really big.
Best regards,
Bartłomiej