Windows 10 kills connection on "227 Passive mode ..." messages

[Cols]

I build an embedded FTP server and talk to it with a Windows 10 computer.

Strange finding:
When the FTP server sends a "227 Passive mode (192, 168, 0, 73, 208, 190)" , Windows 10 terminates the connection ! Just out of the blue. Allways.
When the FTP server sends a "227 Passive mode (192,168,0,73,208,190)", - thus no blanks - the connection remains alive.

This seams to be related to Windows 10 and not to FileZilla, still thought this might be interessting to you all.
Firewall is off, Windows 7 does not show this behaviour.

Basically - Windows 10 reads the traffic on this connection and messes with TCP connections, even though firewall is off. This is bad, very bad.

Can anybody confirm ?

[botg]

Are you sure the firewall is off? Windows 10 has the habit of re-enabling everything you disable on its own.

Note that the spaces in the PASV reply in violation of the FTP specifications.

[AndreasKretzer]

This thread started a while ago, but I can confirm the behavior.
It's not related to FileZilla, but to Win10 (I currently have no older version anymore, so it
is unclear, when this "bug" was introduced).

When you start a PASV session and get the answer "227 foobar (h1,h2,h3,h4,p1,p2)CRNL"
Windows will send a RST packet and the connection closes. This happens regardless of
an active or inactive firewall, with or without a virus scanner.

I checked that with an embedded FTP-server, a command line telnet and Wireshark.
If you, for example, change the answer code to 228 nothing will happen. On the other
hand, sending the answer in multiple small packets doesn't help at all! Windows interprets
the answer if it comes from port 21 and starts with answer code 227 (I tried port 31 and
everything was fine).

So Windows ist definetely the one to blame!

Andreas

[AndreasKretzer]

Ha! Got you!

My previous reply is still (almost) valid. Win10 does(!) interpret the ftp communication.
But it also checks the answer for validity. When implementing my FTP Daemon on my
embedded system (FreeRTOS + lwIP) I came across the following site:
https://cr.yp.to/ftp/retr.html where the author recommended to use the
following answer to a PASV request: 227 =h1,h2,h3,h4,p1,p2

This is a bad idea when accessing this ftp server from windows
The correct way is: 227 =(h1,h2,h3,h4,p1,p2) <-- use of parantheses '(' and ')'.
This way, windows is happy and acknowledges the packet.

Still I think, this bad behavior! Why would windows not allow me send a packet with
whatever contents from whatever port (if we have an established connection)? OK,
maybe that's necessary for some ftp connection tracking inside the firewall. But
it would have been better to accept this and ignore the information in this packet,
possibly leading to a denied data connection on the advertised port.

So, I'm a little bit pissed off by windows

Maybe we now can close this subject ...

Andreas

[boco]

The response to PASV is indeed not standardized (see also section 4.1.2.6 here).

@botg: Maybe FileZilla should switch to using EPSV/EPRT whenever possible (supported by the server)? EPSV, EPRT and their responses are fully standardized IIRC. Currently, EPSV/EPRT is mandatory only for IPv6, but you CAN use it for IPv4, also.

[botg]

I suppose this could be done if the server advertises EPSV support. Sadly the EPSV RFC does not say how support for it should be advertised.

[boco]

Response: EPRT
Response: EPSV

The one I use does. FileZilla Server does, likewise. For the odd FTP server that's known to support EPRT/EPSV while not advertising it, there could be a "Force EPRT / PASV mode" checkbox in the Site Manager.

Other approach: Opportunistic try, ignore error and fallback to PASV. Hide that specific error from the concise log.