the problem here is that the "Hello" command can be sent for any user,
not just the one logging in. so an altered "Hello" is assumed to be for
some other user, and the client sits waiting for its own "Hello" to come
in.
i'm not sure this could be solved without breaking backwards
compatibility: there may be hubs that send "Hello" messages for their
bots before the "Hello" for the user currently logging in.
** Changed in: dcplusplus
Status: New => Won't Fix
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/634037
Title:
Client doesn't send MyINFO on unsupported chars in nick
Status in DC++:
Won't Fix
Bug description:
Bug in NMDC login: When using a nick that contains chars not supported
by the hub (or maybe not even supported by the client's own locale)
the login procedure stalls after sending $ValidateNick / receiving
$Hello <nick>.
Example:
Nick: http://flexhub.org/images/dc-nick-problem.jpg
Client locale: Win-1251, Hub locale: Win-1251
The client doesn't send it's MyINFO then and the connections waits
until hub disconnects it due to a timeout.
It might be due to $Hello <nick> not replying with the exact same
nickname as the client is using internally. But if there's a
difference between them, then the client should disconnect, instead of
staying connected and not sending MyINFO.
This bug shows the same behavior for Ynhub, Verli and FlexHub logins.
I suggest warning the user if it's using a nickname not compatible
with it's own locale, for NMDC hubadresses. Another option is a proper
message from client if $Hello returns a different nick than originally
sent.
To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/634037/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~linuxdcpp-team
Post to : linuxdcpp-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~linuxdcpp-team
More help : https://help.launchpad.net/ListHelp
