Bug 844473 - clients connected to cisco rv180 / rv180w are unable to upload files to vsftpd server
clients connected to cisco rv180 / rv180w are unable to upload files to vsftp...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vsftpd (Show other bugs)
x86_64 All
unspecified Severity unspecified
: rc
: ---
Assigned To: Jiri Skala
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2012-07-30 15:30 EDT by evcz
Modified: 2014-11-09 17:35 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-09-30 07:15:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vsftpd.conf (773 bytes, application/octet-stream)
2012-07-30 15:30 EDT, evcz
no flags Details
tcpdumps and configs (14.57 KB, application/octet-stream)
2012-08-02 07:45 EDT, evcz
no flags Details

  None (edit)
Description evcz 2012-07-30 15:30:19 EDT
Created attachment 601334 [details]

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

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 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 11:43:14 EDT
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 07:45:36 EDT
Created attachment 601932 [details]
tcpdumps and configs
Comment 4 evcz 2012-08-02 07:46:47 EDT
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 12:36:14 EDT
Edit: I meant RTT of 120ms... not TTL :D
Comment 6 RHEL Product and Program Management 2012-09-07 01:34:47 EDT
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 08:08:00 EDT
I verified your vsftpd.conf again. I didn't find 'pasv_address' option there. This should be used if the server is behind NAT:


then it should work when the router is configured correctly.

Best regards

Comment 9 evcz 2014-08-14 16:17:20 EDT
(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-13 23:25:27 EDT
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 07:15:50 EDT
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.