Opened 12 years ago

Last modified 5 years ago

#3181 closed Bug report

Resume Sometimes Persistently fails on FZ3b11

Reported by: mwrmwr Owned by:
Priority: normal Component: Other
Keywords: Cc: mwrmwr, Tim Kosse, Alexander Schuch
Component version: Operating system type:
Operating system version:

Description

This is a follow on from my Help forum entries with an upload of debug log and contrasting log from FZ2 which seems to always work.
I'm still worried that the same problem occurs when remote server is WinFTPserver or FZ 9.2.23 and also if the client is FireFTP.

In the attached logs ip addresses and file names are genuine originals, but I also tested with a simpler file name yesterday as described in Help Forum entry.

The odd thing is that some resumes work but those that don't resume successfully appear to NEVER resume successfully with FZ3b11 but vdo resume with FZ2.2.32

I have reverted to FZ2 for now.

...oh, and its XPsp2 on this (laptop) PC
and same problem on another clinet PC I started this exercise on a few days back.

p.s. NAT at client-end router maps ports 20 and 21, and that stuff about allowing a bunch of ports to be exploited (limit local ports) didn't seem very manageable when it came to NATting. I didn't set any this time but could get away with a few if required. I did try NATting a couple of local ports extra when I first hit problems on the PC I used at the weekend and that didn't fix the problem.

p.p.s. I have transfer compression on

Attachments (2)

FZ3_failsresume.rtf (18.8 KB) - added by mwrmwr 12 years ago.
FZ3 Resumes fail log
FailFZ3b11resume.rtf (37.4 KB) - added by mwrmwr 12 years ago.
another debug log at level 4

Download all attachments as: .zip

Change History (10)

Changed 12 years ago by mwrmwr

Attachment: FZ3_failsresume.rtf added

FZ3 Resumes fail log

comment:1 Changed 12 years ago by Tim Kosse

Please attach a log with debug level 4.

Also, if there's a delay before the timeout, indicate which is the last line in the log before the delay.

Changed 12 years ago by mwrmwr

Attachment: FailFZ3b11resume.rtf added

another debug log at level 4

comment:2 Changed 12 years ago by mwrmwr

File Added: FailFZ3b11resume.rtf

comment:3 Changed 12 years ago by Tim Kosse

Please run the network configuration wizard of FileZilla 3. If it fails, the problem is caused by your router and/or firewall and not FileZilla.

comment:4 Changed 12 years ago by mwrmwr

Sorry codesquid: I didn't mention that on the last submitted file I bypassed the "external" aspect of the routers by means of a 192.168.1.n VPN connection between the two locations. Is that why you asked on seeing that ip address ? Same problem with resume.

Previously, I was using the "normal" - "it says on the tin that it is using external references" approach which requires NAT setting and now I was trying to minimise the router issues.

I struggled a bit with understanding the wizard but by the 3rd or 4th time (not enough BACK options to see what was on previous screen) I got the OK from it.
[p.s. I NATted 6901 and 6902 explicitly as the extra ports rather than open a bunch as suggested in the wizard. I could only just spare those.]
========================================================================
Connecting to probe.filezilla-project.org
Response: 220 FZ router and firewall tester ready
USER FileZilla
Response: 331 Give any password.
PASS 3.0.0-beta11
Response: 230 logged on.
Checking for correct external IP address
Retrieving external IP address from http://ip.filezilla-project.org/ip.php
Checking for correct external IP address
IP 82.16.42.230 ic-bg-ec-cda
Response: 200 OK
PREP 6990
Response: 200 Using port 6990, data token 2029723181
PORT 82,16,42,230,27,78
Response: 200 PORT command successful
LIST
Response: 150 opening data connection
Response: 200 Successful
QUIT
Response: 200 goodbye!
Connection closed
===================================================
Side-track I know but:
a) why can't we put in our explicit ddns name (that would be a good extra test that there's no old value being used) ? (rather than goto your lookup server)
b) You are the expert, so could you explain (or give me a good URL) why my NATted port 21 to 6921 (confidential) does not need to be mentioned in the wizard ? I think it is because that NAT is only used for inward connection to my FZserver - correct. So, If I just have an FTP client on a particular PC, there is no need to NAT port 21 to it - correct ?
Mark

comment:5 Changed 12 years ago by Alexander Schuch

I can just answer to your question a).

The FileZilla 3 network wizard needs a /special/ minimalized probe-FTPd, which is available as part of the FileZilla Project at <http://filezilla.cvs.sourceforge.net/filezilla/probe/>. You can compile the probe-FTPd yourself and run it on the server. On the client, you need to (temporarily) map the domain name "probe.filezilla-project.org" to the IP address of your server, so that this name resolves to your server when the FileZilla network wizard is run.

The network wizard has been designed for end-users who like to use FTP for file transfer to/from (properly set up) remote sites, rather than testing local *and* remote setup issues. But nevertheless, using the steps outlined above, it /can/ be used for that as well.

However, the probe-FTPd was designed to work on Unix-like systems, so if your server is running Windows, it might not compile properly - but you can try it anyway. Though, it is provided as-is and not (officially) supported at all.

comment:6 Changed 12 years ago by Alexander Schuch

In order to (temporarily) map a domain name to (another) IP address, you need to edit /etc/hosts on Unix, or on Microsoft Windows XP C:\Windows\system32\drivers\etc\hosts by default.

comment:7 Changed 12 years ago by Tim Kosse

The 2nd log is very different than the first one. Did you change anything else despite the log level?

Trace: CTransferSocket::OnClose
Trace: CTransferSocket::TransferEnd(1)
Trace: CFtpControlSocket::TransferEnd()
Trace: CFtpControlSocket::OnReceive()
Response: 426 Connection closed; transfer aborted.

This is a rather clear sign that either the server, a router or a firewall did close the connection prematurely.

comment:8 Changed 12 years ago by sf-robot

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

Note: See TracTickets for help on using tickets.