Getting VSFTP working

In addition to getting SSH working that I just posted about, I also got VSFTP working.

The reason I chose VSFTP was because it was claimed that it was the fastest, or amongst the fastest of the FTP programs. I was not doing it for the ability to use SSL. The setup I describe here is NOT secure, as passwords are transmitted in clear text and susceptible to man-in-the-middle attacks. If you are interested in security, look at SSH. Also, look at the options for VSFTP. I didn't try SSL, so I don't know if it works. But you are welcome to try if security is more important than speed.

Speaking of speed, the fastest connection I was able to get out of it with a wifi was 1.3 MB/sec. Over wired it was 4.1 MB/sec down and 3.0 MB/sec up. So about the same speed as samba for transferring files over the same connection, maybe a little faster, but it was much faster than the BFTP found at RTD1261 wikidot, which clocked at around 500 MB/sec over wifi. Additionally, there is no 2 GB limit problem with VSFTP. I used FileZilla for my FTP transfer tests.

Setup is a little more complicated.

First, download the files: http://www.box.net/shared/68250x4psu

Again, I created the binaries from the new buildroot that I was able to create from the GPLed iomega source. I have a feeling this is what prevented my earlier efforts from working.

Once again, unzip the file into the root directory of the screenplay, preserving the directory structure. If you have previously run IomTools and had to do something like that before, then all you have to do is reboot the machine as the script will automatically run. If not, you will need to run the I10SetupVSFTP.sh script yourself.

When the script is finished, you will need to set up a new user.

The default user, ftp, is anonymous access and will provide read only access to the root of the ScreenPlay. This will automatically be set up for you. If you do not want to provide read only access to anonymous users, you will need to edit the /etc/vsftp/vsftp.conf file.

If you want write access to the drive, You will need to setup an account. You cannot use root unless you change root's home dir. I wouldn't suggest doing that. For this example, I'm going to use the user named ftpuser.

adduser -h /tmp/hddmedia -s /bin/nologon -H ftpuser

you will be prompted for a password. If you want the FTP account password protected (a good idea) then enter the password. If not, just press enter and have no password.

Now you will need to edit the /etc/passwd file to change the default group for the new user. vi /etc/passwd and you'll find a line that looks something like this:

ftpuser:$1$mUZ/dW81$bLAtC7pGOSvh3cnbdmHfm0:1003:1003:Linux user,,,:/tmp/hddmedia:/bin/nologon

That second number, right before "Linux user", is the group number. Change it to 0. yes, that will give that FTP user root privileges. The way I've set up the script, the HDD directory gets changed so that only the root group has access to write to it. The FTP login goes to the HDD directory and is chroot protected so that the screenplay media is the only set of directories the user has access to. I would set the group ownership, but the busybox that comes with the screenplay doesn't have that built in. So the paranoid will need to wait until I publish the new buildroot, or use the old buildroot, it might work. And then you can change the group ownership of the HDD directory.

Anyway, that's it. Enjoy.

Hopefully the way I've done SSH and VSFTP should make it easy to add into IomTools, if SuperBerny so desires. I've also given him the necessary code for manipulating the password, so he can add the feature to IomTools to set the root password and create users.

Edit: After playing around with it for a few days, what I'm experiencing on my local box is a lockup during file transfer. Not very consistent, sometimes it locks up after transferring several GB, but usually locks up after 1-2 GB has been transferred, at least downloading. I'm not sure if this is related to the 1.8 firmware, or the VSFTP program. I had lockups prior to VSFTP, so I'd appreciate feedback from others as to if they are seeing lockups on other firmware versions, or no lockups at all.

Edit 2: I have just updated the VSFTP program by compiling it with v4.2.4 of the GCC compiler. It seems to have solved the lockup problem. I was not only able to upload > 6 GB multiple times, and download > 6 GB, I was also able to upload multiple files simultaneously, which the prior compile was leaving dead processes after trying to do. VSFTP works really well now. I am using firmware R1.8. One note: The R1.0 firmware mounts the HDD with no executable permissions, and as a result, you cannot run the script off of the hard drive. So I would recommend either upgrading to R1.8, or running the script by typing sh < I10SetupVSFTP.sh to execute the script.

Getting SSH working

I finally got the Iomega GPL source to compile and link in a way that didn't lock up when I did a chroot :) The uClibc binary library is a very close match to the uClibc library on the SPP. Not perfect yet, I'm getting there. But as close as it is now, I've been able to get some things working that weren't working before.

SSH, for one.

Now, a warning. The SSH is for encrypted transmission. I believe this encryption process slows down the throughput rate of the Screenplay. When doing scp to transfer a file, the fastest I got was about 300 KB/s going over wifi. That's not very good. The FTP found at rtd1261.wikidot.com runs at about 500 KB/s over the same connection. Nonetheless, there are a variety of options in SSH and maybe somebody more knowledgable about SSH than me can figure out how to fine tune this and make it faster for the SPP.

So, if you want to install SSH anyway you start by downloading the binaries I created:
http://www.box.net/shared/o4e84c03ag

Unzip the file into the root of the screenplay, preserving the directories. Now, if you have previously used the IomTools and had to unzip the Setup files, then all you need to do is turn off and turn on the screenplay again and that I10SetupSSH.sh script will automatically run. Otherwise, you will need to run the script yourself.

Now, if you haven't already set the root password, then I have to ask if you are really that serious about security... Anyway, if you haven't, then telnet into the device and set the root password. You should then be able to use ssh to do all further communications.

How did I create the binaries? SSH was an option in the buildroot, so all I did to create the files was to turn on the option and rebuild. Then it was just a matter of copying the libraries and executables one at a time until I had determined which ones were needed to get it started.

SSH does not appear to have the 2 GB limit problem like the FTP from rtd1261.

1.8 firmware differences

For those not already aware, iomega has released its 1.8 firmware available on the support download page.
Doing a quick comparison of the 1.8 firmware vs the 1.0 firmware files:

New Files:
ufsd.ko - Paragon NTFS driver (possibly fixes the Norton problem)
ntfsmount - another NTFS driver from ntfsprogs
DejaVuSans.ttf - font
DroidSansFallback.ttf - font
Grotesk Pro Regular.otf - font
snmpd and some directories with many snmp related files.

Removed Files:
arial.ttf
cwheib.ttf
cwyen.ttf
gkai00mp.ttf

Changed files:
inetd.conf - commented out telnet and www. Added in iodiscovery, and a commented out snmp with a note saying snmpd moved to rcS1.

rcS1 - now installs ufsd.ko and mounts the media partition using that. The "8th" partition (not on any SPP drives I've seen) is being mounted using ntfsmount.

rcS1.4partition - same changes as rcS1

services - added iodiscovery, port 6553 udp and tcp.

smb.conf - Comments removed, making it more difficult for people not familiar with the smb.conf file to change it. Max opened files upped from 1000 to 10000. Max connections upped to 4. Max smbd processed upped to 4. Log size increased to 1000. passdb backend changed to smbpasswd instead of tdbsam. oplocks changed to yes.
removed:
write cache size = 0
max mux = 10
min protocol = NT1
stat cache = no
strict sync = yes
sync always = yes
added:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2048 SO_RCVBUF=2048
read raw=yes
write raw=yes
max xmit=65535
dead time=15
getwd cache=yes
lpq cache=30
read prediction=yes
client NTLMv2 auth=yes

.str files: renamed Shared key (WEP) to WEP Key. Added ShiftJIS and Cyrillic strings. In those where the aspect was listed as 16:09, it was changed to 16:9. Many russian translations changed.

Binaries that changed:
DvdPlayer - Main player menu program
wpa_cli - WPA command line interface to wpa_supplicant
wpa_supplicant - WPA authentication provider
IO_Discovery - Daemon for responding to Discovery calls from the PC
IO_Discovery1 - Same, although slightly different binary.
nmbd - Part of Samba, Responds to NetBios over IP requests
smbd - Part of Samba, responds to file sharing requests
initrd.bin - Initial ram disk boot
install_ide_pvrbox_pc_v2 - Screenplay program that executes after copying firmware to do the install.


The following files are significant in the fact that they did NOT change.

busybox - no new linux commands

All files in the kernel/usb directory - meaning no new wifi devices supported

video_firmware.bin - meaning no new codecs or changes to existing ones.

hotplug - meaning the attaching of external USB drives will still be mounted using the kernel NTFS driver for those NTFS drives. So if those drives have been "modified" by Norton antivirus products, those would effectively stop the screenplay from booting still. Edit: Not true, see comment.