FTP: a deeper look at a 'Passive' file transfer

Body

With ftp we can do a PASSIVE file transfer.  In most cases it's just the adding of a parameter in our bpml to switch.   It may be that we don't need to add anything because the default setting is just fine.  

A PASSIVE file transfer is one where the ftp client will request, by the PASV command, that the ftp server tell it what port it is listening on.  Then the ftp client will initiate opening the data connection to that specified port.  The ftp server will do this by sending a "227 entering Passive Mode" message to the client.  In this 227 message is the ip/port to connect to.

So what happens when we do an Passive file transfer?  

Hopefully this blog will visually show you what happens during an PASSIVE file transfer.  

ACTIVE is handled in another blog.

The FTP client used in this blog was IBM Sterling B2B Integrator.

The bpml used was simple:

FTP Client Begin Session Service
FTP Client LIST service
FTP Client End Session service

Below is the pretty typical Status Report one would find for the FTPClientBeginSession Service:

Below is the Status Report from the FTPClientList Service:

Finally, below you will find the status Report from the FTPCientEndSession Service:

Everything above is what we typically see during a ftp session within SBI and I would guess, to an extent, from most ftp client applications. 

Now lets take a look at the packet level, with Wireshark, for the same ftp session.

Take note of the responses that show in our status report and all the responses and activity that happens behind the scenes in the tcp and ftp protocol.

The FTP Client is ip addr: 9.99.99.33 and the FTP Server is 9.99.9.88.

We can see the Source (Sender) and Destination (Receiver) columns.

We also see that this packet capture starts with packet number 1138.

1 - 3. We can see the 3-part tcp handshake. The client sends a SYN, the server responds with a SYN,ACK, then the client responds with ACK.  This is tcp protocol and it established a connection between the client and server.

- After the connection is made (3-part handshake), in packets 1166 and 1168 you can see the client sends his logon information.

4 -The FTPClientList Service was set to default which is an Passive file transfer.  This is seen by the PASV command being sent by the client in packet 1178.

- The response back from the server is: 227 Entering Passive Mode (9,99,99,88,214,137) This is the way the server tells the client what port the server will be listening on for the client to reach out to it for the data connection.

- (9,99,99,88,214,137) these 6 numbers following in the servers response break down as follows:

First 4 are the ip address: 9.99.99.88 

The fifth and sixth numbers are the port. You take the fifth number multiply it by 256 then add the sixth number:

214 * 256 = 54784 + 137 = 54921

So the servers response is telling the client that it is listening at the ip/port of 9.99.99.88:54921***

- The client sends the LIST command to the server, we see this in packet 1186.

5 - In packet 1187 we see the Server responding with "150 Opening ASCII mode data connection."

6 - Notice the gap in the packets after packet 1180 and 1187?  This screen shot is filtered by the tcp connection between client ip/port <=> server ip/port.

With the PASV command we have a new set of ports to deal with.  These missing packets are below:

*** Above you can see the client, 9.99.99.33, from port 43512, has reached out to the server 9.99.9.88 on port 54921.

The 3 part handshake is established, packets 1181-1183.

The list is sent to the client in packet 1188 (maybe in 1189?).

Then 1191-1192 is this tcp connection closing down initiated by the client because they received the data.

NOW BACK TO THE OTHER SCREEN SHOT

- In packet 1193 we pick back up with the ftp session.

- In packet 1194 we see the server sending the message that the list was transferred (226 Transfer complete)

7 - The client sends the quit command to end the ftp session in packet 1196.

- In packet 1199 we see the response from the server to the clients quit command.

8 - Finally we see the actual tcp tear-down of the connection.  Very similar to what happened to the data connection in packets 1202-1204.