Is an FTP error (503 Bad sequence of commands) the result of a client issue or a server issue

11,034

The client sends the PASV command to initiate another file transfer before waiting for the previous transfer (the STOR command) to be finished (226 response):


The first transfer starts:

> PASV
< 227 Entering Passive Mode (54,79,122,6,195,141)
> STOR media/UV1358A_4.jpg
< 150 Opening data channel for file upload to server of "/media/UV1358A_4.jpg"

The PASV command for another transfer before the first transfer finished:

> PASV
< 227 Entering Passive Mode (54,79,122,6,195,136)

The first transfer finishes only now. The filename in the message is missing, because the FileZilla Server resets a file transfer data (including the file name) upon processing of the out-of-order PASV command (it actually should have better rejected the PASV command already with the 503).

> 226 Successfully transferred ""

A request for the another transfer. It fails because the FileZilla server forgets the out-of-order PASV command upon completion of the first file transfer.

> STOR media/UV1358A_5.jpg
< 503 Bad sequence of commands.
Share:
11,034
Ads
Author by

Ads

BY DAY: I try to stay out of trouble and not break too many things. BY NIGHT: I do the same

Updated on June 22, 2022

Comments

  • Ads
    Ads almost 2 years

    I have an FTP server running on an AWS virtual server. We have about 100 users connecting to it over the course of a day, uploading images and other files. All but one are working perfectly. Files come in, not a problem.

    We have 1 single user that causes the following log lines to be generated - the username and IP has been removed intentionally and the "***" has been added to highlight the error line:

    > 227 Entering Passive Mode (54,79,122,6,195,96)
    > STOR media/UV1358A_3.jpg
    > 150 Opening data channel for file upload to server of "/media/UV1358A_3.jpg"
    > 226 Successfully transferred "/media/UV1358A_3.jpg"
    > PASV
    > 227 Entering Passive Mode (54,79,122,6,195,141)
    > STOR media/UV1358A_4.jpg
    > 150 Opening data channel for file upload to server of "/media/UV1358A_4.jpg"
    > PASV
    > 227 Entering Passive Mode (54,79,122,6,195,136)
    > 226 Successfully transferred ""
    > STOR media/UV1358A_5.jpg
    ***********************************************
    > 503 Bad sequence of commands.
    ***********************************************
    > PASV
    > 227 Entering Passive Mode (54,79,122,6,195,80)
    > PORT 122,99,115,5,212,227
    > 200 Port command successful
    > PORT 122,99,115,5,226,227
    > 200 Port command successful
    > PORT 122,99,115,5,130,124
    > 200 Port command successful
    > STOR media/UV1358A_9.jpg
    > 150 Opening data channel for file upload to server of "/media/UV1358A_9.jpg"
    > PORT 122,99,115,5,152,62
    > 200 Port command successful
    > STOR media/UV1358A_10.jpg
    > 150 Opening data channel for file upload to server of "/media/UV1358A_10.jpg"
    > PORT 122,99,115,5,161,49
    > 200 Port command successful
    

    We're using FileZilla Server 0.9.55 on a Windows 2012 box.

    My question, as stated in the title is essentially.. Is this our issue on the server end, or is this theirs? Is this 503 error always caused by the FTP client screwing something up or is there the possibility that the FTP server is interpreting something wrongly?

    I'm happy to go back to the customer and say "It is our issue", but I suspect it's not at our end.

    Thanks

  • Ads
    Ads about 8 years
    Thanks Martin for the detailed response. The customer says they're using PHP's in-built FTP library. I'm going to go out on a limb here and say that they are just using a single threaded loop to process the files to upload. They've already said that they upload files to hundreds of other customers' ftp servers without a hitch and we're the only troublesome one and so they won't do any debugging at their end to try and fix the issue.
  • Martin Prikryl
    Martin Prikryl about 8 years
    The PHP FTP library won't protect you from violating the protocol in the described way, if you use a non-blocking API (ftp_nb_fput). I was able to reproduce this easily. Using multi-threaded code would likely reproduce this too, though I didn't try it.
  • Martin Prikryl
    Martin Prikryl about 8 years
    Aren't you geographically close to the customer? That might cause the difference to the other servers. If a latency is low, chances for a race condition like this increases.
  • Ads
    Ads about 8 years
    Martin, I have no idea where their servers are vs our servers. Ours are in AWS and looked after by someone else so I'm not sure of the physical location, but really it "shouldn't" matter should it? Either way, I'd argue it's the responsibility of the ftp client (or site code) connecting to the server to send the various commands in the correct order, irrelevant of framework. That's really what I'm getting at with the original question. :-)
  • Martin Prikryl
    Martin Prikryl about 8 years
    Sure, it shouldn't matter. I'm just trying to suggest how is it possible that the probable client bug manifests with your server only.
  • Ads
    Ads about 8 years
    yeah.. no worries. Thanks for your help, your answer was very insightful.