Closed svet-b closed 1 year ago
The server must respond 234 to AUTH command as stated in the RFC https://www.rfc-editor.org/rfc/rfc4217. In particular, this section https://www.rfc-editor.org/rfc/rfc4217#section-12.1 explains the flow and the 234 response makes the client start the TLS negotiation.
Could it be the server actually doesn't support TLS?
Yeah I suspected the server's behavior is not standards-compliant. And am not surprised, given the nature of the device.
The server does support FTPS - in fact it requires a secure connection - and as I mentioned, I'm able to access data using wget
(with an ftps://...
URL), and it doesn't seem to complain. But I guess the wget
is more lenient towards behavior like this.
Anyway, I was able to work around this using an implicit FTPS connection on another port, which seemed to work without issue (thanks also for the help there!). So on balance, I wouldn't steer you towards accommodating for pathological behavior like this :). Will go ahead and close this.
I'm connecting to an FTP server on an industrial device. In the course of setting up TLS, the following exchange takes place:
Unfortunately at that point the
suppaftp
client raisesUnexpectedResponse
, since it expectsStatus::AuthOk
(234) rather thanStatus::CommandOk
(200) - based on https://github.com/veeso/suppaftp/blob/main/suppaftp/src/sync_ftp/mod.rs#L141.Not quite sure what to make of that. It's entirely possible that the server is just not spec-compliant. But it would be good to find a way to establish the connection nonetheless. FWIW,
wget
connects fine and doesn’t seem to complain. Any thoughts? Maybe I’m just connecting improperly in some way?