KTCPCLOSE not working on slow connections

I am using TCP sockets to talk with a FTP server. All works well on a good strong connection when the speed is high. But when i trottle the connection on FTP to simulate a slow connection, the TCP connection doesn’t seem to close.

I have double checked the file on the remote server. The SHA256 checksum of the server file is the same as the client, so all data is sent over correctly.

When i receive the +KTCP_ACK: x,1 (data done sending) i send the KTCPCLOSE command. By checking KTCPSTAT before and after this command i see the socket status going from 3 (connection is up) to 4 (connection is closing). But looking at wireshark at the remote server, no TCP FIN packet is ever received. The socket stays in the closing state forever.

If i kick the client from the server i see the TCP FIN packet sent from FTP server to client, and the module responds correctly to this. Closing both the command and the passive socket and sending an +KCNX_IND

ATI information

RHL769x.2.27.183100.201809071813.x7120m_3
HL7692
HL769x.2.27
x7120m
FUSED
2018-09-07 18:51:19
r12879

I don’t see problem using the +KFTPCLOSE.
Maybe you can try that.

I will give using the FTP commands a try, see if that does work.

That said, this wouldn’t be an ideal solution in our use case as i would like to use TCP sockets myself to keep the FTP implementation the same between WIFI and FTP and we use some more FTP commands that are not included in the KFTP commands in the HL76.

On a side note, using multiple 20k KTCPSND commands instead of 1 big 360k send does seem to help. However this is a lot slower when the connection is fast as the overhead of a full send command is about a second.

you can capture wireshark log for +KFTPCLOSE and +KTCPCLOSE for comparison.

Using the KTFP functions does partly work.

When sending a file the transfer happens corretly. The full file is transmitted and a file transfer success is shown on the server. But right after the transfer is finished i get a NO CARRIER notification.

If i add a delay in the transfer of bytes to the HL76 to slow it down even more, i do not get the NO CARRIER and it succesfully gfets the KFTP_IND of the file transfer and it closes the FTP connection.

So something seems to go wrong in the transfer of a large amount of bytes. Hardware flow control IS being used for the uart port. If i trottle the FTP connection more or less, the actual transfer of bytes slows down. Yet for some reason the bytes still seem to be sent to quickly

You might meed to tune +kipopt command

I don’t understand what you mean with tuning KIPOPT.
I tried some different values of AT+KIPOPT=0,“TCP”,x,x,x to no success

BTW, why do you want to add delay?

I don’t want to add a delay, in my country everything works fine as our LTE speed and reliability is high enough. But in some other countries the connection isn’t as great, which means the transfer speed is a lot lower at times. This caused the issue described above.

By adding a trottle in the FTP server i can simulate this issue for my debug environment so that i can trobbleshoot the issue.

If you are talking about the delay in the bytes (over uart), this delay is ofcourse unwanted as well as it will slow down transfer in a good connection as well. But if i don’t add this delay on slow connections i get the NO CARRIER error after the tranfer of the file.

When sending a file the transfer happens corretly. The full file is transmitted and a file transfer success is shown on the server. But right after the transfer is finished i get a NO CARRIER notification.

If i add a delay in the transfer of bytes to the HL76 to slow it down even more, i do not get the NO CARRIER and it succesfully gfets the KFTP_IND of the file transfer and it closes the FTP connection.

Actually you can transfer file in both cases, right?

For a single file, yes.
The no carrier is only received after the transfer is completed and the file has been transfered succesfully. But after that i cannot send more files

Same goes for the intial TCP use case, the full file is transferred correcltly. But i cannot close the socket, which means that firstly FTP aborts the transfer after a while. And secondly i cannot continue using the FTP connection to send more commands/files.

Thats why the problem seems weird to me. If i send the bytes over UART to the HL76 without a delay (using hardware control flow). The file IS transferred correctly, but after that the connection becomes unusable. Either the TCP connection doesn’t close (and i cannot send more commands on the command channel). Or using KFTPSND the device gives a no carrier. But the file IS transferred correctly.

If i slow down the UART bytes to the HL76 (100ms delay between each 600 bytes) the file is still tranferred succesfully but slower. But after that i am still able to use FTP and send more files etc.

does problem happen in lower UART baud rate?

I’ve just tested again on the default baud rate and the problem persists.

Interestingly enough, if i ignore the NO CARRIER and do another KFTPSND, this transfer starts correctly and finishes. Followed by a new NO CARRIER. I also don’t get any KFTP_IND showing the transfer completed

did you test 9600 baud rate?

I tried the default 115200.

This would first work because the transfer rate was a lot slower. If i clamped down on the connection more it stopped working as well. 115200 already limits the max transfer rate too much though

Trying again i set up a fresh project, with the same issue. After a +KTFPSND if the connection is slower then the UART transfer i get a NO CARRIER after the transfer has completed. Weirdly enough i CAN start another ftp send on the same FTP connection after this NO CARRIER has been received. This makes me think this really is a bug in the firmware?

‘Should’ i be able to send data over UART without having to add a delay, assuming hardware control is used. Does the modem correctly stop/slow down the transfer when it’s buffer is getting full?

And if so, is 2.27 the newest firmware or has this possible bug maybe already been fixed? I cannot access https://source.sierrawireless.com/resources/airprime/software/hl7692-firmware/ due to ’ Server Error in ‘/’ Application’