FreeRTOS FTP Upload problem

Libraries
1

Hello,
I’m a beginner in FreeRTOS, one of my projects needs to establish a FTP server on AM1808(ARM9 core). I downloaded an lab project(160919_FreeRTOS_Labs), which i succeed to transplant to my board. I can mount, list and download files quickly, but it went unstable in uploading files, the upload speed has to be limited at 1KB/s if the file size exceeds 2KB mostly, whilch had confused me few weeks.
I used wireshark to capture the net packets, it seems that the ftp server needs over seconds to handle a pack of FTP data. And the UDP log always present “TCP: No active socket on port xxx”. Anyone can give me some advises?
Thanks a lot.
Blow is the wireshark capture picture and some UDPlogs.

image
image1366×768 196 KB

[IP-task ] Socket 54438 -> 192.168.0.30:63722 State eSYN_RECEIVED->eESTABLISHED
0.000.001 [SvrWork ] PASV Connected from 54438 to 63722
0.000.001 [SvrWork ] LIST
0.000.001 [IP-task ] CheckClose 841 <= 841 (0 <= 841 <= 841)
0.000.001 [IP-task ] MSS: sending 1460
0.000.001 [IP-task ] Socket 54438 -> 192.168.0.30:63722 State eESTABLISHED->eCLOSE_WAIT
0.000.001 [IP-task ] FreeRTOS_closesocket[54438 to 192.168.0.30:63722]: buffers 24 socks 4
0.000.001 [IP-task ] TCP: No active socket on port 54436 (192.168.0.30:63720)
0.000.001 [IP-task ] TCP: No active socket on port 54437 (192.168.0.30:63721)
0.000.001 [IP-task ] TCP: No active socket on port 54438 (192.168.0.30:63722)
0.000.001 [IP-task ] Socket 21 -> 192.168.0.30:63712 State eLAST_ACK->eLAST_ACK
0.000.001 [IP-task ] TCP: No active socket on port 54436 (192.168.0.30:63720)
0.000.001 [IP-task ] TCP: No active socket on port 54437 (192.168.0.30:63721)
0.000.001 [IP-task ] TCP: RST received from 192.168.0.30:63718 for 54435
0.000.001 [IP-task ] Socket 54435 -> 192.168.0.30:63718 State eESTABLISHED->eCLOSED
0.000.001 [SvrWork ] FTP: recv: ‘/Infineon-Automotive_Power_SelectionGuide_2019-ProductSelectionGuide-v01_00-EN.pdf’ 1460 Bytes (68 bytes/sec)
0.000.001 [IP-task ] FreeRTOS_closesocket[54435 to 192.168.0.30:63718]: buffers 25 socks 3
0.000.001 [IP-task ] TCP: No active socket on port 54438 (192.168.0.30:63722)
0.000.001 [IP-task ] Socket 21 -> 192.168.0.30:63712 State eLAST_ACK->eLAST_ACK
0.000.001 [IP-task ] TCP: No active socket on port 54436 (192.168.0.30:63720)
0.000.001 [IP-task ] TCP: No active socket on port 54437 (192.168.0.30:63721)
0.000.001 [IP-task ] TCP: No active socket on port 54438 (192.168.0.30:63722)
0.000.001 [IP-task ] Socket 21 -> 192.168.0.30:63712 State eLAST_ACK->eLAST_ACK
0.000.001 [IP-task ] TCP: No active socket on port 54436 (192.168.0.30:63720)
0.000.001 [IP-task ] TCP: No active socket on port 54437 (192.168.0.30:63721)
0.000.001 [IP-task ] TCP: No active socket on port 54438 (192.168.0.30:63722)
0.000.001 [IP-task ] Socket 21 -> 192.168.0.30:63712 State eLAST_ACK->eLAST_ACK
0.000.001 [IP-task ] TCP: No active socket on port 54436 (192.168.0.30:63720)

2

Hello, usually it is more useulf to attach a (zipped) PCAP file, rather than a graphic image of the capture.
Could you please attache a zipped PCAP file?
The problem that you describe often has to do with the configuration of TCP, and of the FTP server in particular.

3

Yes, i wanted to upload the pcap and source code zip to the forum, but it’s warnning new users can not upload the attachment.
It seems that the tcp stack dosen’t reply an ack after the ftp-data uoloaded, which leads the PC to retransmit the data, and then disconnect the data link.

4

Lucily, my level promoted, so i can attach the wireshark pcad and tcp&ftp source code.
ARM_FreeRTOS.zip (695.1 KB)
wireshark upload.zip (13.7 KB)

5

Thanks, but I’m afraid that something went wrong uploading the PCAP.
In your ZIP file I see a folder, not a file called xxx.pcap (created by WireShark ( or any other Ethernet sniffer ).

6

wireshark upload.zip (13.7 KB)
I downloaded it myself, and can open the pcap file by wireshark. I ziped again, please try once more.

7

Sorry, my fault. I opened the ZIP with 7-zip, clicked on the PCAP, but 7-zip opened wireshark upload.pcap as an archive.
When I extracted it to a folder first, I could open it with WireShark.
I am going to have a look.
Thanks, Hein

8

Hello Jia, I looked into the other ZIP and saw that you are using source from 2016, four years ago.
In stead of spending time on old sources, I would recommend to upgrade your project from these sources:

The protocols haven’t been included into the Github repo’s, but you can find them on my github.

9

Well, thanks a lot, i’ll try the new source to my program.And reply to you the result.

10

Ps. you will see that the folder structure is a bit different now: *.c have gone to a folder called source.

Before:

/include
/portable
/protocols
/*.c

Today:

/include
/source/*.c
/source/portable
/source/protocols

If you have any questions, or difficulties upgrading, you can always ask in this post.

11

Hi Hein,
I’ve already replace all the source to the latest, and compiles OK, but the test result is the same with before.The deference is only 1460B can be uploaded.Please help checking which config parameter i wrote a wrong value.
ARM_FreeRTOS.zip (1.4 MB)
wireshark upload_0523.zip (6.9 KB)

12

By the way, i found may be two bugs.
The first is in FreeRTOS_FTP_server.c, prvStoreFileWork() function, a pointer char *pcBuffer is used without initialized, which cause a crash everytime uploading, then i initialized it with a empty buffer in ddr, and at least the program keep running although the uploading fails.
The second is in ff_sys.c, struct file_systems uninitialized, which cause in function FF_FS_Add() would not call FF_FS_Init(). Maybe the TI’s compiler dosen’t surpport zero init static or global variables automatically.

13

The first is in FreeRTOS_FTP_server.c, prvStoreFileWork() function, a pointer char *pcBuffer is used without initialized

This is not a bug and your changes don’t look not correct to me.

I guess you missed the word FREERTOS_ZERO_COPY: it means that a pointer to a pointer must be passed to FreeRTOS_recv().
When the function returns a positive number, pcBuffer will point to a buffer that is owned by the IP-stack. The buffer will be released with a dummy read with a null-pointer:

    /* Advance the read pointer with xRc bytes. */
    FreeRTOS_recv( pxClient->xTransferSocket, ( void * ) NULL, xRc, 0 );

For a normal recv() operation you are right, you must provide a pointer to a buffer of a certain size.

The second is in ff_sys.c, struct file_systems uninitialized

Note that file_systems is declared static:

    static ff_sys_t file_systems;

and so the struct must be zero’d at start-up. Can you verify if it is all zero at start-up?

And also there is already a test like you want to add:

    if( file_systems.xFileSystemCount == ( BaseType_t ) 0 )
    {
        FF_FS_Init();  /* xFileSystemCount  will be set to '1' */
    }

+FAT always want at least one file system, obligatory, which is “/”.

I still don’t understand the communication in the PCAP files that you’ve sent. The socket on the embedded side seems to stop acting after the last byte has been received. Even after receiving a simple directory listing.

I’m uploading two PCAP files, one is OK, it finishes as it shoot, the other is from you, the server ( 192.168.0.200 ) stops responding when the FIN flags is seen:

recv_listings.zip (1.6 KB)

To be continued

14

Hi Hein,
Finally i think i resolved my problem, what a long journey on this.
I capture all the packet not only TCP, find every time the ftp data communication established then an ARP would be send from PC, but my program reply the arp with invalid checksum. Then i seached the key word and found a post discrebe it( FreeRTOS-TCP arp reply has invalid checksum), which surggests to add #define ipconfigETHERNET_MINIMUM_PACKET_BYTES 60 in TCP configration head. And now it upload file successfully, although i’m not quite clear about the mean of ipconfigETHERNET_MINIMUM_PACKET_BYTES still. Anyway, it’s seemed to working fine now.

15

Glad to hear that the problem is solved.

We could give ipconfigETHERNET_MINIMUM_PACKET_BYTES a default of 60, but I’m afraid that it would break existing projects. We could issue a compiler warning if the macro is not defined.

then an ARP would be send from PC, but my
program reply the arp with invalid checksum

ARP is without a user checksum. Did you see the Ethernet checksum fail?

Here is an example of an ARP packet: arp_example.zip (264 Bytes)
It is padded with 18 bytes ( all zero’s ) to give it a length of 60 bytes in total. Some developers prefer using a minimum length of 64.

The problem that you saw in ARP is probably the same as for TCP: packet were not padded and therefore got dropped. The ACK/FIN packets are only 54 bytes long.

But please undo your changes to FreeRTOS_FTP_server.c

Thanks for reporting all this!