Having problems with '0:\' drive/LUN designator about lwip-ftpd

[scowell]

OK... an update...
1.) There are several emulation modes in FZ that work with '0:/'... best for me appears to be DOS.
2.) Next problem was 'JAN 00 00:00 ' at the first of each filename in the FZ dir listing... I found each use of 'shortlist' (i.e. send_next_directory(fsd, pcb, 0);) and made the '0' into a '1'... I lost my dir info (size, last mod, perm, owner, etc) but the thing works. Next problem... only 15kiB/sec... so FreeRTOS time.

So I'll have to tease out which 'send_next_directory()' needs shortlist, and which doesn't... definitely screws up the FZ file pull when the last mod date appears at the front of the filename.

[toelke]

I could not get filezilla to connect at all. It sends a "TYPE I" and when the device answers with 502 FZ just stops the connection.

I have had good success using TotalCommander, the Windows built-in ftp-client and the Linux NetKit ftp-client.

Implementing TYPE I or something other than 0:\ should be rather easy. Correctly displaying the time is a big problem though.

[scowell]

I forgot to mention that I hacked the 'TYPE' message to respond OK... that would make a difference! I'll try the several different clients when I get to work. The 'JAN 00 00:00' in front of the filename appears to be a header problem... the code doesn't put it in front of the info header, so not sure why FZ has this problem... I could, of course, debug FZ! More later... thanks for your reply.

[scowell]

OK, most problems resolved... I'm still stuck on slow download, the upload is crazy fast (>300kiB/s)... download still slow (< 16kiB/s). Is this related to the tcp timetics? I seem to have read somewhere that this is expected until you go to RTOS for lwIP... any clue?

[scowell]

Here's something... you clip the return value from sfifo_space() to 2048...

// ftpd.c line c. 477
if (len > 2048)
len = 2048;

... wondering why this was clipped... certainly causes an exception when I set it higher... we'd much rather be taking data from the disk a cluster at a time. What is the limitation? I've increased the fifo size.

[toelke]

I would guess the 2048 is just a nice value for a buffer on the stack.
Are you sure you made the buffer bigger when you set the clipping higher? (l. 466)

[scowell]

Yes, I increased the fifo to 0x7FFF. It was 2048.
I'll check the code when I get in to work. My uP has
128K RAM.

The memory alignment is set to 32bit... I wonder
if this is appropriate... I'll experiment and let you know.
__
Steve
.

On 2/10/2015 1:33 AM, toelke wrote:

I would guess the 2048 is just a nice value for a buffer on the stack.
Are you sure you made the buffer bigger when you set the clipping
higher? (l. 466)

—
Reply to this email directly or view it on GitHub
#2 (comment).

[toelke]

I did not mean the fifo but the buffer "buffer" declared in line https://github.com/toelke/lwip-ftpd/blob/master/ftpd.c#L466

[scowell]

Ah... it's on the stack! I'll check that code later today...
that would do it. Thanks.

On 2/10/2015 7:25 AM, toelke wrote:

I did not mean the fifo but the buffer "buffer" declared in line
https://github.com/toelke/lwip-ftpd/blob/master/ftpd.c#L466

—
Reply to this email directly or view it on GitHub
#2 (comment).

[scowell]

Yes, that was the problem... works much better with fifo at 0x8000 and
buffer at 0x4000... 1MiB/s! I'll close the incident... thanks again for
your
help, great set of code.

On 2/10/2015 7:25 AM, toelke wrote:

I did not mean the fifo but the buffer "buffer" declared in line
https://github.com/toelke/lwip-ftpd/blob/master/ftpd.c#L466

—
Reply to this email directly or view it on GitHub
#2 (comment).

Stephen Cowell
Project Manager/Engineer
Plasmability LLC
Office [phone]
Cell [phone]
www.plasmability.com