[ProFTPD-committers] [Bug 3499] pr_data_xfer returned -1, error = Software caused connection abort

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3397|Server configuration file |proftpd.conf
description| |

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #1 from Roman <***@gmail.com> 2010-08-21 06:23:41 ---
Created an attachment (id=3398)
--> (http://bugs.proftpd.org/attachment.cgi?id=3398)
Log proftpd -nd20 (version 1.3.3)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #2 from Roman <***@gmail.com> 2010-08-21 06:24:00 ---
Created an attachment (id=3399)
--> (http://bugs.proftpd.org/attachment.cgi?id=3399)
Log proftpd -nd20 (version 1.3.3a)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
Status|NEW |ASSIGNED
CC| |***@castaglia.org
Platform|PC |All
Depends on| |3487
OS/Version|Linux |All




--- Comment #3 from TJ Saunders <***@castaglia.org> 2010-08-21 12:36:01 ---
Hrm. Looks like this behavior was introduced because of the fix for Bug#3487.

What FTP client are you using?

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #6 from Roman <***@gmail.com> 2010-08-22 06:08:24 ---
With the allowed PORT the problem doesn't disappear.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #7 from TJ Saunders <***@castaglia.org> 2010-08-23 19:37:34 ---
In my regression tests for this issue, even using proftpd-1.3.3, I cannot issue
a PORT (or EPRT, or EPSV, or PASV) command while a data transfer is already
occurring -- and have the data transfer succeed properly.

Your log of the proftpd-1.3.3 session does not show that the client sends
another command before the LIST command ends; that means that that log does not
show that the client is doing precisely the same thing as when proftpd-1.3.3a
is used.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #11 from TJ Saunders <***@castaglia.org> 2010-08-30 13:50:25 ---
Unfortunately I don't know Russian, sorry.

The choice of the type of data transfer to use (active or passive) is
determined by the client, not by the server. So the question really is: why
would your client choose to use different transfer types depending on the
proftpd version?

As for the data transfer blocked commands, I'm thinking to add a config
directive that tells proftpd whether to block those commands during a transfer.
That way, you can turn that feature off when you need to.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #12 from TJ Saunders <***@castaglia.org> 2010-08-30 14:31:29 ---
Created an attachment (id=3404)
--> (http://bugs.proftpd.org/attachment.cgi?id=3404)
Adds patch to toggle the behavior during data transfers

This patch adds a config directive that can be used to configure whether
proftpd accepts PORT, EPRT, PASV, and EPSV commands during a data transfer. As
per Bug#3487, the default is to deny this commands.

After applying this patch by doing:

cd proftpd-1.3.3a/
patch -p0 < /path/to/patch
make clean
make
make install

Then you can add the following to your proftpd.conf:

TransferOptions AllowTransferCommandsDuringTransfer

and then hopefully proftpd should act just like it did in previous releases.

Can you apply the patch, and make sure it corrects the issue for your clients?

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #13 from Roman <***@gmail.com> 2010-08-31 01:22:40 ---
The patch doesn't solve a problem... :(
I can create a virtual server with proftpd and give you access on it.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #14 from TJ Saunders <***@castaglia.org> 2010-08-31 01:39:52 ---
The issue is not having access to a server; it's the clients you're using, and
how exactly you're using them.

If the patch doesn't work, then you need to say _exactly_ how it isn't working.
Just saying "it doesn't work" does not help me at all to solve the problem.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #15 from Roman <***@gmail.com> 2010-08-31 02:34:10 ---
On the virtual server you can look itself at all necessary logs.
If the virtual server doesn't approach, tell which information I should give?

(Sorry for my English... I use the automatic translator www.translate.ru)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #16 from Roman <***@gmail.com> 2010-08-31 03:21:34 ---
At use Midnight Commander I receive an error message: "Cannot chdir to
/#ftp:***@ftp.raexpert.ru".


Log (local connection):

220 ProFTPD 1.3.3a Server (mskra-ftp01 FTP Server) [127.0.0.1]
MC -- remote_is_amiga = 0
USER nwhisper
331 Password required for nwhisper
PASS <Password not logged>
230 User nwhisper logged in
PWD
230 Last login was: 2010-08-31 11:15:17
CWD /
257 "/" is the current directory
EPSV
250 CWD command successful
EPRT |1|127.0.0.1|34393|
229 Entering Extended Passive Mode (|||65417|)
TYPE A
200 EPRT command successful
LIST -la
200 Type set to A
EPRT |1|127.0.0.1|44106|
150 Opening ASCII mode data connection for file list
PORT 127,0,0,1,74,172
200 EPRT command successful
LIST
450 Transfer aborted. Link to file server lost
EPRT |1|127.0.0.1|48352|
200 PORT command successful
LIST
425 Unable to build data connection: Connection refused
QUIT


Log (remote connection):

220 ProFTPD 1.3.3a Server (mskra-ftp01 FTP Server) [10.10.21.3]
MC -- remote_is_amiga = 0
USER nwhisper
331 Password required for nwhisper
PASS <Password not logged>
230 User nwhisper logged in
PWD
230 Last login was: 2010-08-31 11:15:13
EPSV
257 "/" is the current directory
EPRT |1|192.168.10.100|49658|
229 Entering Extended Passive Mode (|||65467|)
TYPE A
200 EPRT command successful
LIST -la /.
200 Type set to A
CWD /
150 Opening ASCII mode data connection for file list
CWD /
226 Transfer complete
EPRT |1|192.168.10.100|42400|
250 CWD command successful
LIST
250 CWD command successful
QUIT

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #17 from TJ Saunders <***@castaglia.org> 2010-08-31 11:37:25 ---
And what is the full proftpd.conf that you're currently using, after the patch
was applied? What does the proftpd server debug logging show?

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #18 from Roman <***@gmail.com> 2010-09-01 13:49:30 ---
Created an attachment (id=3405)
--> (http://bugs.proftpd.org/attachment.cgi?id=3405)
proftpd.conf with patch

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #19 from Roman <***@gmail.com> 2010-09-01 13:51:06 ---
Created an attachment (id=3406)
--> (http://bugs.proftpd.org/attachment.cgi?id=3406)
Log proftpd -nd20 (version 1.3.3a with patch, local connection)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #20 from Roman <***@gmail.com> 2010-09-01 13:51:33 ---
Created an attachment (id=3407)
--> (http://bugs.proftpd.org/attachment.cgi?id=3407)
Log proftpd -nd20 (version 1.3.3a with patch, remote connection)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #21 from Roman <***@gmail.com> 2010-09-01 13:53:53 ---
Created an attachment (id=3408)
--> (http://bugs.proftpd.org/attachment.cgi?id=3408)
Log mc (local connection to patched proftpd)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #22 from Roman <***@gmail.com> 2010-09-01 13:54:17 ---
Created an attachment (id=3409)
--> (http://bugs.proftpd.org/attachment.cgi?id=3409)
Log mc (remote connection to patched proftpd)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3405|application/octet-stream |text/plain
mime type| |

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #24 from TJ Saunders <***@castaglia.org> 2010-09-01 16:06:38 ---
Are you sure that this difference in behavior first appeared between
proftpd-1.3.3 and proftpd-1.3.3a? Your logs show that now it's the LIST
command that's being denied; the portion of the code in src/data.c which has
the blacklisted commands during a data transfer is exactly the same in both
proftpd-1.3.3 and proftpd-1.3.3a. Which leads me to think that you actually
were running a version of proftpd earlier than 1.3.3, prior to upgrading to
1.3.3a.

In fact, I suspect that you're seeing the effects of the fix for Bug#3135 right
now (with the patch for this current bug applied). That fix prevents a
segfault in the case of an aborted download.

That being the case, I'm going to attach a slightly different version of the
patch for this bug, to see how it does for you.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3404|0 |1
is obsolete| |




--- Comment #25 from TJ Saunders <***@castaglia.org> 2010-09-01 16:09:10 ---
Created an attachment (id=3410)
--> (http://bugs.proftpd.org/attachment.cgi?id=3410)
Updates previous patch

Care to try this patch? You should keep your existing proftpd.conf, with its
TransferOptions setting.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3410|0 |1
is obsolete| |




--- Comment #26 from TJ Saunders <***@castaglia.org> 2010-09-01 19:10:33 ---
Created an attachment (id=3411)
--> (http://bugs.proftpd.org/attachment.cgi?id=3411)
Updates previous patch

This updates the previous patch so that it turns off the check, added for
Bug#3135, if the "TransferOptions AllowTransferCommandsDuringTransfer" config
is used.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3406|0 |1
is obsolete| |

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3407|0 |1
is obsolete| |

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3409|0 |1
is obsolete| |




--- Comment #27 from Roman <***@gmail.com> 2010-09-02 01:40:47 ---
Created an attachment (id=3412)
--> (http://bugs.proftpd.org/attachment.cgi?id=3412)
Log proftpd -nd20 (version 1.3.3a with last patch, remote connection)

At connection Midnight Commander writes: "ftpfs: Reading FTP directory ...
(strict rfc959)(chdir first)". This line he wrote always with proftpd-1.3.3a
(with patches and without).

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499


Roman <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #3409|1 |0
is obsolete| |

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #28 from TJ Saunders <***@castaglia.org> 2010-09-03 13:44:37 ---
I still need you to confirm that when proftpd was working as you expect, that
you were running a version of proftpd older than 1.3.3. Getting a TraceLog,
with the patch applied, would also be useful.

It's also possible that while the older code worked as you expected for
directory listings, it would not work for file transfers -- and that's what the
newer code was trying to fix. Thus just trying to get directory listings to
work as you expect may be more trouble than it's worth.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #29 from Roman <***@gmail.com> 2010-09-04 03:00:05 ---
Config in attachment I use with proftpd from version 1.3.1 (letter I do not
remember). The problem has appeared only from version 1.3.3a.

Tracelog from mc same as previous. Unprivileged port has changed only.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #30 from Roman <***@gmail.com> 2010-09-13 03:23:26 ---
Proftpd-1.3.3b hasn't changed a situation. =(

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #31 from Roman <***@gmail.com> 2011-01-15 01:23:39 ---
Proftpd-1.3.3d hasn't changed a situation.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #32 from Roman <***@gmail.com> 2011-01-22 01:46:02 ---
The program works fine with disabled mod_wrap2. May be mod_wrap2 is corrupted?

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #33 from TJ Saunders <***@castaglia.org> 2011-01-22 02:39:28 ---
If you define a WrapLog file for mod_wrap2 logging, what does it show?

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499





--- Comment #34 from Roman <***@gmail.com> 2011-01-23 00:30:07 ---
mod_wrap2/2.0.6[12632]: using 'file:/etc/hosts.allow' for allow table
mod_wrap2/2.0.6[12632]: using 'file:/etc/hosts.deny' for deny table
mod_wrap2/2.0.6[12632]: looking under service name 'proftpd'
mod_wrap2/2.0.6[12632]: checking access rules for connection
mod_wrap2/2.0.6[12632]: checking allow table rules
mod_wrap2/2.0.6[12632]: daemon list is empty
mod_wrap2/2.0.6[12632]: checking deny table rules
mod_wrap2/2.0.6[12632]: table daemon list:
mod_wrap2/2.0.6[12632]: proftpd
mod_wrap2/2.0.6[12632]: proftpd
mod_wrap2/2.0.6[12632]: proftpd
mod_wrap2/2.0.6[12632]: table client list:
mod_wrap2/2.0.6[12632]: 93.115.125.100
mod_wrap2/2.0.6[12632]: 213.33.156.141
mod_wrap2/2.0.6[12632]: 72.55.165.45
mod_wrap2/2.0.6[12632]: daemon matches 'proftpd'
mod_wrap2/2.0.6[12632]: allowed connection from ***@188.123.251.10

Log file without errors. But the program works normally if i disable a
mod_wrap2.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3499

--- Comment #35 from TJ Saunders <***@castaglia.org> 2011-02-20 17:20:35 EST ---
I think this might be caused by/be the same bug as Bug#3538.

Your original proftpd.conf didn't mention any mod_wrap2 configuration; could
you provide the proftpd.conf you're using?

Also, could you comment out the "SQLLog PASS" line of your proftpd.conf, and
see if that helps?