Let's skip past the initial setup chatter,
as it is identical to FTP active mode.
Unlike the PORT command, the PASV command is pretty boring.
It's literally just the text string of PASV in the
payload of an FTP signaling packet.
Remember, this is just a request, not a port assignment.
Of greater interest is the 227 response from the server.
The server basically says, I'm ready for your connection on port 40515.
This server reply is similar to the FTP active mode PORT command,
as it contains a comma-separated string of bytes.
The first 4 represent the server's IP address,
and the last 2 combine to form the 2-byte TCP port
on which the server is listening.
I'll show the math in blue in case you'd like to
see how it is computed once more.
Look who initiates the TCP three-way handshake this time.
The client sends the TCP SYN to the server with destination port 40515.
The final ACK from the client means the session is up.
At this point,
the client can issue file transfer commands such as RETR
for a download or STOR for an upload.
Let's quickly examine how a download operation works.
In FTP active mode, once the RETR command was sent,
that triggered the server to initiate a new TCP session.
As seen on the previous slide, the FTP data session is already established,
so issuing the RETR command just triggers the file transfer.
The server has to prepare to send the file in binary mode,
so it reports this in the signaling channel.
Then the 38-byte file is transferred without issue.
I'm showing the file contents at the bottom.
This is the same file we downloaded using FTP
active mode in the previous module.
After some expected TCP chatter to acknowledge the
traffic was successfully transferred,
the server reports that the transfer is complete.
You're probably thinking that passive mode seems much simpler than FTP active mode, and I'd have to agree.