FTP problem - Restart position > 0 not accepted in ASCII mode

Hello! o)

I guess because I updated the FTP app on my Android phone some time ago, I introduced some kind of incompatibility with DO. Connecting to the Anroid-SwiFTP was working quite ok some time before that update or before I updated DO the last time.

I double checked with FileZilla to see if it's a general problem, but FileZilla is able to connect just fine.
Maybe you have an idea what goes on here? This is the FTP-log with the "Debug" checkbox enabled in the FTP address book entry - all other settings at default.

Opening Connection 192.168.0.107:2121
220 SwiFTP 2.15.0 ready
--> USER xxxxxxxxxxxxx
331 Send password
--> PASS ...
230 Access granted
--> SYST
215 UNIX Type: L8
--> FEAT
211-Features supported by FTP Server
 UTF8
 MDTM
 MFMT
 MLST Type*;Size*;Modify*;Perm
211 End
--> OPTS MLST type;modify;size;perm;
200 MLST OPTS Type;Size;Modify;Perm;
--> OPTS UTF8 ON
200 OPTS accepted
--> REST 100
200 OPTS accepted
--> TYPE A
550 Restart position > 0 not accepted in ASCII mode
--> ABOR
200 ASCII type set
502 Command not recognized
--> ABOR
502 Command not recognized
Connection closed

Thank you! o)

This part of the log looks odd to me:

--> OPTS MLST type;modify;size;perm;
200 MLST OPTS Type;Size;Modify;Perm;
--> OPTS UTF8 ON
200 OPTS accepted
--> REST 100
200 OPTS accepted

The after two OPTS commands, the server responds to the REST 100 command (used to check if the server supports resuming) by saying OPTS accepted. That response doesn't make sense, and may be causing Opus to assume the server does not support resuming (and thus it would not make sense to sent REST 0 to reset the resume position).

If resume is supported, the server should return a 350 response, assuming this RFC is still up to date: https://tools.ietf.org/html/rfc3659#page-13

What does the FileZilla log look like?

So you mean it's more likely that SwiFTP does something weird? If yes, I will try to contact the author of SwiFTP next.
FileZilla looks like this, no sign of some "REST 100" command it seems.

15:31:45	Status:	Verbindung zum Server getrennt
15:31:45	Trace:	CFtpControlSocket::ResetOperation(66)
15:31:45	Trace:	CControlSocket::ResetOperation(66)
15:31:45	Status:	Verbinde mit 192.168.0.107:2121...
15:31:45	Status:	Verbindung hergestellt, warte auf Willkommensnachricht...
15:31:45	Trace:	CFtpControlSocket::OnReceive()
15:31:45	Antwort:	220 SwiFTP 2.15.0 ready
15:31:45	Trace:	CFtpControlSocket::SendNextCommand()
15:31:45	Befehl:	AUTH TLS
15:31:45	Trace:	CFtpControlSocket::OnReceive()
15:31:45	Antwort:	502 Command not recognized
15:31:45	Trace:	CFtpControlSocket::SendNextCommand()
15:31:45	Befehl:	AUTH SSL
15:31:45	Trace:	CFtpControlSocket::OnReceive()
15:31:45	Antwort:	502 Command not recognized
15:31:45	Status:	Unsicherer Server; er unterstützt kein FTP über TLS.
15:31:45	Trace:	CFtpControlSocket::SendNextCommand()
15:31:45	Befehl:	USER xxxxxxxxxx
15:31:45	Trace:	CFtpControlSocket::OnReceive()
15:31:45	Antwort:	331 Send password
15:31:45	Trace:	CFtpControlSocket::SendNextCommand()
15:31:46	Befehl:	PASS *******
15:31:46	Trace:	CFtpControlSocket::OnReceive()
15:31:46	Antwort:	230 Access granted
15:31:46	Trace:	CFtpControlSocket::SendNextCommand()
15:31:46	Befehl:	OPTS UTF8 ON
15:31:46	Trace:	CFtpControlSocket::OnReceive()
15:31:46	Antwort:	200 OPTS accepted
15:31:46	Status:	Verbunden
15:31:46	Trace:	CFtpControlSocket::ResetOperation(0)
15:31:46	Trace:	CControlSocket::ResetOperation(0)
15:31:46	Trace:	Measured latency of 4 ms
15:31:46	Status:	Empfange Verzeichnisinhalt...
15:31:46	Trace:	CFtpControlSocket::SendNextCommand()
15:31:46	Trace:	CFtpControlSocket::ChangeDirSend()
15:31:46	Befehl:	PWD
15:31:46	Trace:	CFtpControlSocket::OnReceive()
15:31:46	Antwort:	257 "/"
15:31:46	Trace:	CFtpControlSocket::ResetOperation(0)
15:31:46	Trace:	CControlSocket::ResetOperation(0)
15:31:46	Trace:	CFtpControlSocket::ParseSubcommandResult(0)
15:31:46	Trace:	CFtpControlSocket::ListSubcommandResult()
15:31:46	Trace:	CFtpControlSocket::ResetOperation(0)
15:31:46	Trace:	CControlSocket::ResetOperation(0)
15:31:46	Status:	Anzeigen des Verzeichnisinhalts für "/" abgeschlossen

Looks like FileZilla isn't testing for resume support. Maybe it only checks it when it needs to instead of on connection.

I would ask the server authors if there's a reason they return a 200 status instead of 350 after the REST command is sent, and show them the log. The response indicating an OPTS command after something else is also worth mentioning. Maybe the sequence of commands is putting the server into a confused state for some reason.

Thanks Leo. o) I read some FTP-specs (ohdear o) and wonder why DO sends "REST 100" in the first place?
Is it required to fetch the list of items? I mean upon connecting, I did not send a or receive a file yet.

DO also seems to send the "REST 100" command even though the transfer mode has been set to binary. In ASCII mode, resuming seems to be not supported officially (encoding/positioning issues), so I wondered again, why the REST command shows up.

No offense, just trying to understand better. o)

If the server doesn't specify that it supports resuming, Opus issues the command to find out if it does another way.

Opus needs to know in advance so it can know whether or not to offer the Resume option on downloads.

The next version should connect OK (I've added special handling for SwiFTP), please try it and let me know how it goes.

Some decent additions coming up in the next version, looking forward to it!
I will report back on the SwiFTP issue, thank you! o)

Hi Jon, your fix does the job!
I only copied a couple files to the smartphone, but had no issues so far! Thank you! o)

1 Like