Odd connect retry behavior

I use quick schedule a fair bit for one time manually created tasks and have noticed that if there is a problem connecting flashfxp does not try to reconnect as would be expected. It tries, fails, does nothing.

For me the connection failure happens sometimes when my identd server fails to respond quickly enough. (I use an external service to avoid application level interference)

I seem to recall inconsistent connect retry behavior when launching via cli as well... if i open up a launched session when I see it has not connected sometimes i see the 'Delaying for 120 seconds before reconnect attempt' message and sometimes i do not. (launched with the exact same command)

Global preferences: timeout 40 delay 120 count 10, per site options not turned on.

Doing some testing (turned off identd service) I noticed the following behavior... I assume the 0 delay between each entry in the sites dns/ip list is intentional but is the shorter 10 second delay after the first set of attempts (instead of 120) also intentional?

[18:52:23] [L] Connecting to... (ip 1)
...
[18:52:24] [L] PASS (hidden)
[18:52:24] [L] 530 "..." is not valid for the account specified.
[18:52:24] [L] Connection failed (Connection closed by server)
[18:52:25] [L] Connecting to... (ip 2)
...
[18:52:32] [L] PASS (hidden)
[18:52:33] [L] 530 "..." is not valid for the account specified.
[18:52:33] [L] Connection failed (Connection closed by server)
[18:52:33] [L] Delaying for 10 seconds before reconnect attempt #1
[18:52:43] [L] Attempting to Reconnect.
[18:52:43] [L] Connecting to... (ip 1)
...
[18:52:50] [L] PASS (hidden)
[18:52:50] [L] 530 "..." is not valid for the account specified.
[18:52:50] [L] Connection failed (Connection closed by server)
[18:52:51] [L] Connecting to... (ip 2)
...
[18:52:58] [L] PASS (hidden)
[18:52:58] [L] 530 "..." is not valid for the account specified.
[18:52:58] [L] Connection failed (Connection closed by server)
[18:52:58] [L] Delaying for 120 seconds before reconnect attempt #2

Are there some conditions for connection retries here that I am unaware of?

build 3795 can't update yet as I have some stuff running.

There are a few factors that determine the retry delay.

If the connection is unexpectedly lost then FlashFXP will immediately retry and if that fails then the retry delay increases to 10 seconds, if that fails then to uses the user defined value.

Certain error messages during login are classified as critical (based on the server reply code) i.e invalid username or password and in these cases FlashFXP does not automatically retry.

In the session log you included based on these conditions that would be the correct behavior.

[18:52:58] [L] PASS (hidden)
[18:52:58] [L] 530 "..." is not valid for the account specified.

A 530 numerical code in the reply to PASS command is retried.. However if the 530 numerical code was returned after the USER command it would not be retried.

Since you indicate that the behavior is inconsistent check the logs and see if you can determine if anything is different, such as a different reply code or the order of events.

Thank you for the information, you are right this is related to WHEN the server is verifying ip/identd/etc. The servers in question are verifying source credentials on USER while the others are verifying on PASS. No standardization for this kind of thing in any of the FTP RFC's that I could find so I guess its up to the server, though technically speaking it is probably better that this verification is done as soon as possible and given that host restrictions are tied to each user name doing on USER is appropriate (and further enhances security by not needlessly sending the password). Though I am guessing the reason some do it on PASS is precisely because it allows an RFC compatible retry.

What is the FTP server software? I'd be interested in testing it.

What is the exact 530 reply from this FTP server (minus any personal info)?

The RFC defines a strict standard but sometimes things need to be tweaked or extended to provide additional features or functionality or to work around certain problems that have come up after the RFC was defined and this is where things get very complicated.

The problem is that since there is no global index of defined server replies many FTP servers use the same reply codes for different types of errors and when they overlap it makes it difficult to determine how it should be handled.

For example drFTPD may send a 530 reply to the USER command if the user connects via plain FTP and the server requires a secure connection.

In your specific case it would make sense to retry the connection attempt, so if I can detect the FTP server software and match the reply for a specific condition then I can adjust this behavior.

The servers in question are DrFTPd 3, and the exact reply is below, for any failure to match ident@ip to the user specified.

530 "*@1.1.1.1" is not valid for the account specified.

If I had the time I would look into writing a patch for drftpd because I feel it is in fact misplaced and inefficient for these checks to be done on PASS instead of USER. (not that anybody active has commit access to the project right now)