+TCP +FAT FTP Server

pascal-vehigy wrote on Thursday, November 19, 2015:

I have the +TCP Labs going on an STM32F407 controller, now I am trying to make the FTP example work. I have copied and modified the TCPServer, HTTPServer and FTPServer code from the win32 simulator demo. The HTTP server seems to work pretty ok, the FTP server doesn’t do much. I am able to connect to it, but I cannot get the directory listing, I have tried with several different clients, most of them just get stuck, telling me they are downloading. With FileZilla I got a few messages which might be helpful:

Status:	Resolving address of EnergyMaster
Status:	Connecting to 192.168.12.107:21...
Status:	Connection established, waiting for welcome message...
Response:	220 Welcome to the FreeRTOS+TCP FTP server
Command:	USER anonymous
Response:	331 Anonymous login okay
Command:	PASS **************
Response:	230 OK.  Current directory is /
Command:	SYST
Response:	215 UNIX Type: L8
Command:	FEAT
Response:	211-Features:
Response:	 MDTM
Response:	 REST STREAM
Response:	 SIZE
Response:	211 End
Status:	Server does not support non-ASCII characters.
Status:	Connected
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/"
Command:	TYPE I
Response:	200 NOOP command successful.
Command:	PORT 192,168,12,104,71,197
Response:	200 NOOP command successful.
Command:	LIST
Response:	150 Opening ASCII mode data connection to for /bin/ls 
Error:	Connection timed out
Error:	Failed to retrieve directory listing

and here is what happens in passive mode:

Status:	Resolving address of EnergyMaster
Status:	Connecting to 192.168.12.107:21...
Status:	Connection established, waiting for welcome message...
Response:	220 Welcome to the FreeRTOS+TCP FTP server
Command:	USER anonymous
Response:	331 Anonymous login okay
Command:	PASS **************
Response:	230 OK.  Current directory is /
Status:	Server does not support non-ASCII characters.
Status:	Connected
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/"
Command:	TYPE I
Response:	200 NOOP command successful.
Command:	PASV
Error:	Disconnected from server: 10053
Error:	Failed to retrieve directory listing

any help is greatly appreciated.

rtel wrote on Thursday, November 19, 2015:

[We have a project for the STM32F4, including FTP and HTTP on an SD card, but haven’t found the time to release it yet!]

We have mainly tested with FileZilla, so I should stick with that for now. Not sure if it helps, but here is the output I get when connecting to the FreeRTOS+TCP FTP server running on a SAM4E (a Cortex-M4F microcontroller). I’m using a Windows host.

Status:	Resolving address of RTOSDemo
Status:	Connecting to 192.168.0.2:21...
Status:	Connection established, waiting for welcome message...
Status:	Insecure server, it does not support FTP over TLS.
Status:	Server does not support non-ASCII characters.
Status:	Connected
Status:	Retrieving directory listing...
Status:	Directory listing of "/" successful

Your output looks fine up to the LIST command, I will take a WireShark capture to see if LIST is also being used when I connect from Windows.

Other than that - is there anything unusual on the disk you are trying to view view FTP. For example, could there be a file name or path that has more characters than the value set by ffconfigMAX_FILENAME in FreeRTOSFATConfig.h, etc.

Regards.

heinbali01 wrote on Friday, November 20, 2015:

My guess is that you are close to getting it working :slight_smile:

  • The FTP connection with 192.168.12.107:21 went OK
  • Your HTTP server runs, which means that +FAT is functional

And now for some reason the data connection doesn’t seem to get established.
That could be caused by a firewall. Or caused by a lack of resources somewhere.

Do you have logging enabled?

For example like this:

    #define ipconfigHAS_PRINTF     1
    #if( ipconfigHAS_PRINTF != 0 )
        #define FreeRTOS_printf( MSG )   usart_printf MSG
    #endif

In your logging there is this command:

    Command:    PORT 192,168,12,104,71,197

As you probably know, the device is asking for a data connection on the address: 192,168,12,104 port 18373 (71 << 8 + 197)

I just made 3 captures and I also collected the Filezilla logging (2 - Info and “Show raw directory listing”).

You find the following files in the attachment ‘filezilla_examples.7z’ :

filezilla_active.pcap + txt Dir listing with PORT
filezilla_passive.pcap + txt Di listing with PASV
filezilla_send.pcap Sending a 1.2 MB file

If you want us to look you can attach a PCAP of an FTP session.

Regards.

pascal-vehigy wrote on Friday, November 20, 2015:

I would be very interested in the STM32F4 demo, especially because I am not 100% satisfied with the performance. I am sure there are a few settings in the different config files (TCPIP and FAT) that are not ideal. Is it possible, that you sent me the config files of the demo?
I’d also be interested in how you tied the ETH peripheral into the TCPIP stack, if you remember, I had a few issues getting ethernet working several months back, hardware checksum still isn’t working for me.

Regarding the files stored on my SD card, they are all very standard in content and naming, no fancy characters, not even spaces in the names. LFN is enabled and adequate buffer size is allocated. I can successfully “open” each file using firefox (via HTTP server). This lets me conclude, that accessing the SD card and handling the FATFS (FAT32 on an 8GB card, one partition) is working properly.

Best,
Pascal

heinbali01 wrote on Friday, November 20, 2015:

hardware checksum still isn’t working for me

It won’t be the first MAC peripheral that promises checksum-off-loading while it does not work properly. Should ask ST about this.

I checked that explicitly by clearing the 2 CRC fields ( IP and TCP/UDP check-sum ), send messages from the device and look with Wireshark. Or I would have it receive packets from my laptop with erroneous check-sums.

I would be very interested in the STM32F4 demo

Could you write to us directly ( h point tibosch at freertos point org ) ?
Then I will send you the current sources so you can try them.

If FTP doesn’t work properly, could you send a PCAP of some session? And some logging ( produced by FreeRTOS_printf() ) would also be interesting.

Regards.

pascal-vehigy wrote on Friday, November 20, 2015:

Hello Hein,

Thanks for the valuable input, I will implement some logging. I did capture the network traffic and the corresponding filezilla log (see attachment).

Firewall is not the issue, completely disabled it for testing purposes. Also FTPing to other servers in the network works.

I’ll get back to you with the FTP logs.

Best,
Pascal

pascal-vehigy wrote on Wednesday, November 25, 2015:

in the meantime I got my setup running, FTP and HTTP with +FAT and microSD card.

I also enabled logging for FTP and HTTP, in the FTP logs I keep getting this message:

prvListSendWork: Unknown error (rc) = (-2113601484)

it happens around line 1767 in the file FreeRTOS_FTP_server.c. Note that I got my own logging mechanism going, so I had to change the original formatting a bit. I suppose the original message would look like this:

prvListSendWork: Unknown error (rc = 82050034)

Again, FTP is working fine, navigating through dirs, copying both directions, renaming, deleting. There are also no suspicious messages in the FileZilla console/log area.

I am just wondering what this “error” means.

Regards,
Pascal

heinbali01 wrote on Wednesday, November 25, 2015:

in the FTP logs I keep getting this message:
prvListSendWork: Unknown error (rc) = (-2113601484)

Sorry about that :slight_smile:

-2113601484 would be 0x82050034 which is a +FAT error code. A what?

 /* See ff_error.h */
 * Error codes are 32-bit numbers, and consist of three items:
 *    1Bit     7Bits      8Bits           16Bits
 *     .     ........   ........    ........  ........
 * [ErrFlag][ModuleID][FunctionID][--   ERROR CODE   --]

It is a 32-bit ‘signed’ number, which contains the Module ID (source file), a function ID and an error code.

The error code 0x34 is very innocent, end-of-dir:

#define FF_ERR_DIR_END_OF_DIR    52

In the later version, you won’t see this error any more.

Within ff_stdio.c, these codes are translated from FF_Error_t to a comparable errno value.

In the latest version, both error codes are accessible:

int stdioGET_ERRNO();
FF_Error_t stdioGET_FF_ERROR();

The idea of the FF_Error_t is to make debugging a lot easier. The functions in ff_error.c will print a readable error like e.g. :

	ff_file.c::
        FF_ExtendFile::
            The file was not opened for writing

which gives a lot more information than an errno 13: EACCES /* Permission denied */

Again, FTP is working fine, navigating through dirs, copying both
directions, renaming, deleting. There are also no suspicious messages
in the FileZilla console/log area.

Good to hear, thanks.

Regards,
Hein

pascal-vehigy wrote on Wednesday, November 25, 2015:

All right, thank you for clarifying this.

Regards,
Pascal