Transferring files via FXP to connected USB HDD

Hammett

New Member
Has anyone successfully managed to transfer files via FXP from humax hdd to usb attached hdd? Have tried flashftp, ftprush on pc, tried tinyftp and vsftpd on humax. Tried disabling passive transfer, all to no avail.

Any ideas?
 

af123

Administrator
Staff member
It would only have to support standard FTP commands but would need passive mode support. Most FTP servers restrict FXP for security reasons though so you'd need to look at the vsftpd configuration. Tinyftp won't work due to the missing passive support.
 

raydon

Well-Known Member
I thought FXP required two remote servers with the transfer being initiated between them by a local client. I see only one server in this scenario. Am I missing something obvious here ?
 

Black Hole

May contain traces of nut
Good point, but I did think it should allow for the relocation of a file within a file system instead of the FTP process of transferring of data via two network links, and it is what seems to have been done on the HDR-FOX in THIS TOPIC (click).
 

af123

Administrator
Staff member
I thought FXP required two remote servers with the transfer being initiated between them by a local client. I see only one server in this scenario. Am I missing something obvious here ?
The client could make two connections and then initiate a transfer between the daemons. I'm not saying it makes sense, just it is possible.
 

raydon

Well-Known Member
O.K. Got this working using vsftpd server and FlashFXP as the client. You just need to add the following two lines to /opt/etc/vsftpd.conf in the #Security section.

pasv_promiscuous=YES
port_promiscuous=YES
 
OP
H

Hammett

New Member
Thanks for that raydon, added two lines to config, then stopped and started the vsftp service, problem is it won't start now unless I revert back to the old config file. Does the unit require a restart to apply the setting?
 
OP
H

Hammett

New Member
Bingo, had to telnet and vi the config file, vsftpd must not like windows editing the file, I presume it writes it back incorrectly. Many thanks again raydon, you're a font of humax knowledge.
 

Black Hole

May contain traces of nut
The problem will be line endings. Windows uses CRLF and Linux uses just LF, so the CR will be seen as an extra unexpected (probably invalid) character, potentially invalidating the whole command line.

This shows up particularly in Telnet, where sending commands to a Unix/Linux system (eg the Humax) from a Windows Telnet client produces mostly OK command functions except there is a double command prompt in response (the CR is interpreted as a command ending, and then so is the LF). It goes wrong when a program requires user input, and then the CR screws things up. Usually there is a way to adjust the line ends in a Windows Telnet client: the Windows client itself requires the "unset crlf" command each time, or PuTTY has a configuration option.

When creating/editing files in Windows that are destined for a Unix/Linux system, it is important to use a programmer's editor with line ending options instead of just a normal Windows ASCII editor (eg Notepad) or word processor saving to .txt. It is however possible to covert a file from CRLF to LF, there are plenty of downloadable utilities to do that.
 
OP
H

Hammett

New Member
I thought that transferring files to ext hdd this way would be quicker, it's still twice as fast as copying via samba as the data has to go via the computer. Strange thing is though, if I copy a file from the humax to pc via network I get about 5mb/s. Fxping the file gets me about 3.2mb/s. Shame, there would appear to be a bottleneck somewhere.
 
Top