Bug 165083
| Summary: | sunique on vsftpd caused problems with netkit ftp | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Sachin Prabhu <sprabhu> | ||||
| Component: | vsftpd | Assignee: | Maros Barabas <mbarabas> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Mike McLean <mikem> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0 | CC: | poelstra, praszyk | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | RHEL3U7NAK | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-08-02 18:10:54 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: |
|
||||||
Created attachment 117435 [details]
Proposed patch
Proposed patch checked in. But shouldn't this be handled also by `ftp'? At least the connection should not be refused in this case. Applied on rawhide There is a new ftp-client-patch netkit-ftp-0.17-vsftp165083. This 'hack' will avoid a bug in ftp-server ( < vsftpd-2.0.1-5). This patch can be (later ?) removed. ftp 0.17 Release 28 Use ftp 0.17 Release 29 |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4 Description of problem: When using the suniq option on vsftpd, the server prints the '150 FILE:...' line twice. The ftp client expects only one line of output for every query sent by it. When the 2 lines are sent by vsftpd, it cause a problem with the client. From that point onwards, the client uses the line it received from the server before it got the current line. If you try to run any command requiring connection to the data port after the put command, the client will say 'Connection refused'. This is because the client never reads the '227 Entering Passive Mode' line sent by the server before the ls command is output and tries to connect to the previous data port used by the server. This can be seen in the client strace given. The problem in vsftpd occurs when the suniq flag is used. vsftpd prints out the line using the line vsf_cmdio_write_str(p_sess, FTP_DATACONN, &resp_str); first in function handle_upload_common() at postlogin.c in the if condition checking for suniq condition. then in function get_remote_transfer_fd() at postlogin.c Proposed patch removes the line given above from the vsf_cmdio_write_str function. This line is called for all uploads at get_remote_transfer_fd() and looks like it is not required. Version-Release number of selected component (if applicable): vsftpd-2.0.1-5, ftp-0.17-22 How reproducible: Always Steps to Reproduce: 1. Connect using netkit ftp provided with RHEL to vsftpd sever. 2. use the command 'suniq' to enable unique names for remotely stored files. 3. upload a file with the command put <file name> 4. Try running the ls command. # ftp localhost Connected to localhost.localdomain. 220 (vsFTPd 2.0.1) 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type Name (localhost:root): test 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> suniq Store unique on. ftp> mput install.log mput install.log? y 227 Entering Passive Mode (127,0,0,1,241,187) 150 FILE: install.log.27 150 FILE: install.log.27 47007 bytes sent in 0.00031 seconds (1.5e+05 Kbytes/s) ftp> ls 200 Switching to ASCII mode. ftp: connect: Connection refused ftp> Actual Results: ftp: connect: Connection refused Expected Results: Directory listing. Additional info: Strace of the ftp client given below .. .... 4389 14:23:35 connect(5, {sa_family=AF_INET, sin_port=htons(15737), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 4389 14:23:35 setsockopt(5, SOL_IP, IP_TOS, [8], 4) = 0 4389 14:23:35 rt_sigaction(SIGINT, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x6fd688, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:35 write(3, "STOU install.log\r\n", 18) = 18 4389 14:23:35 rt_sigaction(SIGINT, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:35 read(3, "150 FILE: install.log.8\r\n150 FILE: install.log.8\r\n", 1024) = 50 4389 14:23:35 write(1, "150 FILE: install.log.8\n", 24) = 24 ... ..... ... ..... 4389 14:23:35 write(1, "150 FILE: install.log.8\n", 24) = 24 .. ..... 4389 14:23:35 write(1, "47007 bytes sent in 0.037 seconds (1.2e+03 Kbytes/s)\n", 53) = 53 4389 14:23:35 read(0, "ls\n", 1024) = 3 4389 14:23:38 rt_sigaction(SIGINT, {0x6fd730, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x7040a0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:38 rt_sigaction(SIGINT, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x6fd730, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:38 write(3, "TYPE A\r\n", 8) = 8 4389 14:23:38 rt_sigaction(SIGINT, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:38 read(3, "226 File receive OK.\r\n", 1024) = 22 .. ...... 4389 14:23:38 write(3, "PASV\r\n", 6) = 6 4389 14:23:38 rt_sigaction(SIGINT, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, {0x6fd5e0, [INT], SA_RESTORER|SA_RESTART, 0x1c28c8}, 8) = 0 4389 14:23:38 read(3, "200 Switching to ASCII mode.\r\n", 1024) = 30 4389 14:23:38 write(1, "200 Switching to ASCII mode.\n", 29) = 29