Connection wizard's test failed..

[eagle3386]

Alright, got this from the test's log-window:

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-beta1
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 84.180.178.143 ie-bia-bhi-bed
Response: 200 OK
PREP 4454
Response: 200 Using port 4454, data token 147641643
PORT 84,180,178,143,17,102
Response: 200 PORT command successful
LIST
Response: 150 opening data connection
Response: 503 Connection failed.
Server sent invalid reply.
Connection closed

The only apps that MIGHT block it are my firewall
(Fritz!Protect, part of Fritz!DSL-software),
PeerGuardian or my router (Fritz!Box 7170) itself.

Though, none of these apps reported problems (FZ
3.0.0-beta1 listed as "allow connections from this app"
inside Fritz!Protect and PeerGuardian doesn't show any
blocked connection attempt).. Also, using the latest
*stable* FZ, I can connect just fine..

[Tim Kosse]

That's the whole point of the configuration wizard to detect
the user's misconfigured routers/firewalls. Like in your case.

Fix the configuration and the test will pass.

[eagle3386]

How to fix that? FZ is allowed to connect to the Internet
(on all ports!) and my Router doesn't block Port 21..

And AFAIK, there's no need to enable specific ports when an
application connects to a server (the other way needs that,
though)..

[Tim Kosse]

The FTP protocol uses additional connections for the
transfers, and one mode to establish these additional
connections require that FZ is allowed to accept incoming
connections.

[eagle3386]

Well, why does 2.x work with the current settings, but 3.x
reports an error? - I'm using multiple connections and it
works just fine with 2.x..

Additionally, FZ 3 *is* allowed to create and to accept
external connections..

[Tim Kosse]

2.x has no configuration test at all.
You are comparing normal operation with a special test
designed to detect even the smallest problem.

[eagle3386]

OK, my fault.. I apologize myself for that..

Though, I opened 10 ports (33860-33869) and now, the test
still doesn't run fine:

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-beta1
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 84.180.178.143 ie-bia-bhi-bed
Response: 200 OK
PREP 33865
Response: 200 Using port 33865, data token 499640120
PORT 84,180,178,143,132,73
Response: 502 Port mismatch. Tainted by router.
Server sent invalid reply.
Connection closed

[Tim Kosse]

Caused by your router or firewall.

The test does the following:

First it create a listening socket on your system and gets
its port number, which it sends to the server using the PREP
command.
It's a custom command routers and firewalls don't know, so
they relay it through unmodified (At least most do, some
disconnect the client even!)

The server acknowledges the port and sends the client a data
token which will later be used to verify the transfer.

Next the client sends the PORT command using this port in
the last to numbers.

When the server recieves this commands, it checks whether
the passed port is the same as during the PREP command. In
your case that was not the case, indicating that some router
or firewall did tamper with it. Note that even the Windows
firewall is misbehaving and should be disabled.

Assuming everything would be ok, the server would connect to
the port provided by the client and the server sends the
data token again over the data channel.
Client compares it to the one received in the PREP reply to
verify that the connection is reliable.

[eagle3386]

Well, Fritz!Box-routers don't play with packets.. - If you
tell the router to forward external requests on port 1234 to
the local port (also set to 1234 by myself for easier
handling), then the Fritz!Box will exactly do this.

As I got Win2k and not that XP-bullsh.., I don't even have
that firewall installed, only the Fritz!Protect-firewall as
a part of the Fritz!DSL-software, provided by AVM
(www.avm.de) - and as already stated earlier, Fritz!Protect
is instructed to let FZ (3.x) talk to all external ports and
to let all external ports talk to FZ..

So, does the Log-setting (if set to #3) produce any output
which would be useful for this? Or should I set it to #4?

I'd like to get this issue fixed and therefore I'll be as
helpful as I can.. :)

[eagle3386]

Screenshot showing the IP recording

[eagle3386]

Alright,

had a *very* long discussion with AVM (producer of my router) and after submitting some recording (while going through the FZ3-wizard) they finally got the reason which is on the FZ3-side.

In detail, they said:

The FTP client creates an outgoing FTP connection to
filezilla-project.org.
Afterwards the FTP server tries to open the data
connection to the client and receives an ICMP-Redirect
from the FRITZ!Box and refers to itself.
Then, the TCP-Syn goes from the FRITZ!Box to the
FRITZ!Box and upon this the FRITZ!Box finally answers
with a ICMP Type 3.

The reason for FRITZ!Box's ICMP-Redirect is the
following:
The FTP client (FileZilla's assistant) sends the external
IP address of the FRITZ!Box (84.180.182.246) within the
PORT commando and not its own (internal) IP address
(192.168.178.20):

(Embedded image moved to file: pic37923.jpg)

[NOTICE: I've attached this to this tracker item, too.]

We can't find any reason why the FTP client does this,
because normally every NAT-device converts the data
within the PORT commando automatically.

If there's any option called "behind a NAT" inside
FileZilla's settings for the connection wizard or
something like that, it should be turned off.

Maybe the developer puts the result of the IP check
directly into the PORT commando.
If so, we think this isn't correct. If he would send
the PORT commando just with its local IP address, the
FRITZ!Box can patch the PORT commando appropriately
and that could be rrecognized.

Therefore AVM does not plan to change the behavior of
the FRITZ!Box.

So I'm hoping that you can fix this ASAP.

[Tim Kosse]

I'd suggest to get a different brand of router.

It might be possible for your router to perform the magical PORT command rewriting for plain FTP, but as soon as the connection would be encrypted (explicit TLS/SSL for example), the router will be unable to rewrite the PORT command and ALL transfers will fail.
There is only one conclusion: PORT rewriting is broken by design. A router should never ever change the data, that's the job of proxies and gateways.
And FileZilla 3 works perfectly by detecting this flawed router behaviour and notifies the user that there is a problem.

Please forward to the Fritz!Box developers, that I would gladly discuss this issue in more detail, they can contact me at tim.kosse@…

[eagle3386]

Text copied and mail sent to AVM's support-employee (Timo Polterock)

[eagle3386]

Alright,

AVM has replied to your text - here is Timo Polterock's answer:

I've forwarded the remarks regarding the behavior
of the FRITZ!Box of you and Mr. Kosse to the internal
staff.
We'll contact you again in case we need more
information from you or Mr. Kosse.

If and how we'll change the behavior that has been
criticized by Mr. Kosse is not clear at this moment.
So far, a change on the part of the FRITZ!Box is not
planned.

Yes, I wrote them that this can't be a serious answer and that I'm totally disappointed with the way they deal with customers.. AVM's routers are really nice and friendly, but the fact they aren't thinking about fixing this minor issue makes me sick..