Custom Query (8117 matches)

<Date> Info [Type] Message <30-11-2022 16:00:42> Admin UI [Error] The server appears to be behind a NAT router. Please configure the passive mode settings and forward a range of ports in your router.

The message above should not be [Error], it should be [Info] or [Notice].

When i try to upload with 1.8 in passive mode, i get an error:

Status: Starting upload of c:\Program Files\FileZilla\license.txt Command: TYPE A Response: 200 Type set to A. Command: PASV Response: 227 Entering Passive Mode (12,x,2,11,56,16). Command: STOR license.txt Error: Transfer channel can't be opened. Reason: The requested address is not valid in its context. Error: Upload failed

On the logs for my ftp server (g6) i see:

STOR license.txt asked to upload 'license.txt' in 'd:\' --> Access

allowed.

PASV aborted uploading 'license.txt' in 'd:\' -

(17:42:41 - -0.001 KB - 0.000 KBytes/s).

227 Entering Passive Mode (192,168,0,2,40,123). TYPE A 200 Type set to A. LIST PASV 426 Cannot retrieve. Failed. Aborting 227 Entering Passive Mode (192,168,0,2,249,189).

Compared with 1.7b (which works), there was no PASV command issued after STOR. It just goes straight to "data connection." That has to be the reason it's messing up.. right?

I tried it real quick to upload to a proftpd server and i got the same error.

I hope it's not just me.

thnx

Upon resuming an FTP download of a large file, Filezilla takes up 100% of CPU usage on Windows 98 SE, and mouse pointer movement gets extremely sluggish. After the connection is established, all returns to normal. If the download fails, Filezilla will retry the connection, and upon resuming it again the problem happens again but worse: the system seems to lock up completely for about 60 seconds (sometimes more, sometimes less). Most of the times, the connection is established and the system becomes responsive again after that lock-up period, but sometimes the lock-ups require a hardware reset.

If more than one large file are being downloaded, the lock-up caused by one transfer can make the others fail, so that they in turn lock the system up and make the first resumed download fail too.

This only happens when the resume position (the parameter for the RSET command) is large enough. Resuming the download of a large file on a position near zero doesn't cause any lock-up.

I guess (without looking at Filezilla's source) that there's some blocking call being made while Filezilla waits for the remote server to seek() to the RSET position.

In case that this be a server-dependent bug in Filezilla (I don't think it is), here's an example: I've experienced this problem while downloading the Mandrake distribution from many of the USA mirrors (for example, ​http://www1.mandrakelinux.com/ftpredir.php?url=ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrakelinux/official/iso/10.0/i586&tpc=mirrors-iso-Mandrakelinux-10.0-Official-inst-i586.txt ). This is a 700 Mb file. And for the record, Filezilla was run on a 400 Mhz AMD K6-3 processor.