FTP Mainflow RETR Command with PWD on server side
This message flow is intended to generate simple IPv4 FTP traffic between the MN and the Network Host node. The flow simulates an FTP session that retrieves a file from a server using passive mode while traversing a proxy device. The flow is intended to generate simple FTP traffic between the MN and the Network Host node.
This flow is also a good example of using a command to listen for and respond to a request from an external device. The PWD request is included in this flow and is assumed to be issued by the Proxy — see the FTP Mainflow Active EPRT Command message flow for an example that uses PWD without a Proxy.
When control plane protocols are used, the initial TCP connection for the FTP control messages is established after Data Start Delay timer expires. The MN initiates the TCP connection, using the Client Port and Server Port defined in the message flow.
-
The server begins the message sequence by notifying the client that it is ready to receive requests.
-
The client issues a USER request to begin the login, and the server responds with a request for the password.
-
The client responds with a PASS and the password, and the server responds with a confirmation that the login succeeded.
-
In this step, the command instructs the server to respond to a PWD request. The PWD request can come at any time during the flow, and the server will respond with the defined message. In this example, the Proxy issues the PWD after receiving the RETR request from the client (see step 6).
-
The client issues a PASV request to force the server into passive mode. The server responds with the IP address and port on which it will listen for a TCP connection from the client for the data transfer.
NOTE: The IP address and port included in the server response can be defined in the response message as shown in the diagram. This information, however, will be overwritten during test execution by the IP address of the Network Host and the Server Port defined in the subflow.
-
The client issues a RETR request to begin the file retrieval. Before relaying the RETR to the server, the Proxy issues a PWD and the server responds with the current directory. It is assumed that the client is presented with the correct directory at login. On receipt of the server response, the Proxy issues the RETR to the server, which responds with a confirmation.
At this point in the message flow, the FTP Data Transfer Subflow is executed. It establishes the TCP connection for the data transfer using the ports defined in the subflow (see step 5), and sends one 78 byte packet to the client: a payload of 76 Zs terminated with a CR-LF pair. The mainflow waits for a TRANS_COMPLETE event from the subflow, indicating that the subflow transaction completed, before continuing.
-
The server notifies the client that the transfer is complete, and that the data connection will be closed.
The Stop Subflow control is inserted at this point to release the TCP connection used for the data transfer.
-
The client issues a QUIT request to terminate the control session, the server responds with a confirmation, and the initial TCP connection is closed.
In the default configuration, the message flow will repeat once per second while the MN session is active. This assumes that the entire flow can be completed in one second. The flow must complete before the next iteration can begin, even if this results in a slower transaction rate.
Modifying the Message Flow
Since FTP is a text-based protocol, you can easily modify the request and response messages. You can also modify the data transfer payload or import a file to be used in the data transfer.
You can specify that random port numbers, in the IANA specified dynamic range of 49152 — 65535, be used by the client for the FTP control session by entering a 0 for the Client Port. Random port numbers can be used for both the client and server in the FTP Data Transfer Subflow.