linuxdcpp-team team mailing list archive

[poy <634037@xxxxxxxxxxxxxxxxxx>]

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