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): 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:
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 <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.)
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.
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 <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?
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. :-)