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?
 
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.
 
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 ?
 
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).
 
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.
 
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
 
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?
 
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.
 
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.
 
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.
 
Back
Top