Red Hat Bugzilla – Bug 60045
rpm sends malformed ABORT command to FTP server
Last modified: 2008-05-01 11:38:01 EDT
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):
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.
Created attachment 46000 [details]
recorded dialog between rpm command (client) and FTP server
Created attachment 46001 [details]
raw libpcap packet capture, suitable for use with ethereal or tcpdump
In the packet capture attached above
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.)
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.
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.
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?
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. :-)