In Wireshark traces, I can find a packet which has both 150 and 226 FTP codes. The server is programmed to handle 150 and 226 codes in different packets: the former followed by latter. If both codes are found in a single packet, the server gets confused and skips the data transfer. The packet flow is:
Is this expected behavior? If yes, under what scenario? asked 06 Jul '12, 05:03  vishal edited 07 Jul '12, 22:15  helloworld |
One Answer:
Per RFC 959, "File Transfer Protocol (FTP)", 150 means "File status okay; about to open data connection" and 226 means "Closing data connection." There should be a data transfer in between these two commands, so it would certainly be unusual to have both commands in the same packet. Still, there is nothing in the RFC that forbids it, so I suppose both commands could appear in the same packet if the file being transferred is extremely small or the server for some reason decides to immediately close the data connection. The RFC does require each reply code to be on a separate line. You say the server gets confused and skips the data transfer if both codes are found in a single packet. The server doesn't get confused by these codes; the server is the one sending these codes. The server is not skipping the data transfer because there's both a 150 and a 226 code in the same packet. Rather, there are both a 150 and a 226 code in the same packet because the server has skipped the data transfer. Sounds like your server is misbehaving. The presence of both codes in the same packet is not the cause of the problem, it's a symptom of the problem. answered 06 Jul '12, 08:34  Jim Aragon |
Thanks Jim.
Unfortunately I am new to using FTP at the command level, so I am having trouble understanding everything. So I would spell out all the details for you, as I believe that ways you will be able to help better:
an RETR command is being issued to retrieve data:
::::normal case as from Wireshark traces I have:::::
client->server Request: RETR <file name="">
Request Command: RETR
Request Arg: <"file name">
.
server->client Response: 150 File status Okay; about to open data connection \r\n
Response Code: File status Okay; about to open data connection(150) Repsonse Arg: File status Okay; about to open data connection .
client->server xxxxx > ftp [ACK] Seq=.. Ack=.. Win=.. Len=..
.
server->client Response: 226 Closing data connection. \r\n
Response Code: Closing data connection(226) Response Arg: Closing data connection . xxxxx is some random 5-digit number
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
. .
::::::faulty scenario or precisely "unexpected" scenario:::::::::
client->server Request: RETR <"file name">
Request Command: RETR
Request Arg: <"file name"> .
client->server [TCP Retransmission] Request: RETR <"file name">
Request Command: RETR
Request Arg: <"file name"> .
server->client [TCP Previous Segment lost] ftp> xxxxx [ACK] Seq=.. Ack=.. Win=.. Len=..
.
server->client [TCP Retransmission] Response: 150 Opening Binary mode data for <"file name"> \r \n
Response Code: File status Okay; about to open data connection(150)
Response Arg: Opening BINARY Mode data connection for <"file name">
226 Transfer Complete. \r\n .
client->server xxxxx -> ftp [ACK] Seq=.. Ack=.. Win=.. Len=..
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Can you spot the the reason as to what is going on here in these two scenarios?
Thanks a million in adavnce.
Best Regards Vishal.
It would be far easier, if you upload a sample capture file. You can upload it to cloudshark.org.
HINT: As you cannot delete an anonymously uploaded file on cloudshark.org, you better don't post any private data. Post just those packets in a capture file, that are required to analyze the problem.