Another UTF8 filename encoding question

[andreasgrab]

Hello,
i have a problem when transfering files with "Umlaut" like öäß in the filename. I use a proftpd 1.3.6 server on debian buster with mod-lang. The filenames get encoded and look wired at the server and the ftp-client also when transfering with filezilla standard setting.
If forcing filezilla client settings to UTF8 it works.

Here the log WITHOUT forcing UTF8:

07:32:59 Befehl: USER testuser1
07:32:59 Antwort: 331 Password required for testuser1
07:32:59 Befehl: PASS **********
07:32:59 Antwort: 230 User testuser1 logged in
07:32:59 Befehl: SYST
07:32:59 Antwort: 215 UNIX Type: L8
07:32:59 Befehl: FEAT
07:32:59 Antwort: 211-Features:
07:32:59 Antwort: 211-AUTH TLS
07:32:59 Antwort: 211-CCC
07:32:59 Antwort: 211-CLNT
07:32:59 Antwort: 211-EPRT
07:32:59 Antwort: 211-EPSV
07:32:59 Antwort: 211-HOST
07:32:59 Antwort: 211-LANG es-ES;ru-RU;fr-FR;it-IT;en-US;bg-BG;zh-CN;zh-TW;ko-KR;ja-JP
07:32:59 Antwort: 211-MDTM
07:32:59 Antwort: 211-MFF modify;UNIX.group;UNIX.mode;
07:33:00 Antwort: 211-MFMT
07:33:00 Antwort: 211-MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.groupname*;UNIX.mode*;UNIX.owner*;UNIX.ownername*;
07:33:00 Antwort: 211-PBSZ
07:33:00 Antwort: 211-PROT
07:33:00 Antwort: 211-REST STREAM
07:33:00 Antwort: 211-SITE COPY
07:33:00 Antwort: 211-SITE MKDIR
07:33:00 Antwort: 211-SITE RMDIR
07:33:00 Antwort: 211-SITE SYMLINK
07:33:00 Antwort: 211-SITE UTIME
07:33:00 Antwort: 211-SIZE
07:33:00 Antwort: 211-SSCN
07:33:00 Antwort: 211-TVFS
07:33:00 Antwort: 211-UTF8
07:33:00 Antwort: 211 End
07:33:00 Status: Der Server unterstützt keine Nicht-ASCII-Zeichen.

See attached log also for full transfer.

The server answers 211-UTF8 as FEATure, so i don't understand why Filezilla complains "The Server does not support non-ASCII char".
The same happens when the server additionaly send "
I can not find a solution on server side, and i do not understand what is wrong.


Thanks for any help
Andreas

[botg]

Broken server, it sends a malformed FEAT response. See RFC 2389:

Code: Select all

   Replies to the FEAT command MUST comply with the following syntax.
   Text on the first line of the reply is free form, and not
   interpreted, and has no practical use, as this text is not expected
   to be revealed to end users.  The syntax of other reply lines is
   precisely defined, and if present, MUST be exactly as specified.

        feat-response   = error-response / no-features / feature-listing
        no-features     = "211" SP *TCHAR CRLF
        feature-listing = "211-" *TCHAR CRLF
                          1*( SP feature CRLF )
                          "211 End" CRLF
        feature         = feature-label [ SP feature-parms ]
        feature-label   = 1*VCHAR
        feature-parms   = 1*TCHAR

   Note that each feature line in the feature-listing begins with a
   single space.  That space is not optional, nor does it indicate
   general white space.  This space guarantees that the feature line can
   never be misinterpreted as the end of the feature-listing, but is
   required even where there is no possibility of ambiguity.

[andreasgrab]

Thank you for the quick answer.
I read the RFC but now i see the problem. Seems to be an regression as it was fixed in proftpd 2006 (http://bugs.proftpd.org/show_bug.cgi?id=2752).

[botg]

I use a proftpd 1.3.6 server on debian buster

Thank you for the quick answer.
I read the RFC but now i see the problem. Seems to be an regression as it was fixed in proftpd 2006 (http://bugs.proftpd.org/show_bug.cgi?id=2752).

Something doesn't seem to be quite right. 1.3.6 got released over 10 years since the bug got fixed in 2006. Are you sure you are actually connecting to the right server?