From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Description of problem: Xinetd should make sure that the correct line endings are used when a banner is transmitted. If the banner file contains bare LF characters, they should be converted to CRLF. Alternatively, a warning should be added to the man page that CRLF line endings are required by the RFCs. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create text file using vi. 2. Add "banner <text file>" to xinetd ftpd configuration. 3. Connect to ftp port with IBM z/OS 1.3 FTP client. Actual Results: Banner is transmitted as is, violating FTP protocol standards. The IBM z/OS 1.3 FTP client sees one long line beginning with "220-" and so times out waiting for the next header line. Expected Results: Banner should be sent out with CRLF line ending characters to respect the FTP protocol standards. The IBM z/OS 1.3 FTP client will then see separate lines and the final line will begin with "220 ". Additional info:
Xinetd should not be making any changes to banner files it outputs, since it has no knowledge of the appropriate protocol. Instead, it is the user's responsibility to ensure the banner file is in an appropriate format for the specified protocol. I have updated the xinetd CVS documentation, and the fixed text will be included in a future release of xinetd.
The tcp_wrappers library converts line endings if the ": banner <directory>" extension is used. How is it different from xinetd in this case?