Skip to content

Fix: FTP server non-compliance with RFC 959 regarding data connection…#404

Open
pnfd wants to merge 1 commit into
eclipse-threadx:masterfrom
pnfd:fix-ftp-repsonce-code-rfc959-compliance
Open

Fix: FTP server non-compliance with RFC 959 regarding data connection…#404
pnfd wants to merge 1 commit into
eclipse-threadx:masterfrom
pnfd:fix-ftp-repsonce-code-rfc959-compliance

Conversation

@pnfd

@pnfd pnfd commented Jul 14, 2026

Copy link
Copy Markdown

Description

This PR fixes a critical state-machine issue where the NetX Duo FTP server sends the incorrect FTP reply code (250) after closing a data connection, instead of the RFC 959 compliant code (226).

Impact

Standard-compliant FTP clients (e.g., standard Yocto FTP clients, Rust FTP clients) hang indefinitely after downloading a file, uploading a file, or requesting a directory listing. The clients detect that the data connection was closed but wait endlessly for the 226 Transfer complete code on the control channel to properly finalize the transaction.

Root Cause

According to RFC 959:

  • 250 Requested file action okay, completed should only be used when the command does not involve closing a data connection (e.g., RNTO, DELE).

  • 226 Closing data connection must be sent to indicate that a data transfer (like RETR, STOR, LIST, NLST) has concluded successfully and the data port was closed.

In nxd_ftp_server.c, the macro NX_FTP_CODE_COMPLETED ("250") is currently hardcoded for all successful operations, including those that close the data socket (lines processing RETR, STOR, LIST, and NLST).

Wireshark traces clearly show the following sequence:

  1. Data transferred via the data channel.
  2. Server sends TCP [FIN, ACK] on the data channel (closing it correctly).
  3. Server sends 250 File Sent / 250 List End on the control channel instead of 226.

Evidence of Protocol Violation

1. Application Layer (Control Channel)
The server incorrectly replies with 250 instead of 226 after the transfer is done:

227 Entering Passive Mode (10,0,0,27,192,5).
---> LIST
125 Sending List 
drw-rw-rw-  1 owner group          0 JAN 01 00:00 testfolder
-rw-rw-rw-  1 owner group         12 JAN 01 00:00 testdata.txt
250 List End

The Wireshark capture of the corresponding data port shows that the server (10.0.0.27) explicitly closes the socket by sending a [FIN, ACK] (Packet 201), proving that a 226 response was required:

Screenshot from 2026-07-14 09-15-12

Solution implemented

link macro NX_FTP_CODE_LOGOFF correcly if a connection cleanup occurs previously

Replaced the incorrect NX_FTP_CODE_COMPLETED macro in nxd_ftp_server.c for the RETR, STOR, LIST, and NLST command processing blocks.

Operations without data channels (like DELE, RNTO, CWD) correctly retain the 250 response code.

This fully restores interoperability with strict FTP clients.

… closing codes

Signed-off-by: David Penfold <david.penfold@pnfd.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant