View Full Version : FTP from Windows to Fedora Linux - Caveats for Newbies

15th December 2011, 01:32 AM
Note on using WINDOWS FTP
(Win XP-SP3 & Win2K-SP4)

And some notes on Using
"vsftpd" on Fedora Linux


There is FTP client and server code everywhere, and
if you are like me, with old equipment, and older code
that you have come to rely on, you may still be
interested in trying to use ftp between older Windows
boxes, and various Linux platforms. FTP is typically
pretty stable and simple to use. If your machines
are not accessable from the outside, security is
not a showstopper. But there are still caveats, and
I found one today.

You need to set the buffer *big* when running Windows
FTP to a Linux box. There is a strange Windows bug
that causes it to fail with a hang, and "Connection
Reset by Peer" message - very missleading message!
The problem is local to Windows XP-SP3, and not the
fault of the Linux platform "vsftpd" daemon.

When starting FTP, run a BIG BUFFER, not the standard
size of 4096. On Windows XP-SP3, I could get a repeatable
failure to a Fedora VSFTPD client on a local Linux box.

This failure was for files just over the 64K boundry,
and was specific to text files, regardless of whether
they were sent in binary or ascii form. Smaller and
larger files would send with mput or send, no problem!

SO, when starting FTP, select the -w: option to
specify something not equal to 4096. Eg: (moving some
old SLATEC routines to the Linux box from Windows..)

c:\SLATEC> ftp -w:16000
ftp> open L2-LinBox1
(enter userid when prompted)
(enter password when prompted)
ftp> bin
ftp> prompt off
ftp> mput *.for

seems to work ok. Win2000 worked without this tweak,
but Win XP-SP3 would hang my vsftpd client on the
Linux boxes, but only for files around 64K in size!
Bigger and littler files worked ok. Some stupid MS
coding error, or a deliberate impairment, in the
Windows XP code? Maybe fixed on newer Windows versions,
but I will never know, since I am converting to Linux.

I had one file which would hang the vsftpd on Fedora9
Linux (a *really* stable version on my platforms),
and I spent *hours* debugging the file, thinking it
had some EBCDIC junk characters in it or maybe some
kind of weird rogue bitstream. But Google-searches
finally turned up some folks with *exactly* the same
weird problem, for which the buffer-size expansion on the
Windows side (the calling client), fixes the problem.

The hang only happens on one file (out of 10, for example),
and it is specific to Windows XP-SP3. My old WIN2K
boxes can send and receive all files ok, despite having
the same default 4096 byte ftp buffer-size, running on
the same LAN, same files, to same vsftpd client on same
Fedora Linux machine.

I've become so disgusted with Windows bloatware and
black-box ugliness, that I am suffering the bleeding
edge of Fedora Linux with less pain. Linux is complex,
and sometimes is grief to use - but I find I can *always*
make it work, eventually. WRT this Windows client-side
ftp file-size/buffer-size bug, I can only work around it.
I still have no real idea exactly what is happening to
hang communciation only for 64K+ sized files.

Here is another little tidbit:

If running vsftpd on Redhat Fedora Linux, (I am
running Fedora9 - pretty old now.., but this info
may still apply to new versions), you might like
some tips to get everything working nicely.

"vsftpd" can be a chore to get running right with the
SELINUX (the Security-Enhanced Linux you must run if
you allow *any* outside access of anykind), and the
vsftpd restrictions. (Note: really, use ssh PSCP if
you are coping from the outside world. You should
really have full encryption on everything now).
But for internal box-to-box use, ftp is nice, 'cause
it is easy and simple).

The config file is in /etc/vsftpd/vsftpd.conf, and
you can start and stop the ftp service with the
usual Fedora Linux "service" start and stop commands.
Eg: (using command line interface in Gnome X-windows)

[root@LinBox1 etc]# cd vsftpd
[root@LinBox1 vsftpd]# ls -l ( eg. list files..)

/sbin/service vsftpd status

/sbin/service vsftpd stop (to take down ftp)

vi vsftpd.conf (edit the vsftpd config file)

(find the # commented out stuff that says...)


(This "chroot" stuff locks users only to their home)
(directories. You can change it, and put your main)
(userid in the file "/etc/vsftpd/chroot_list". Then,)
(the chroot_list file holds names of only those who )
(can navigate outside of their home directories, if )
(you want. This is more useful, probably. )

If vsftpd is just internal use only, then go nuts.
I also include in vsftpd.conf, the following:


pasv_min_port=(some big number)
pasv_max_port=(some big number)+(some very small number)

(the "vsftpd.conf" file is well-commented, if you need)
(to make other tweaks or configuration changes. )

And that, plus a tweak to make SELinux view ftp as a trusted
service (use the GUI, and select System/Admin/SELinux Mgmt),
access it using root pswd, select Boolean option, and put
a check market beside "allow_ftpd_full_access". Then, back
out to "Firewall config", and select FTP (21/tcp) as a "Trusted
Service", from the Trusted-Service Menu, so port 21 is allowed
to be seen.

Then, restart vsftpd using the "service" feature, and you will
have an ftp server on the air, and accessable to Windows boxes.
And you can move files over, and begin building your new world!

(Eg: restart vsftpd after tweaking the config file. of
course, you need to do this from the "root" userid...)

[root@LinBox1 etc]# /sbin/service vsftpd restart

From any Windows box, or Dec2020 (got one in your basement, maybe?),
or Linux box, or even from an Apple iPad, running a cheap Telnet
client, you should be able to access your Linux box, and transfer
files back and forth. (The iPad will need an ftp client also...). These can
include large video files, etc. Tweak the vsftpd.conf file to allow
directory listings, and it all will work pretty smoothly, though I suggest
not letting the outside world into the port 21 on your ftp-enabled Linux box.
(If running Linksys router, you just don't enable the port 21
for port-forwarding, like you do with your ssh port 23, and port
80 for your httpd webserver). :)

Good luck, & hope this is maybe useful for someone.

- Rus, Dec. 14, 2011
</pre> :D