RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 844473 - clients connected to cisco rv180 / rv180w are unable to upload files to vsftpd server
Summary: clients connected to cisco rv180 / rv180w are unable to upload files to vsftp...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vsftpd
Version: 6.3
Hardware: x86_64
OS: All
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-30 19:30 UTC by evcz
Modified: 2014-11-09 22:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-30 11:15:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
vsftpd.conf (773 bytes, application/octet-stream)
2012-07-30 19:30 UTC, evcz 		no flags Details
tcpdumps and configs (14.57 KB, application/octet-stream)
2012-08-02 11:45 UTC, evcz 		no flags Details
Show Obsolete (1) View All

Description evcz 2012-07-30 19:30:19 UTC 
Created attachment 601334 [details]
vsftpd.conf

Description of problem:
Clients behind cisco rv180 / rv180w small business routers are unable to complete ftp uploads (PUT)

Version-Release number of selected component (if applicable):
vsftpd-2.2.2-11.el6.x86_64

How reproducible:
every time a client behind a cisco rv180 tries to upload a file

(downloading as GET works fine, directory listing is fine, uploading to proftpd and pureftpd is fine too. It's just uploading to vsftpd that appears to be failing)

Steps to Reproduce:
1. connect a client to a cisco rv180 router/firewall
2. install vsftpd on a remote rhel5 or rhel6 (wan side)
3. setup basic vsftpd config (the test one I'm using is this: http://pastebin.com/raw.php?i=QRS1y7Qw but I've tried changing basically any kind of settings)
4. try to upload a file using PASV mode
  
Actual results:
The file uploading starts properly and continue till the full file is transferred but once the transfer is completed the client hangs untill the data connection timeout expires and at such point the client consider that as an error and tries to reupload the file

at the same time the timeout is reached upload completition log entry is written to the vsftpd logs (as if it was a success)

Expected results:
client should finish the upload without issues and upload completition should be written just right after the upload the file were ended

Additional info:
On the exact same machines replacing vsftpd with proftpd or pureftpd (both with very similar configs and exact same ports used) fixes the issue.

Tried 2 different cisco rv (a cisco rv180 and a cisco rv180w both running the latest firmware 1.0.1.9) and both of them are showing the same issue.

Tried on multiple clients running windows and linux: none of them was working.

Replacing the cisco rv180 with any other kind of router (tried a lot of netgear, dlink, tplink and other vendors routers) fixes the issue (uploads completing properly) with no additional change needed
Comment 2 Jiri Skala 2012-07-31 15:43:14 UTC 
Hi,
unfortunately I have no Cisco rv180 router available. So I'd like to ask you for wireshark traces in the ideal case from both sides of the router.

Thanks, Jiri
Comment 3 evcz 2012-08-02 11:45:36 UTC 
Created attachment 601932 [details]
tcpdumps and configs
Comment 4 evcz 2012-08-02 11:46:47 UTC 
Hi Jiri,

I've attached some tcpdumps.

There are 3 dumps from each side (server / client)

the ones with "atlantis" in the name are captured while the client was behind (NAT) a different router without issues.
This working router is based on Argon 432 running Virata ATMOS

the ones with "rv180" in the name are run while the client was behind (NAT) a cisco rv180 router.

the ones with pure-ftpd in the name are run while the server was running pure-ftpd instead of vsftpd

commands.txt contains the exact command sequence that I issued on the client (client running Ubunbu 12.04 - client software used is "ftp" from terminal)
testfile.txt is the file I was trying to transfer from the client to the server

Client internet connection is the same, server internet connection, firewalls and so on are the same.
Network topology on the client has not been changed, only the router got replaced.

Test server is in Canada, test client in Italy.
TTL ~120ms - no packet loss - connection between client and server is generally excellent.

Into the archive you can also find pure-ftpd.conf and vsftpd.conf that were in use while running the tests

In the past I also did some tries with "ASCII" transfers instead of forced binary but the problem was still there, same with enabling port 20.

If any additional information/test is needed just let me know.

PS: during these tests I realized that after the timeout expires the server push out the 226 message...
I did not noticed that before because I was previosly doing tests on different clients that had a timeout set to 120 (exactly like the server) but was probably expiring sooner due to network latency.

Thank you,
best regards
Comment 5 evcz 2012-08-02 16:36:14 UTC 
Edit: I meant RTT of 120ms... not TTL :D
Comment 6 RHEL Program Management 2012-09-07 05:34:47 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 8 Jiri Skala 2014-08-14 12:08:00 UTC 
Hi,
I verified your vsftpd.conf again. I didn't find 'pasv_address' option there. This should be used if the server is behind NAT:

pasv_address='WAN-ROUTER-IP'

then it should work when the router is configured correctly.

Best regards

Jiri
Comment 9 evcz 2014-08-14 20:17:20 UTC 
(In reply to Jiri Skala from comment #8)
> Hi,
> I verified your vsftpd.conf again. I didn't find 'pasv_address' option
> there. This should be used if the server is behind NAT:
> 
> pasv_address='WAN-ROUTER-IP'
> 
> then it should work when the router is configured correctly.
> 
> Best regards
> 
> Jiri


The server is not behind a NAT.
The server is directly connected to the public internet with a public routable address assigned to the eth0 interface.
Comment 10 Stan Zapaticky 2014-09-14 03:25:27 UTC 
This is a bug in the router ALL PASV FTP uploads fail on the RV180 and RV180W routers and Cisco doesn't seem interested in fixing it.
Comment 11 Jiri Skala 2014-09-30 11:15:50 UTC 
Thanks Stan for sharing this information. I guess the bug can be closed.
Note You need to log in before you can comment on or make changes to this bug.