toelke / lwip-ftpd Goto Github PK

Hello Philips
Looking at the code it seem's that when inside the send_next_directory function we are in a endless loop until the end of the directory list.
As we only call send_data function which does not call tcp_output, after a while tcp_sndbuf(pcb) returns zero, and no more data are send....
Furthermore as tcp_output does not allow to send data during the tcp_input process, there is no way to list long file list...
How do you manage to get this to work ?
Best Regards

Hi.
I tried passive mode by uncommenting line 1107 in ftpd.c. It does work, opens a session & lists the files present in the SD Card, but seems to leave a pcb open after the FTP session is terminated. This is evidenced by lwIP stats showing an increasing number of used TCP_PCB_LISTEN after each FTP session, until the max MEMP_NUM_TCP_PCB_LISTEN has been reached, thereafter failing to open an FTP session.

This may be a red herring, but from what I can see, the fsm->datapcb created during the cmd_pasv() (line 873) is not the same pcb passed to send_next_directory() and subsequently closed (line 517).

Any help in resolving this issue would be appreciated.
Regards
Mark

After running through cmd_pasv function several times successfully, I finally get a hard fault in function ftpd_dataclose of code:

temppcb = tcp_listen(fsm->datapcb);
if (!temppcb) {
    ftpd_dataclose(fsm->datapcb, fsm->datafs);
    fsm->datapcb = NULL;
    fsm->datafs = NULL;
    return;
}

from cmd_pasv function.

Any clues as to what might be causing the hard fault? It happens specifically on line:
fsd->msgfs->datafs = NULL;

.. in ftpd_dataclose function.

Many thanks!

in file vfs.c,
function vfs_opendir

i'm pretty sure that
vfs_dir_t* dir = malloc(sizeof *dir);
should be
vfs_dir_t* dir = malloc(sizeof dir);

Phillipp, I'm seeing memory leaks... the module is failing malloc() after several repeated downloads.

I'm wondering about this particular malloc(), in vfs_open():

vfs_file_t *f = malloc(sizeof(vfs_file_t));// line 88, vfs.c

... I can't find where the corresponding free() for this is. What am I missing?

FTP works with linux tools but not with FileZilla on Windows - can you fix this if it is a bug? file transfer does not work. Listing is OK.

Hello Philipp,

I am trying out your code on a Keil MCBSTM32C Board with STM32F107 chip.
FatFS is running fine, but ftpd seems to hang after LIST command, please see UART log. Total Commander (ftp client) seems to wait forever after this LIST command.

Could you please help me narrowing down this issue? I have good microcontroller experience but no experience with ftp protocoll.

Don't know how to contact you otherwise than creating this issue.

Thanks,

lwIP 1.4.1 test starting
Trying to mount
Drive mounted
----A 01.01.2011 12:00 610 TEST
1 File(s), 610 bytes total
0 Dir(s), 3952599040 bytes free
FAT type = FAT32

Link on
eth init
response: 220 lwIP FTP Server ready.
query: USER userresponse: 331 User name okay, need password.
query: PASS userresponse: 230 User logged in, proceed.
query: SYSTresponse: 214 UNIX system type.
query: FEATresponse: 502 Command not implemented.
query: HELP SITEresponse: 502 Command not implemented.
query: PWDresponse: 257 "/" is current directory.
query: TYPE AGot TYPE -A-response: 502 Command not implemented.
query: PORT 192,168,1,33,237,124response: 200 Command okay.
query: LISTresponse: 150 File status okay; about to open data connection.

I'm using lwip/ftpd/ff on an Atmel SAM4E-EK... project is to create an embedded FTP server using an SD card. I'm using FileZilla 3.10.1.1 as the client.

I can't seem to get FZ to proceed beyond PWD when 0 is used as the drive designator/LUN... if I kludge the code to return 'C:' then FZ is happy... up until the next call, LIST, which I also have to kludge to get further. Now I can see the contents of the directory, but apparently I'll have to keep kludging the cwd return string to replace '0' with 'C' for all commands.

Am I missing something in the setup of FZ or ftpd? Or ff? I tried SmartFTP and it recognized the server as a UNIX style but it hung up too.

I see that same question has been asked before :

#1
#7

I'm having the same ( or similar ? ) problem. If the client sends a "LIST" command, data is sent correctly but message 226 is sent %10 of the time. I've checked with Wireshark, nothing on the wire. Client is hung since he is waiting for close indication.

Looking at the other posts, maybe there is a problem with my port, I'm not sure. If so, any idea how to check this ?

Thanks in advance.

Lwip 2.0.3 running on STM32F4 HAL version V1.24.1

The FTP server runs great. However sometimes when FTP send a file from pc to STM using total commander:
message: Assertion "tcp_recved: len wrapped rcv_wnd"

It is because rcv_wnd overflowed This value leads to TCP_MSS default 536 and increasing makes no difference.

Rebooting the STM is the only solution.

in vfs.c, fuction vfs_closedir the memory for the directory object is freed but not closed

void vfs_closedir(vfs_dir_t* dir)
{ if (dir) 
  {  f_closedir(dir);   // <== need to add this
    free(dir);
  }
}

Hi

I have a problem with the ftp directory listing, it is very slow.
There are big pauses in the transfer, visible in the attached wireshark log.
Do you have any idea what can cause these pauses?

Thanks and regards,
Daniel

dir_slow.pcapng.txt

Hi Philipp,

If the client issues a QUIT command, ftpd replies with 221 and waits for the ftpd_msgsent callback to release the allocated resources with the help of ftpd_msgclose. However, following check never lets the code to reach the ftpd_msgclose function :

https://github.com/toelke/lwip-ftpd/blob/master/ftpd.c#L1203

if (pcb->state > ESTABLISHED) return ERR_OK;

pcb->state is always CLOSE_WAIT at this point in case of QUIT command.

Is this check really necessary ? Can we remove it to solve the problem ?

If an ftp client send a RETR closely followed by an ABOR memory is freed in the cmd_abrt() -> tcp->abort() -> tcp->abandon() -> ftpd_msgerr() -> ftpd_dataclsoe() call sequence that cmd_abrt subsequently tries to use/free again. Taking the code to free memory out of cmd_abrt() fixes the crash, but causes a memory leak as expected. I believe the fundamental problem is the callbacks used do not have the ability to propagate the freeing of the memory back up the call return stack. Some one of the calling functions need to know enough to invalidate a pointer somewhere.

This was found by implementing the SIZE command and issuing a curl command that had a range starting at offset 0.

curl ftp://ip_address/filename --range 0-1000 -o /tmp/out.tx

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hello

I am trying to get ftpd running, but after 2 days of debugging, I am stuck. It gets pretty far, but when the file list is being sent, something stucks. It happens with different clients (also the windows built-in).
I have attached a wireshark log and the output of the firmware.
If you have a little time to look at it, I would be very glad.

Thanks and regards,
Daniel

ftp_MasterMACS.pcapng.txt

log.txt

Hi Philipp,

Am I missing something or the following line deletes a global object which is not allocated on heap in case guard_for_the_whole_fs is passed as parameter :

https://github.com/toelke/lwip-ftpd/blob/master/vfs.c#L74

It seems like call to free should also be placed inside if block in the following snippet :

void vfs_close(vfs_t* vfs) {
	if (vfs != &guard_for_the_whole_fs) {
		/* Close a file */
		f_close(vfs);
	}
	free(vfs);
}