mldonkey, a multi-networks file-sharing client - Bugs: bug #16507, firewalled source is treated as...
You are not allowed to post comments on this tracker with your current authentication level.
bug #16507: firewalled source is treated as direct?
Submitter: | Kozarezov Artem <artemgr> | ||
Submitted: | Wed 03 May 2006 12:24:08 PM UTC | ||
Category: | eDonkey-Plugin | Severity: | 3 - Normal |
Item Group: | Program malfunction | Status: | Need Info |
Assigned to: | None | Open/Closed: | Open |
Release: | 2.7.5 | Release: | |
Operating System: | FreeBSD | Binaries Origin: | Downloaded from third-party page |
CPU type: | Intel x86 |
Spam posted by brucewayne | |
Fri 10 Nov 2006 11:47:18 AM UTC, comment #3: |
Kozarezov Artem <artemgr> |
Thu 09 Nov 2006 10:17:07 PM UTC, comment #2: An indirect client is a client which connected to MLDonkey
|
spiralvoice <spiralvoice>![]() |
Thu 04 May 2006 08:33:06 AM UTC, comment #1: When i use MLDonkey from NAT and configure it with
|
Kozarezov Artem <artemgr> |
Wed 03 May 2006 12:24:08 PM UTC, original submission:
I have a file i want to share into the network.
|
Kozarezov Artem <artemgr> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2006-11-09 | spiralvoice | Status | None | ![]() |
Need Info |
2006-05-03 | artemgr | Attached File | - | ![]() |
Added firewalled.PNG, #9883 |
Yeah,
i know for the fact that the other peer is firewalled (because the other peer is my own eDonkey running behind a NAT), and that it has a low-id, and i see that MLDonkey (at least at the time when the bug was submitted) displays that peer as "Indirect" but, as it seems, still tries to contact that firewalled peer directly...
I thought that this is due the fact, that some part of MLDonkey code decides on how to contact the peer based on its IP, and for my peer it sees the public NAT IP, not the private one.
I may have been mistaking in diagnosis, but the fact is that NAT-firewalled peer, which is both connected to a EDK server and have a KAD buddy, and have a file to share: a) is found by MLDonkey; b) MLDonkey tries to contact it; c) there is no sign in the firewalled peer that it has been contacted (no new clients in queue), nor there is any sign that the peer has been contacted in the MLDonkey interface.