Bug 60045

Summary: rpm sends malformed ABORT command to FTP server
Product: [Retired] Red Hat Linux Reporter: Ben Liblit <liblit>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: ftp://ftp.redhat.com/pub/redhat/redhat-7.2-en/os/i386/RedHat/RPMS/rpm-4.0.3-1.03.i386.rpm
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-19 12:34:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
recorded dialog between rpm command (client) and FTP server
none
raw libpcap packet capture, suitable for use with ethereal or tcpdump none

Description Ben Liblit 2002-02-19 12:23:23 UTC 
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):
rpm-4.0.3-1.03

How reproducible:
Always

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

2. Run the following command: "rpm -qip
ftp://ftp.redhat.com/pub/redhat/redhat-7.2-en/os/i386/RedHat/RPMS/rpm-4.0.3-1.03.i386.rpm"



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 12:25:52 UTC 
Created attachment 46000 [details]
recorded dialog between rpm command (client) and FTP server
Comment 2 Ben Liblit 2002-02-19 12:29:25 UTC 
Created attachment 46001 [details]
raw libpcap packet capture, suitable for use with ethereal or tcpdump
Comment 3 Ben Liblit 2002-02-19 12:34:27 UTC 
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 16:37:56 UTC 
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
affect.

There's no problem that I can see here.
Comment 5 Ben Liblit 2002-02-24 20:53:52 UTC 
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 21:45:53 UTC 
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
<http://www.redhat.com/about/presscenter/news_archive/2001/news_7.2_launch.html>
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 05:55:07 UTC 
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.  :-)