FTP Server

[chrisgp]

I haven't worked on moving it to the background at all -- based on your other question it looks like you're starting to make some progress on that which is awesome.

[Roberthh]

Actually I did. It works now with standard FTP programs, like ftp, filezilla and fireftp, and Firefox & Chrome. The file managers behave a little bit strange, mostly because they seem to cache the servers content. The only file manage that seems to work is Windows File explorer (!).
For the implementation, I used your utelnetserver.py as template. It still requires cleaning & straightening, but at least it's a good alpha.

uftpd.zip

(2.66 KiB) Downloaded 305 times

[pythoncoder]

Nice work! Along with the Telnet server http://forum.micropython.org/viewtopic.php?f=16&t=2478 it makes an effective alternative to the Webrepl. Remarkably light on RAM too.

[Roberthh]

Just the update of the day. I should open a git repo for it. Wasted a few hours in trying to find the reason for nautilus' strange behaviour, w/o luck. There is no substantial change in the code, even if many lines are changed. Here are the changes:

• ls pattern: the comparison is now case insensitive
• starting: the uftpd.start() call has now two parameters: port = 23 and verbose = 0. The latter controls the amount of debug prints

Observations:

• The background version responds much faster than the foreground version.
• Nautilus behaves strange. Most of the times it falls into a loop, where it constantly reconnects. The server stays stable. If I stop nautilus' attempts and start ftp, the server works fine.
• Mac OS X's finder also behave strange. Even if the mode is set to passive, it sometimes tries active connections, and sometimes it even connects fine.

So for the moment, just ignore nautilus and finder. The dedicated ftp clients work well with this little server,

uftpd.zip

(3.13 KiB) Downloaded 279 times

[Roberthh]

Catch of the day. No functional changes, just attempts to make it more robust under various clients.
Access with Nautlilus now works, OS X Finder is still flaky. Sometimes it works, sometimes not.
There are still some rough edges.

• If you open one seesion with ftp, and another session in a second window, this second session blocks, instead of being rejected immediately. Even if you close the first session, the second one stay in a zombie state and blocks other connection attempts. In that case, you either have to restart the ftp server, or just wait for the 5 minutes timeout.
• Clients which do not terminate clean (with a QUIT command) could still be a problem. Among these clients are Nautilus, Windows Explorer, Thunar, Firefox, and others. Thunar and Firefox do not seem to be a problem, and most of the time also Windows Explorer behaves well. Dedicated ftp clients like ftp, FileZilla or FireFtp work reliably. Thunar also never showed problems in testing.

uftpd.zip

(3.41 KiB) Downloaded 244 times

[Roberthh]

For now it looks OK. There is a repository now for it at https://github.com/robert-hh/MicroPython-FTP-Server.
The use with Nautilus is not always smooth, but at least stable. It looks more to be a problem of debian Nautilus. Like before, dedicated FTP clients work well, besides windows' ftp client. For those who do not want the get the GIT repository: here is the zip file.

uftpd.zip

(5.02 KiB) Downloaded 288 times

[Roberthh]

Another update: The server now accepts several clients, as long as only one is active at a time. That solves the issues with most of the clients. Nautilus now seems robust, Dolphin and Konqueror too, and FileZilla can be used from the quick connect bar. Mac OS X finder is still not working. Also clients which forget to release all sessions, like Windows explorer, are now less of a problem.
The package is at https://github.com/robert-hh/ESP8266-FTP-Server or here, but the git repository may be more up-to-date.

uftpd.zip

(10.21 KiB) Downloaded 276 times

[warren]

Another update: The server now accepts several clients, ....

Thank you for this work. Unfortunately I get an error when I use Filezilla on Ubuntu:

Output from uFTPd server (verbose = 2):

Code: Select all

FTP server started on 192.168.4.1:21
>>> FTP connection from:('192.168.4.2', 33178)
Command=USER, Payload=anonymous, Path=/anonymous
Command=PWD, Payload=, Path=/
Command=TYPE, Payload=I, Path=/I
Command=PASV, Payload=, Path=/
Command=LIST, Payload=, Path=/

Filezilla messages:

Code: Select all

Status:	Connecting to 192.168.4.1:21...
Status:	Connection established, waiting for welcome message...
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/"
Command:	TYPE I
Response:	200 OK
Command:	PASV
Response:	227 Entering Passive Mode (0,0,0,0,52,21).
Command:	LIST
Error:	The data connection could not be established: ECONNREFUSED - Connection refused by server
Response:	550 Fail
Error:	Failed to retrieve directory listing

Any suggestions?

[Roberthh]

Hello @warren,
actually filezilla never made any problems. Try the attached version, which I just pulled from the github site https://github.com/robert-hh/ESP8266-FTP-Server, which is more recent. What I see that the IP address in the PASV response is 0.0.0.0, when it should be 192,168,4,1. I'll try this night with my setup and your IP addresses. With the actual version, you can also use active mode.

uftpd.zip

(6.71 KiB) Downloaded 301 times

[warren]

Try the attached version, which I just pulled from the github site

Thanks for the fast reply.

Initially I got the same error (ECONNREFUSED). But then I looked at the other settings in Filezilla and set the "Tranfer settings" tab to "Active" (from "Default")...

it works like a charm - thank you so much. It's a very useful addition...

There is just one behaviour that would be great if it could be suppressed:

I import uftpd in main.py - at that point the FTP server binds to 192.168.4.1 as you would expect.

Some time later, the ESP module associates with my AP, and gets an i/p address of 192.168.103.125

At this point the FTP server generates a new message saying it is now serving files on this new address (and no longer on the 192.168.4.1). This is what I see in my REPL:

Code: Select all

FTP server started on 192.168.4.1:21
FTP server started on 192.168.103.125:21

Can it be fixed so that it does not reassign the FTP address?