Bug 60045 - rpm sends malformed ABORT command to FTP server
rpm sends malformed ABORT command to FTP server
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2002-02-19 07:23 EST by Ben Liblit
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-19 07:34:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
recorded dialog between rpm command (client) and FTP server (632 bytes, text/plain)
2002-02-19 07:25 EST, Ben Liblit
no flags Details
raw libpcap packet capture, suitable for use with ethereal or tcpdump (3.22 KB, application/octet-stream)
2002-02-19 07:29 EST, Ben Liblit
no flags Details

  None (edit)
Description Ben Liblit 2002-02-19 07:23:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.1.3 (X11; Linux i686; U;) Gecko/20020205

Description of problem:
When "rpm -qp" is querying a package on an FTP server, it tries to abort the RPM
file download once it has seen enough data to answer the query.  It appears that
the it is trying to send some sort of "ABORT" command to the FTP server. 
However, the command is garbled with several junk characters.  As a result, the
FTP server fails to recognize the command and therefore does not abort the
download.  The entire RPM file is downloaded, causing the "rpm -qp" command to
take much longer than it should.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start a packet sniffer, such as "ethereal" or "tcpdump".

2. Run the following command: "rpm -qip

Actual Results:  A rather large amount of data is transferred; far more than is
necessary to service the query.

In the packet sniffer's output, look for a "RETR" command to begin download of
the RPM file.  A short time later, notice that the client issues a "trABOR"
command.  Presumably this was supposed to be "ABORT" or something like that?  I
don't know the FTP protocol all that well, but I'm pretty sure that "trABOR"
is not a valid command.

If your packet log has time stamps, notice that there is a long delay as the
download continues, unaborted.  At the end, observe that the server sends
confirmation of the download...

    226 File send OK.

...followed by two error messages:

    500 Unknown command.
    500 OOPS: vsf_sysutil_recv_peek: no data

Clearly something's not right here.

Expected Results:  The "rpm" command should send only valid commands to the FTP
server.  In particular, it should send well-formed commands to properly abort
the download once it has seen enough data to service the request.

Additional info:
Comment 1 Ben Liblit 2002-02-19 07:25:52 EST
Created attachment 46000 [details]
recorded dialog between rpm command (client) and FTP server
Comment 2 Ben Liblit 2002-02-19 07:29:25 EST
Created attachment 46001 [details]
raw libpcap packet capture, suitable for use with ethereal or tcpdump
Comment 3 Ben Liblit 2002-02-19 07:34:27 EST
In the packet capture attached above
<http://bugzilla.redhat.com/bugzilla/showattachment.cgi?attach_id=46001>, the
garbled commands from client to server appear in packets 21 & 22.  The fact that
it is split across two packets leaves me wondering whether this is a single
garbled command or whether there were actually *two* commands that should have
been sent at this point.  (If the first command's trailing CRLF has been
scrambled, then it could appear to merge with the second command.)

Observe the long delay between packets 23 & 24.  During this period the rest of
the file download continued, unaborted.  (I've included only the FTP control
connection in this log.)
Comment 4 Jeff Johnson 2002-02-24 11:37:56 EST
Yes, rpm sends an FTP ABOR command.

Yes, there are non-ASCII characters sent
when aborting an FTP command, that's specified
in RFC's and rpm is doing the right thing.

Yes, an entire header is read to perform
a query before sending an ABOR.

Yes data continues to arrive before the ABOR takes

There's no problem that I can see here.
Comment 5 Ben Liblit 2002-02-24 15:53:52 EST
Right you are; rpm is doing exactly what RFC-959 and RFC-854 say it should do. 
Sorry for my confusion.  I guess if there's a bug anywhere, it's in the FTP
server, which clearly doesn't handle ABOR as RFC-959 requires.
Comment 6 Ben Liblit 2002-02-24 16:45:53 EST
While rpm is doing the right thing on the client side, it would be a good idea
to report ABORT handling bugs against buggy FTP servers when we can identify
them.  After all, those buggy servers are making rpm look bad, and we can't have
that now can we?  :-)

rpmfind.net handles ABORT badly; it calls itself "vsFTPd 1.0.0".  I will send a
message to Chris Evans alterting him to the problem.

ftp.rpmfind.net handles ABORT gracefully, with rapid cutoff of the download. 
This server calls itself "Linux 2.4 TUX 2.0 FTP server".  Whoo-hoo ... go TUX!

ftp.redhat.com handles ABORT badly.  It doesn't identify what server software it
is running, but
claims that Red Hat is also using vsFTPd.  Can someone at Red Hat confirm that
this is still the case?
Comment 7 Ben Liblit 2002-02-25 00:55:07 EST
Looks like vsFTPd does handle ABOR, but only if the "async_abor_enable" flag is
turned on in its configuration file.  The documentation seems pretty negative
about the very idea of handling ABOR, and refers to clients that use it as "ill
advised".  Odds are most FTP server admins will leave this turned off.

I guess the only thing to do from the client side is to just avoid FTP servers
that are not configured to handle ABOR.  Sadly, <ftp.redhat.com> is one such
server.  Oh well, all the more reason to use a mirror.  :-)

Note You need to log in before you can comment on or make changes to this bug.