Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Re: Passive IPv6 data transfers fail in FTP

This bug has been added to tracker.

Any chance I could get an estimate of when this bug might be fixed? It's very easy (I already told you how). :-)


Found the problem in your code

Hi again -- I just looked at the WinSCP source code and I think I see the problem.

In CFtpControlSocket::List() under case LIST_PORT_PASV, it searches for the parenthesis in the message and stores their locations in variables i and j. Then in the IPv4 code it does temp = retmsg.Mid(i+1,(j-i)-1) to grab the stuff between the parenthesis and parse it. However the IPv6 code doesn't do this one line, it just starts with temp = temp.Mid(3):
   else if (GetFamily() == AF_INET6)

      temp = temp.Mid(3);
      pData->port = atol( T2CA(temp.Left(temp.GetLength() - 1) ) );

It should be more like:
   else if (GetFamily() == AF_INET6)

      temp = retmsg.Mid(i+1,(j-i)-1);
      temp = temp.Mid(3);
      pData->port = atol( T2CA(temp.Left(temp.GetLength() - 1) ) );

or maybe this to be shorter:
   else if (GetFamily() == AF_INET6)

      temp = retmsg.Mid(i+4,(j-i)-5);
      pData->port = atol( T2CA(temp) );

Passive IPv6 data transfers fail in FTP

I'm using WinSCP 4.2.2 (build 480) as one client for testing an FTP/S server that we're implementing. The following works fine in another client I'm using to test (a proprietary one), although it happens to break on active IPv6 transfers where as WinSCP is breaking on passive IPv6 transfers.

The client is sending an EPSV command and getting what is, as far as I can tell, a proper response, as you can see in the log below, according to section 3 of RFC 2428. The client then sends a LIST command and then immediately attempts to open a connection to the port that the server specified in its response, but apparently fails in doing so for whatever reason. I suspect based on the error in the log that it's actually creating an IPv4 socket and attempting to connect to an IPv6 address with it.

Here's the relevant portion of the log:
. 2009-07-10 14:02:28.243 Connected

. 2009-07-10 14:02:28.243 Got reply 1 to the command 1
. 2009-07-10 14:02:28.243 --------------------------------------------------------------------------
. 2009-07-10 14:02:28.243 Using FTP protocol.
. 2009-07-10 14:02:28.244 Doing startup conversation with host.
> 2009-07-10 14:02:28.249 PWD
< 2009-07-10 14:02:28.251 257 "/Home" Current directory
. 2009-07-10 14:02:28.251 Got reply 1 to the command 16
. 2009-07-10 14:02:28.255 Getting current directory name.
. 2009-07-10 14:02:28.260 Retrieving directory listing...
> 2009-07-10 14:02:28.260 TYPE A
< 2009-07-10 14:02:28.260 200 Transfer mode is now ASCII.
> 2009-07-10 14:02:28.260 EPSV
< 2009-07-10 14:03:02.286 229 Entering extended passive mode (|||49715|)
> 2009-07-10 14:03:02.286 LIST -a
. 2009-07-10 14:03:02.286 Transfer channel can't be opened. Reason: The requested address is not valid in its context.
. 2009-07-10 14:03:02.286 Could not retrieve directory listing
. 2009-07-10 14:03:02.286 Got reply 4 to the command 2

Please let me know if there's anything else I can provide you with. I believe this to be a bug in WinSCP, but could be wrong (despite the fact that another client works fine).