Bugs item #3421912, was opened at 2011-10-11 21:31
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3421912&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ftp
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas L. Shinnick (tshinnic)
Assigned to: Daniel Stenberg (bagder)
Summary: unable to force PORT usage, --disable-eprt ineffective

Initial Comment:
Unintended consequences? Or malevolent sense of humor?

After a couple hours of "but the documentation says --disable-eprt will force use of PORT in FTP sessions" and searching the web and experimentation, I grabbed the source. *Very* disappointed to find

  /home/Tom/temp/curl-7.22.0/lib/ftp.c
   961 #ifdef ENABLE_IPV6
   962 if(!conn->bits.ftp_use_eprt && conn->bits.ipv6)
   963 /* EPRT is disabled but we are connected to a IPv6 host, so we ignore the
   964 request and enable EPRT again! */
   965 conn->bits.ftp_use_eprt = TRUE;
   966 #endif

curl currently will ignore any explicit command line option to the contrary and use EPRT if connecting to an ipv6-enabled host. Connecting to a defaulted modern Linux will find both ipv4 and ipv6 enabled. It is impossible to force use of PORT using the identified options.

Well, unless you *also* specify the -4 option to first force ipv4 usage. That is,

      ./curl --verbose --ftp-port - --disable-eprt --list-only ftp://Tom:@localhost:2121/

will still use EPRT, not PORT, but

    ./curl --verbose -4 --ftp-port - --disable-eprt --list-only ftp://Tom:@localhost:2121/

will work to force use of PORT.

If a user says --disable-foo how can it ever be appropriate to 'foo' ? In this case, the association between EPRT and ipv6 _should_ have been interpreted to mean that ipv6 should have been disabled also. Or so it would seem...

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2011-10-17 00:48

Message:
I just uploaded unstick-ipv6.patch as an attachment to this bug report. Can
you try and see if it makes your case work any better?

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-10-17 00:20

Message:
I think see the "stuck ipv6 status" problem in the code. I'll work on a
small patch you can try...

----------------------------------------------------------------------

Comment By: Thomas L. Shinnick (tshinnic)
Date: 2011-10-16 23:44

Message:
I stumbled on this oddity in wanting to use curl as a test tool, as yet
another ftp client to test an FTP server. I needed to force use of
PORT/EPSV when curl _really_ seemed to want to use ipv6 commands. In all
my test cases, only ipv4 connections were used, as the FTP server software
disallowed ipv6 connections.

I have struggled figuring out how to illustrate the 'problem', as I am
having a hard time describing the weirdness here. It is as though, if curl
thinks there is any possibility of ipv6 connections, it 'resists'
ipv4-style commands. This could be a problem, the lack of flexibility, in
a mixed environment, when curl 'guesses' wrong. Not all software/hardware
is ready for ipv6 and curl requiring ipv6 commands could cause problems.

I'll first give the minimum information, my local /etc/hosts and then a
table of options vs. actions. And I'll copy much of this to a 'gist' so
that the formatting won't be messed up
      https://gist.github.com/1291458

On a defaulted Fedora 15 Linux the /etc/hosts file has both ipv4 and ipv6
definitions for 'localhost'. I added a definition for the host name as an
ipv4 address. Thus we have one name that has both ipv4 and ipv6, and one
name that has only an ipv4 definition:
 
    127.0.0.1 localhost localhost.localdomain localhost4
localhost4.localdomain4
    ::1 localhost localhost.localdomain localhost6
localhost6.localdomain6
    192.168.57.145 TLSF15A.TLSWG TLSF15A

If I run a series of tests using the ipv4-only name, everything works as
expected:
              
    tlsf15a EPSV
    tlsf15a --disable-epsv PASV

    tlsf15a --ftp-port - EPRT
|1|192.168.57.145|38450|
    tlsf15a --ftp-port - --disable-eprt PORT
192,168,57,145,181,77
    tlsf15a -4 --ftp-port - EPRT
|1|192.168.57.145|56256|
    tlsf15a -4 --ftp-port - --disable-eprt PORT
192,168,57,145,129,157

When I run the same tests on the name which could be *either* ipv4 or
ipv6, we get strange results for some combinations:

    localhost EPSV
 ?? localhost --disable-epsv EPSV
    localhost -4 EPSV
 ok localhost -4 --disable-epsv PASV

    localhost --ftp-port - EPRT |1|127.0.0.1|58913|
 ?? localhost --ftp-port - --disable-eprt EPRT |1|127.0.0.1|56154|
    localhost -4 --ftp-port - EPRT |1|127.0.0.1|59841|
 ok localhost -4 --ftp-port - --disable-eprt PORT 127,0,0,1,156,94

The lines marked with '??' are unexpected results.

While I could throw the many test listings in here, let me instead show
those for the last two cases marked above:

Here we give all the options correctly to forbid, but EPRT is done anyway;
 note the display saying that an ipv6 connection was attempted and
rejected, followed by a successful ipv4 connection; we *are* using ipv4 but
somehow we don't use ipv4 commands;

        curl --verbose --ftp-port - --disable-eprt ftp://localhost/
        * About to connect() to localhost port 21 (#0)
        * Trying ::1... Connection refused
        * Trying 127.0.0.1... connected
        * Connected to localhost (127.0.0.1) port 21 (#0)
        < 220 (vsFTPd 2.3.4)

> EPRT |1|127.0.0.1|56154|
        < 200 EPRT command successful. Consider using EPSV.
        * Connect data stream actively

  Here we first disallow attempting ipv6 connections, and then the options
work again;

        curl --verbose --ftp-port - --disable-eprt -4 ftp://localhost/
        * About to connect() to localhost port 21 (#0)
        * Trying 127.0.0.1... connected
        * Connected to localhost (127.0.0.1) port 21 (#0)
        < 220 (vsFTPd 2.3.4)

> PORT 127,0,0,1,156,94
        < 200 PORT command successful. Consider using PASV.
        * Connect data stream actively

It is the situation where curl first attempts an ipv6 connection that
seems to confuse curl. It doesn't seem to have noticed that it later
actually connected using ipv4. I have to think there is a simple boolean
flag stuck somewhere.

Note that tests were done using both 7.21.3 and 7.22.0
      curl 7.21.3 (i386-redhat-linux-gnu) libcurl/7.21.3 NSS/3.12.10.0
zlib/1.2.5 libidn/1.19 libssh2/1.2.7
      curl 7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.0
zlib/1.2.5

Summary:
  - if an ipv6 connection is *possible*, --disable-eprt has no effect
  - workaround to disallow EPRT/EPSV is to also use -4 option
  - a more unlikely workaround is to use an ipv4-only DNS name
  - no documentation of ipv6 vs ipv4 vs options
  
Because this problem has a user-level workaround, it is therefore not
something that *must* be fixed in code. However, because of the code's
unintuitive actions, something should be noted in the *documentation*
regarding priority of ipv6 connections vs. ipv4-related options.
 
(I also noticed these typos in the man page for 7.22.0:
    /home/Tom/temp/curl-7.22.0/docs
      .TH curl 1 "14 April 2009" "Curl 7.21.6" "Curl Manual"
                                         ^^^^

                                              vvvv
      --epsv can be used to explicitly enable EPRT again and --no-epsv
      is an alias for --disable-epsv.
)

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-10-15 16:28

Message:
If the connection is done with IPv6, it seems _very_ unreasonable to use
PORT to a FTP server as that implies IPv4 to be used to connect back to the
client. It is also a technical problem since "--ftp-port -" would get the
local address and use that (for PORT) but as the connection is done with
IPv6 libcurl has no local IPv4 address to use and it doesn't know a
suitable one.

Are you actually asking for a mixed IPv6 - IPv4 FTP operation or as you
asking for --disable-eprt to rather imply IPv4 from the start?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3421912&group_id=976
Received on 2011-10-17