linuxdcpp-team team mailing list archive

[FlipFlop™ <634037@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: dcplusplus
     Importance: Undecided
         Status: New

-- 
Client doesn't send MyINFO on unsupported chars in nick
https://bugs.launchpad.net/bugs/634037
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.

Status in DC++: New

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.