No files visible connecting via FTP on 3.6.0-beta.4

Triet

@chrishamm Now I am a step further. It was the Windows firewall. It poped up at some time warning me. So I enabled ftp connections in the local network and retried:

C:\WINDOWS\system32>ftp myduet
Connection with myduet.fritz.box established.
220 RepRapFirmware FTP server
500 Unknown login command.
Benutzer (myduet.fritz.box:(none)): anonymous
331 Please specify the password.
Kennwort:
230 Login successful.
ftp> ls
500 Unknown command.
500 Unknown command.
ftp>

WinSCP is still complaining about unknown command and not showing any files.

Do we have an issue here on the server side?

droftarts

@Triet I've updated the Gcode dictionary M586 notes section with how to connect via FTP, using FileZilla:

To connect via FTP, use an FTP client such as FileZilla. In FileZilla, create a 'New site', give it a name, then set the 'Host' to the Duet's IP address or .local hostname. Set 'Logon Type' to 'Anonymous', and in 'Transfer Settings' check 'Limit number of simultaneous connections' and set 'Maximum number of connections' to 1. Then connect.

I haven't tried the Windows ftp client, but it may not be possible to limit the number of connections. I can't connect to the Duet FTP using the macOS finder, either, but FileZilla does work.

Ian

chrishamm

@Triet I don't think the Windows ftp utility supports that setting but I think WinSCP does, although it's been a while since I used it. AFAIR it's this bit in Options -> Preferences -> Transfer -> Background:

If that doesn't work, I suggest you try out FileZilla Client with the setting @droftarts mentioned.

Triet

@chrishamm I had already found the appropriate settings for WinSCP, but nothing changed.

What I did: Installed latest 3.6.0-rc.1, installed Filezilla, configured Filezilla as indicated, explicitely configured the Windows Firewall to allow both clients to connect in the LAN.

Nothing changed but... after many attempts I have noticed that at times DWC loses connection, exactly after an FTP connection attempt. The PanelDue shows a flashing message like "lost WiFi connection ... SPI timeout". The DWC does not seem to like those FTP connections.

To be sure I have reset the network password (the same), disabled and reenabled FTP, and at times, I have tried to restart the board using M999 to have a clean start... but guess what, it just shuts down and must be manually started again. That is not how it is supposed to be.

Something is not clean here, I cannot still exclude myself

My Duet 2 WiFi is a client with a fixed IP in the local LAN, so I am not using a direct connection to its own SID, but through my router, as it should normally be. I will check that the router is not blocking anything, but normally it shouldn't.

chrishamm

@Triet Did you upgrade the WiFi server firmware as well?

Triet

@chrishamm I installed the package Duet2and3Firmware-3.6.0-rc.1.zip, I looked into it and it contains a file DuetWiFiServer.bin. The version shown for the WiFi Server is 2.2.1 - it should be OK.

Triet

@chrishamm I came back and retried after a couple of hours and I could connect both using the Windows ftp client (as a mere comparison check) and Filezilla. WinSCP still shows the same issue: connection takes place, but no file list visible ("unknown command"), even after retrying different connection options.

This all makes no sense to me. I did not change anything, just switched the printer on again and retried.
I had done that before without success, now I feel quite annoyed as I am afraid FTP might fail again soon. Results have been erratic, causing the Duet board to freeze, reboot, shutdown or lose connection. Reading similar cases tend to confirm the precarious character of the FTP protocol in Duet boards. FTP failing during transfers is not healthy at all, might lead to corruption. We will see.

I have setup many sorts of file transfer connections in my life (scp, ftp, ssh, rsync and what not) in all kinds of environments (virtual machines, Solaris, Sinix, different Linux versions, emulation subsystems) across several servers simultaneously, using network tunneling, going through firewalls, proxy servers, using automated scripts, with and without encryption... seldom needed longer than 5 min. Only server setup has demanded more attention due to security considerations. But this time, it took me several hours and I am not sure that I have a stable FTP connection. And yet FTP is so simple.

What a shame.

Triet

@chrishamm Just half an hour later... FTP is failing again (using Filezilla). Same symtoms: session is established, but no file list is visible.

I switched diagnostics on using M929 P"0:/sys/eventlog.txt" S3 and found:

2025-03-20 02:16:35 [warn] Error: WiFi module reported: Listen failed

But I am not sure that this is related to the issue.

Filezilla reports:

Status:	Connecting to 192.168.178.52:21...
Status:	Connection established, waiting for welcome message...
Status:	Plain FTP is insecure. Please switch to FTP over TLS.
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Retrieving directory listing of "/sys"...
Command:	CWD /sys
Response:	250 Directory successfully changed.
Command:	TYPE I
Response:	200 Switching to Binary mode.
Command:	PASV
Response:	227 Entering Passive Mode (192,168,178,52,107,46)
Command:	LIST
Error:	The data connection could not be established: ECONNREFUSED - Connection refused by server
Response:	425 Failed to establish connection.
Error:	Failed to retrieve directory listing

Please note the error message "data connection could not be established". As far as I remember, FTP uses two channels, one for control commands and one for data transfers. The error is triggered as the requested directory listing would be transfered. The session as a whole is still alive, but only the command channel is working. Perhaps we should allow two connections at least (but still for one session).

Now, I have been using three different FTP clients, all of them play back the same thing: The server cannot handle the LIST (ls) command, because it needs a second channel for data transfer. My conclusion is that we are dealing with a spurious server behaviour.

I will still try to reconfigure the FTP client and will report the outcome, but read carefully: "Connection refused by server". That I cannot change.

Now, read my lips please: Your FTP implementation needs to be revised, really.

Triet

@chrishamm I found in
https://forum.duet3d.com/topic/28833/possible-ftp-upload-problem/17
that you already provided a fix to this FTP issue here: https://pkg.duet3d.com/RRF-3.4.1plus1.zip

Is this fix included in the current RC version?

Triet

@chrishamm Preparing for a new debugging session, today I retried Filezilla... this time it worked fine (showing all files).
I just started the printer, nothing else.
Crazy.
How to fix an intermitent issue, that's a new problem.