On 2007/06/06 18:21, Brendan Grossman wrote: > I'm having a problem getting through NAT using ftp-proxy to a certain server > using active FTP. > > After analysing packets between this server and others that work, this > server tries to establish a connection on the data port before giving the > 200 OK to the PORT command. > > I'm thinking that ftp-proxy waits for this response before setting up rules. > Can anyone confirm? > > If that is the case, does anyone have any ideas to get around it?
It looks like it (around line 960 of ftp-proxy.c); RFC 959 isn't exhaustive and RFC 1123 doesn't clarify this, but I'd say the server is probably broken here - it seems odd that it should open the data connection before it's told to (i.e. by STOR/RETR/LIST). I think changing this in ftp-proxy would require a fair bit of reworking. Are you able to identify the server software that's in use? Perhaps an update is available...It wouldn't surprise me if it breaks some other NAT helpers too. Since we're on the subject of ftp-proxy, it is over-strict about parsing 227 replies to PASV - 4.1.2.6 in RFC 1123 warns about the lack of standardisation for these; "a User-FTP program that interprets the PASV reply must scan the reply for the first digit of the host and port numbers" - the one I saw was "227 Passive mode OK (10,0,0,138,4,8 )" ...typical... the RFC is absolutely clear about formatting of commands, as far as placing of spaces, but somewhat lacking in defining response formats, allowing such horrors as this (and publicfile's directory listing format :-)
