serial_lte_modem AT#XFTP="put" SLM data mode and escaping data?

[Mr.Newlove]

So I have to upload a bunch of files, some contain arbitrary data that might contain +,\r,\n,\ ext

So there are two different ways of using the FTP put command, one is in SLM data mode, the other is inline in quotes and I am having huge issues with both

**inline Mode?**
AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt","this is test content"
AT#XFTP="close"


**SLM Data Mode**
AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is test content
AT#XFTP="close"

We can talk about these two options:

Option1 is what I call inline mode:

if I try to include a  \" inside the first option, or a \r\n in the next the modem will just lock up for a long time. Is there any way to send a bunch of arbitrary binary data as long as I escape it somehow? since backslash doesn't seem to be working

Example that will fail:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt","this is\" test content"
AT#XFTP="close"

Option2: Is what you guys call SLM data mode:

According to the documentation and from what I can see in the code, the only way the modem should exit SLM data mode is after a timeout, or by sending +++

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/slm_data_mode.html

But this doesn't happen, it only seems to exit SLM mode when I send a \r\n but there appears to be no way of escaping this?

Another problem is if I just pretend the first issue isnt a thing and remove all new lines from my data(which I really can't do, this is just for exploring the other problem I am having) and send +++ it shows up in the file that is uploaded to the server?

Example that will write part of a file and then get an error because it drops out of SLM too soon:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is \r\ntest content+++
AT#XFTP="close"

If I try to use the +++ as intended from the documentation:

AT#XFTP="open","******username********","*******password*****","*******domain*******"
AT#XFTP="verbose","on"
AT#XFTP="binary"
AT#XFTP="put","test.txt"
this is test content+++
AT#XFTP="close"

I end up with a file on the server including the +++:

this is test content+++

This example will also fail if you do not send a \r\n at the end of the test content line even though the +++ is supposed to terminate it.

Few quite baffling things that do not follow normal conventions or even the documentation?

[Charlie]

Hi Kyle,

Thanks for your feedback, I have tested your observation and agree that we should improve the implementation of these parts.

I will talk with our development team and give you a reply later.

Best regards,

Charlie

[Mr.Newlove]

Hello Charlie,

OK great, both relived and slightly frustrated it wasn't just me.

Just a thought for the devs, other AT command structures I've used have used workarounds if for some reason its not practical to use escaping characters ect, Instead they would let people send data as hex bytes encoded in asci and convert it before sending it out

ie:

AT#XFTP="put","test.txt","this is a test packet\r\n\r\nwith many\r\n\r\nlines"

... would become....

AT#XFTP="put","test.txt",7468697320697320612074657374207061636b65740d0a0d0a77697468206d616e790d0a0d0a6c696e6573

But then coded back to normal bytes before sending said data.

Just a thought if that is easier for them to fix, obviously I would prefer standard escaping or the SLM Data mode working as intended.

Thanks,

Kyle

[Mr.Newlove]

Different but unrelated problem, even with good network conditions the FTP client sometimes just wont connect to the server at all, sits for ~8-10s and then just returns error. but then will work later. Not something easy to test on your end but just in case that gives you something

[Charlie]

Hi Kyle,
I tested with a public FTP server yesterday(ftp://ftp.dlptest.com/) and encounter the same errors at a specific period(about ten minutes ). I suspect this is affected by network or server availability. Anyway, I will try to enable debug information to see if there are some clues when I see the same error report. 

Best regards,

Charlie

[Mr.Newlove]

I opened another ticket about that problem specifically, it seems to come down to carrier DNS lockups when I was using the debugger.

https://devzone.nordicsemi.com/f/nordic-q-a/84121/serial_lte_modem-dns-resolution-issues

It would be great if I could just set my own DNS