DC++ tries to connect/pm through wrong ADC hub

Bug #206778 reported by MikeJJ on 2008-03-25
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
DC++
High
Unassigned
StrongDC++
Critical
Big Muscle

Bug Description

Basically the nmdc problem for which Token was suggested, seems to also happen with ADC.
To reproduce this
1. connect to a ADC hub where downloads is blocked, e.g. DC Dev Public.
2. get someone else to connect to same hub.
3. connect to a ADC hub where downloads aren't blocked.
4. get same person to connect to this.
5. try doing a download / upload to them from the second hub.

It fails because it tries to connect through the first ADC hub where connections are blocked, instead of the one where the connection was initiated from.

Thanks eMTee for helping verify this.

Jacek Sieka (arnetheduck) wrote :

yes, it's wrong now...round-robin would be better (starting with the hubframe hub if added from hub frame)

Changed in dcplusplus:
importance: Undecided → Medium
status: New → Confirmed
Big Muscle (bigmuscle) wrote :

Same problem doesn't apply for connecting only, but also for private messaging, sending search results and user commands. I think there shouldn't be online user map stored in ClientManager, but it should try to find online user in correct hub. It would save some memory too.

Szabolcs Molnár (fleet) wrote :

+1

It's for private messaging too, and it's a critical security issue in that manner, so it would be urgent to fix this bug.

** you cannot share sensitive information on "trusted" hubs in pm, since you never can be sure if your pm goes through on your trusted hub or on another one
** you cannot control bots, because they answer on random hubs and take actions on random hubs
** it's an irritating, old bug but noone seems to care

Big Muscle (bigmuscle) wrote :

i already tried to fix this bug, but without success. Code of this part is too complicated and it would require redesign client and gui part to avoid stability problems.

Szabolcs Molnár (fleet) wrote :

it's a privacy problem too, so i set it to hight

Changed in dcplusplus:
importance: Medium → High
Jacek Sieka (arnetheduck) wrote :

Ok, committed a tentative fix for this...the prefered hub won't be saved in the queue though so it's only valid for the first connection attempt...there's also no warning if pm:s go through another hub (ideally one would have a dropdown with a hub url chooser in the pm case)

Changed in dcplusplus:
status: Confirmed → In Progress
Szabolcs Molnár (fleet) wrote :

Sounds good :) (no, not "good".. rather "great" ;)) )

Just a question about PMs.. you wrote that "there's also no warning if pms go through another hub".. Theoretically how can it happen? I mean when you open a private message window, the PMs in it goes through the initial hub, right? I think if the connection is closed with the original hub, it can go through another one even if the client reconnecs, right? - Maybe this case dc++ could enter a line to the pm window telling the user that the connection with the preferred hub is lost, they have x more hub in common and those will be used for pming. DC++ don't have to track it anymore, but the user will know that it's not ensured that their pm goes through the original hub. If the sender now wants to ensure what hub is used, he may close and reopen the PM window. But you're right, a drop-down list would be better. Just playing with my thougts.

poy (poy) wrote :

would be nice to only see the nick/hub the PM is going on with, not all of the nicks, in the title bar.

Big Muscle (bigmuscle) wrote :

I'm not sure about situation when adding ADC source from search result. Since it doesn't know the user's hub, the "hubHint" variable will contain list of all hubs where the user is connected to. What will happen then?

Big Muscle (bigmuscle) wrote :

Also, I think there's a bug in ClientManager.cpp, function findOnlineUser.

there's: if(u->getClient().getAddress() == hintUrl) {
but it should be if(u->getClient().getHubUrl() == hintUrl) {

because hintUrl is usually set to hubUrl and not to address.

endator (endator) wrote :

This bug has been marked high since almost a year now, has there been ANY progress?

I still can not get a filelist or download from someone if we both are also in a ADC hub where downloading is blocked (like dcdev). This is starting to feel a little silly to have to close one hub to be able to download off another.

poy (poy) wrote :

rev 1864 introduces favorite hub groups; PMs & connections with users in hubs that are part of private fav hub groups should now always happen with the correct hub, and won't happen if that hub is offline.
possibly fixed other issues related to this, and added saving of queue hub hints.

haven't tested much of it.

Changed in dcplusplus:
status: In Progress → Fix Committed
mb.team (c-scholten26) on 2010-01-07
Changed in dcplusplus:
assignee: nobody → mb.team (c-scholten26)
Steven Sheehy (steven-sheehy) wrote :

This bug is already fixed by someone, why are you assigning it to yourself?

Changed in dcplusplus:
assignee: mb.team (c-scholten26) → nobody
mb.team (c-scholten26) on 2010-01-08
Changed in dcplusplus:
status: Fix Committed → Fix Released

Reverted

mb.team dont mess around here this isnt your playground !!

Changed in dcplusplus:
status: Fix Released → Fix Committed
Olorin (vivliofika) wrote :

ha-ha-ha!

Hi!
That's great!
People, don't you know about mailing lists?

Szabolcs Molnár (fleet) wrote :

See priv discussion.

Changed in dcplusplus:
status: Fix Committed → In Progress
poy (poy) on 2010-01-21
Changed in dcplusplus:
status: In Progress → Fix Committed
poy (poy) wrote :

Fixed in version 0.760

Changed in dcplusplus:
status: Fix Committed → Fix Released
poy (poy) wrote :

the private hub group deal may be removed in the future. re-opening this bug for now.

Changed in dcplusplus:
status: Fix Released → Confirmed
Big Muscle (bigmuscle) on 2012-06-11
Changed in strongdc:
importance: Undecided → Critical
Big Muscle (bigmuscle) wrote :

I would insist on fixing this bug completely - introduce hubhint in search results (probably via token) + solve the situation when file with different hubhint is being requested but old connection is used (so connection is made via invalid hub).

Big Muscle (bigmuscle) on 2012-06-21
Changed in strongdc:
status: New → In Progress
assignee: nobody → Big Muscle (bigmuscle)
Fredrik Ullner (ullner) on 2013-11-30
tags: added: core win32-ui
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers