FTP connection problems | Thales IoT Developer Community
July 25, 2018 - 5:18pm, 2568 views
Hello,
I use EHS6 / ELS61 modules to send FTP via AT command. My application is battery powered, so I have to shut down module completely after transmission and cut power. Next transmission normally after one day.
So I switch on the module and wait for registration:
^SYSLOADING
^SYSSTART
AT
OK
ATE1
OK
AT^SPOW=1,0,0
OK
AT\Q3
OK
AT^SCFG="Radio/Band","511"
^SCFG: "Radio/Band","511"
OK
AT^SXRAT=1,2
OK
AT+CPIN?
+CPIN: READY
OK
AT+CREG?
+CREG: 0,5
OK
AT+CSQ
+CSQ: 17,99
OK
After this I set up SICS and SISS parameters:
AT^SICS=0,conType,GPRS0
OK
AT^SICS=0,apn,"*****"
OK
AT^SISS=0,"srvType","FTP"
OK
AT^SISS=0,"conId",0
OK
AT^SISS=0,"cmd","put"
OK
AT+CSCS="UCS2"
OK
AT^SISS= 0,"address","006600740070003A002F002F00760065007200690062006F0078003A004E006F00640065004A00530031003000300040003100390032002E003100360038002E00380031002E0031002F"
OK
AT^SISS= 0,"files","00560045005200490042004F0058002D00390039003900390039002D00320033003000370032003000310038002D003100380034003200310038002E006300730076"
OK
AT+CSCS="GSM"
OK
Then I open the connection:
AT^SISO=0
OK
^SIS: 0,0,2100,"Ftp open(192.168.81.1:21)"
^SIS: 0,0,2100,"220 Microsoft FTP Service"
^SIS: 0,0,2100,"FTP Login OK"
^SIS: 0,0,2100,"put VERIBOX-99999-23072018-184218.csv"
^SISW: 0,1
AT^SISW=0,69
^SISW: 0,69,0
<.....data....>
OK
^SISW: 0,1
AT^SISW=0,0,1
^SISW: 0,0,0
OK
^SIS: 0,0,2100,"226 Transfer complete."
^SISW: 0,2
AT^SISI=0
^SISI: 0,6,0,69,0,0
OK
AT^SISE=0
^SISE: 0,0
OK
AT^SISC=0
This works fine with the most FTP servers and internet providers.
But in few cases with some FTP servers nearly every time (95%) after first SISO command the module answers with:
^SIS: 0,0,2100,"Ftp open(192.168.81.1:21)"
and then comes nothing more. I abort after one minute.
But when I close connection after approx. 15 seconds and open immediately again (SISI and SISE show nothing strange):
AT^SISI=0
^SISI: 0,3,0,0,0,0
OK
AT^SISE=0
^SISE: 0,0
OK
AT^SISC=0
OK
AT^SISO=0
OK
Then everything works fine again (in most cases, only sometimes I have to repeat a third time):
^SIS: 0,0,2100,"Ftp open(192.168.81.1:21)"
^SIS: 0,0,2100,"220 Microsoft FTP Service"
^SIS: 0,0,2100,"FTP Login OK"
^SIS: 0,0,2100,"put VERIBOX-99999-23072018-171618.csv"
My questions:
can it be that the module is not ready for internet connection shortly after startup (I tried to insert a simple wait before SISO, but did not help)?
Is this a connection problem to the APN or to the FTP server (in my experience it is only depending on the FTP server, not on the provider)?
What does the URC: ^SIS: 0,0,2100,"Ftp open(192.168.81.1:21)" exactly mean: trying to establish internet connection or already have communication with the server?
Does anyone has experience what to do to avoid open and close and open again to get it running (as the module is battery powered, I don't want to waste battery if not necessary)?
Is there any command, that indicates, that internet connection is available (I tried also CGREG, but does not help)
Thanks and best regards
Klaus
Hello,
If it was failing each time I would suspect that there is some incompatibility between FTP server and the client.
I might imagine some network quality problems that could influence the connection but according to your observation it's rather not the case. Especially that it usually connects when you retry. You could of course do some tests to wait longer after reboot to make sure that the module is ready but I doubt that this could change something. You wait for the network registration and it should be working.
It seems that it could be somehow related to the FTP server. You could also try to test the server with some PC client to verify. Or maybe it is related to the network - you could try to establish some other connection before FTP (http for example) and check if this will also stuck. Or try to connect to that failing FTP server using some other network operator.
This FTP open URC is thrown just after SISO replies OK, so it does not yet mean that the connection was established. You can be sure that it is, when you get the first welcome message from the server.
You can read the status of the internet connection defined with AT^SICS with AT^SICI? command.
Best regards,
Bartłomiej
Hello Bartłomiej,
thank you for your answer.
I had this behavior two ***** until now:
First case is with a Microsoft FTP server from one of our customers (from this case are the above logs). Unfortunately it lies behind a VPN, so I can't find it from any other FTP client nor can I reach another server with this SIM card. The possibilities to log this server are also very restricted. This problem really burns. The customer now tries to install a FileZilla FTP server. We will see what happens.
The second case is with our own FTP server (Synology NAS): I found this issue independent from the network operator (I tried several different ones). On the other hand we have a lot of modules sending to this server without any problem. But the most of them use TC63i. So maybe it is an issue of 3G modules. Maybe when after start up the module registers to 2G and switches later to 3G. Is it possible, that this makes problems, when it happens immediately after or during attempt to open the internet service (SISO)?
So a possible solution (or way for verification of this theory) could be to wait until module is registered to 3G. But this causes to wait (not good for battery) a certain time. What when no 3G available - then I always lose battery power?
Or there is a way to tell the module to keep the first technology after registering. So if 2G available it registers and stays at 2G. And when no 2G available it registers initially to 3G. So I have no change during establishing the session. But I could not find a command which enables this. Do you have an idea?
And I don't know if this is an elegant solution?
And it speaks against this theory, that I have also FTP servers without any problems, regardless of 2G or 3G.
Regarding first case (customers Microsoft server over VPN): also here we have about 50% (100 pieces) that work always fine. Some units have this problem nearly always, some only every 2,3,4 days.
Best regards
Klaus
Hello,
TC63i is a different module and no longer manufactured for a long time probably. So there may be differences in implementation and behavior.
You can use AT^SXRAT command to set the radio access technology but you can't configure the module to not change any technology that it will register to. For testing purposes it could be a solution.
If you have the own server and devices that frequently have problems, you could try to trace TCP traffic on the server. Capturing the trace on the device side might be the best solution but you are not able to do it. Without any tracing it may be very hard to find the answer.
If among the same type of devices some are having this issue more frequently then the others maybe the devices location matters here (and the network quality) or the operator. You could also compare the firmware versions (ATI1 command) to check if this can have any influence on the problem.
Best regards,
Bartłomiej