Test 254 (passive FTP) still fails for me
Date: Tue, 29 Jan 2013 11:04:07 -0700
Not long ago test 254 passed on my system (OS X Mountain Lion), but around the time the always-multi patch was committed, this test quit working, and test 255 is also stalling. Looking at the trace254 file, I see this:
> 10:24:49.088800 == Info: About to connect() to ::1 port 8996 (#0)
> 10:24:49.088983 == Info: Trying ::1...
> 10:24:49.089577 == Info: 0x7fb8fb805a08 is at send pipe head!
> 10:24:49.089594 == Info: STATE: CONNECT => WAITCONNECT handle 0x7fb8fb413cf8; line 1032 (connection #0)
> 10:24:49.089614 == Info: Connected to ::1 (::1) port 8996 (#0)
> 0000: PASV
> 10:24:49.099735 == Info: FTP 0x7fb8fb8118e8 (line 1365) state change from STOP to PASV
> 10:24:49.099739 == Info: Connect data stream passively
> 10:24:49.099747 == Info: STATE: DO => DOING handle 0x7fb8fb413cf8; line 1223 (connection #0)
> 10:24:49.107553 <= Recv header, 40 bytes (0x28)
> 0000: 227 Entering Passive Mode (::1,235,196).
> 10:24:49.107597 == Info: Couldn't interpret the 227-response
It appears that curl has opened an IPv6 connection to the faux FTP server and is sending it a PASV command. The return from a PASV command is expected to include an IPv4 address, but the server is sending an IPv6 address back, and curl doesn't know what to do about this, so it errors out. So if I'm not mistaken, there are two bugs here:
1. When using IPv6, curl should be using the EPSV and EPRT commands instead of PASV and PORT. I looked at ftp.c and it appears they are supported, but they're not being used on my system for some reason.
2. Should the faux server be returning an IPv6 address in its PASV response? It seems to me that it should only ever return an IPv4 address…
- application/octet-stream attachment: log254.tgz