I've spent the last four hours trying to work out why NTFSCLONE will backup to an FTP server but not restore. The restore just hung at NTFSCLONE's opening line (the bit about 'ntfsclone 2.0.0 (libntfs 10:0:0)').
In a moment of lucidity, it dawned on me that the only difference was that the restoring machine was on a different subnet, going across a Linksys RV082. When I plugged it directly into my LAN, it worked fine.
This got me wondering what was so different about the Linksys and (from memory) I think that the device doesn't route active FTP traffic properly.
As such, I was wondering if the FTP program you use in G4L has an option to force transfer in PASV mode. If it does, are you using it? If not, would you be able to put a menu option on that could allow the end user to toggle active/PASV modes?
J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using the latest release and an alpha you supplied me in another thread. My money's on the router I was using, in fairness -- it's one I swapped out a while back and I'm sure I had issue with active FTP on it before. I distinctly remember us having to get around it in IE6 with the 'Use passive mode for FTP transfers' option.
From http://www.ncftp.com/ncftp/doc/ncftpget.html, -E and -F are used to switch between PASV and PORT modes. As you said, it does say that it is supposed to try one then the other, though, so maybe it is already doing this. Possibly it responds to the timeout option (-t) to determine how long to wait before it tries the other.
J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
G4L uses ncftp family of programs for the ftp access in both upload and download.
It might be that the default route is not being set, or it could be the router.
In the past, I have used an option under S: called Xena that could setup something with routing. The school lab has 4 class C networks all on the same physical network, and it would work if you had one machine on a different network from the server. The Xena option would setup a route that would work. It does a: "route add $server gw $ipaddress"
That might work in you case, or you might have to add the router IP address if they are on different physical networks.
Would have to look at the ncftp options to see if there is a way to set the PASV or if that would solve the problem. I think the ncftp is suppose to automatically try one, and if it doesn't work try the other, but I may be wrong.
Which version are you using of g4l?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've spent the last four hours trying to work out why NTFSCLONE will backup to an FTP server but not restore. The restore just hung at NTFSCLONE's opening line (the bit about 'ntfsclone 2.0.0 (libntfs 10:0:0)').
In a moment of lucidity, it dawned on me that the only difference was that the restoring machine was on a different subnet, going across a Linksys RV082. When I plugged it directly into my LAN, it worked fine.
This got me wondering what was so different about the Linksys and (from memory) I think that the device doesn't route active FTP traffic properly.
As such, I was wondering if the FTP program you use in G4L has an option to force transfer in PASV mode. If it does, are you using it? If not, would you be able to put a menu option on that could allow the end user to toggle active/PASV modes?
J.
Using the latest release and an alpha you supplied me in another thread. My money's on the router I was using, in fairness -- it's one I swapped out a while back and I'm sure I had issue with active FTP on it before. I distinctly remember us having to get around it in IE6 with the 'Use passive mode for FTP transfers' option.
From http://www.ncftp.com/ncftp/doc/ncftpget.html, -E and -F are used to switch between PASV and PORT modes. As you said, it does say that it is supposed to try one then the other, though, so maybe it is already doing this. Possibly it responds to the timeout option (-t) to determine how long to wait before it tries the other.
J.
G4L uses ncftp family of programs for the ftp access in both upload and download.
It might be that the default route is not being set, or it could be the router.
In the past, I have used an option under S: called Xena that could setup something with routing. The school lab has 4 class C networks all on the same physical network, and it would work if you had one machine on a different network from the server. The Xena option would setup a route that would work. It does a: "route add $server gw $ipaddress"
That might work in you case, or you might have to add the router IP address if they are on different physical networks.
Would have to look at the ncftp options to see if there is a way to set the PASV or if that would solve the problem. I think the ncftp is suppose to automatically try one, and if it doesn't work try the other, but I may be wrong.
Which version are you using of g4l?