Can't log into ICQ using bitlbee-libpurple

[km@…]

Trying to log into ICQ using bitlbee-libpurple fails with an incorrect password error. The same account works without a problem with pidgin on the same machine.

The bitlbee-libpurple version is BitlBee-LIBPURPLE 3.4.2+20161018+master+75-gc94e208-git, but I've had this problem with previous 3.4.2 versions as well.

libpurple0 and libpurple-dev on this machine are version 2.10.10-1~deb7u1.

<@user> account 1 set
<@root> allow_multiple_logins = `true'
<@root> always_use_rv_proxy = `false'
<@root> auto_connect = `true'
<@root> auto_reconnect = `true'
<@root> away is empty
<@root> display_name is empty
<@root> encryption = `opportunistic_encryption'
<@root> login_type = `client_login'
<@root> mail_notifications = `false'
<@root> mail_notifications_handle is empty
<@root> nick_format = `%full_name'
<@root> nick_source = `handle'
<@root> password = `********' (hidden)
<@root> port = `5190'
<@root> server = `slogin.icq.com'
<@root> status is empty
<@root> tag = `icq'
<@root> username = [[uin would go here, removed in this dump]]

<@user> account 1 on
<@root> icq - Logging in: Connecting
<@root> icq - Login error: Incorrect password
<@root> icq - Logging in: Signing off..

[dx]

This is a libpurple bug fixed in 2.11.0

Quoting the ​changelog:

	ICQ:
	* Stop truncating passwords to 8 characters like old ICQ clients did.
	  (#16692). If you actually needed this, truncate your password
	  manually by pressing backspace a few times.

Ticket: ​https://developer.pidgin.im/ticket/16692

If you can't upgrade, change your account password (using the website) to be exactly 8 characters long.

[km@…]

My password is 8 characters long, so I don't think that's the bug.

[km@…]

Replying to dx:

This is a libpurple bug fixed in 2.11.0

Quoting the ​changelog:

	ICQ:
	* Stop truncating passwords to 8 characters like old ICQ clients did.
	  (#16692). If you actually needed this, truncate your password
	  manually by pressing backspace a few times.

Ticket: ​https://developer.pidgin.im/ticket/16692

If you can't upgrade, change your account password (using the website) to be exactly 8 characters long.

I've upgraded libpurple to 2.11.0 by compiling a source package. dpkg-i now lists:

ii  finch          2.11.0-3     i386         text-based multi-protocol instant
ii  finch-dev      2.11.0-3     all          text-based multi-protocol instant
ii  libpurple-bin  2.11.0-3     all          multi-protocol instant messaging 
ii  libpurple-dev  2.11.0-3     all          multi-protocol instant messaging 
ii  libpurple0     2.11.0-3     i386         multi-protocol instant messaging 
ii  pidgin         2.11.0-3     i386         graphical multi-protocol instant 
ii  pidgin-dbg     2.11.0-3     i386         Debugging symbols for Pidgin

I've then restarted bitlbee with /reconnect from irssi. My ICQ password is exactly 8 characters long. When I try to connect by ICQ, the following happens:

<@user> account 1 on
<@root> icq - Logging in: Connecting
<@root> icq - Login error: Incorrect password
<@root> icq - Logging in: Signing off..

The pidgin that was compiled as part of the package generation process (and thus also is 2.11.0-3) has no problem connecting to my ICQ account. So it doesn't seem like that's the bug.

[dx]

Maaaaybe shouldn't have closed this so soon. Either way thanks for upgrading, that helps discard a couple of possibilities.

Get a debug log ​https://wiki.bitlbee.org/Debugging and compare the login part with the same output from pidgin when running it with pidgin --debug

[km@…]

Replying to dx:

Maaaaybe shouldn't have closed this so soon. Either way thanks for upgrading, that helps discard a couple of possibilities.

Get a debug log ​https://wiki.bitlbee.org/Debugging and compare the login part with the same output from pidgin when running it with pidgin --debug

The bug (or part of it) seems to be that bitlbee-libpurple tries to connect to api.screenname.aol.com, whereas Pidgin connects to api.login.icq.net. The latter happens to be the same host as slogin.icq.com, which is what the server setting is set to in both programs, but I'm not sure if api.login.icq.net is a hardwired API host or if the problem is that Pidgin uses the server specified in the setting and bitlbee doesn't.

Log excerpts:

From pidgin:

(13:10:52) oscar: oscar_login: gc = 0x81f48500
(13:10:52) util: requesting to fetch a URL
(13:10:52) util: Defaulting max download from https://api.login.icq.net/auth/clientLogin to 524288
(13:10:52) dnsquery: Performing DNS lookup for api.login.icq.net
(13:10:52) dns: Created new DNS child 3413, there are now 1 children.
(13:10:52) dns: Successfully sent DNS request to child 3413
(13:10:52) dns: Got response for 'api.login.icq.net'
(13:10:52) dnsquery: IP resolved for api.login.icq.net
(13:10:52) proxy: Attempting connection to 178.237.20.78
(13:10:52) proxy: Connecting to api.login.icq.net:443 with no proxy
(13:10:52) proxy: Connection in progress
(13:10:52) proxy: Connecting to api.login.icq.net:443.
(13:10:52) proxy: Connected to api.login.icq.net:443.
(13:10:52) nss: SSL version 3.3 using 128-bit AES-GCM with 128-bit AEAD MAC
[ SSL stuff snipped ]
(13:10:52) certificate: Successfully verified certificate for api.login.icq.net
(13:10:52) util: request constructed
(13:10:52) util: Response headers: 'HTTP/1.1 200 OK^M
Server: nginx/1.10.1
Date: Sun, 23 Oct 2016 11:10:52 GMT
Content-Type: text/xml
Content-Length: 498
Connection: close
Pragma: no-cache
Cache-Control: no-store,no-cache,must-revalidate
                                                                              
'
(13:10:52) util: parsed 498

From bitlbee:

DEBUG oscar: oscar_login: gc = 0x81d214a8
DEBUG util: requesting to fetch a URL
DEBUG util: Defaulting max download from https://api.screenname.aol.com/auth/clientLogin to 524288
DEBUG dnsquery: Performing DNS lookup for api.screenname.aol.com
DEBUG dns: Created new DNS child 29773, there are now 1 children.
DEBUG dns: Successfully sent DNS request to child 29773
DEBUG dns: Got response for 'api.screenname.aol.com'
DEBUG dnsquery: IP resolved for api.screenname.aol.com
DEBUG proxy: Attempting connection to 149.174.140.6
DEBUG proxy: Connecting to api.screenname.aol.com:443 with no proxy
DEBUG proxy: Connection in progress
DEBUG proxy: Connecting to api.screenname.aol.com:443.
DEBUG proxy: Connected to api.screenname.aol.com:443.
DEBUG nss: SSL version 3.3 using 256-bit AES with 160-bit SHA1 MAC
[snip SSL]
DEBUG certificate: Successfully verified certificate for api.screenname.aol.com
DEBUG util: request constructed
DEBUG util: Response headers: 'HTTP/1.1 200 OK
Date: Mon, 24 Oct 2016 15:09:08 GMT
Set-Cookie: JSESSIONID=3A416E7E531C98903D23490F90D652C8; Path=/auth/; Secure; HttpOnly
Pragma: No-cache
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: DENY
Content-Type: text/xml;charset=UTF-8
Content-Language: en-US
P3P: CP="PHY ONL PRE STA CURi OUR IND"
Access-Control-Allow-Origin: *
Connection: close

'
DEBUG oscar: clientLogin response statusCode was 330 (3011): <response xmlns="https://api.login.aol.com">
  <statusCode>330</statusCode>
  <statusText>Password/LoginId Required/Invalid</statusText>
  <statusDetailCode>3011</statusDetailCode>
  <data>
    <challenge>
      <info>Enter your password again</info>
      <context>WA4kFAAArBsAqXVs</context>
    </challenge>
  </data>
</response>

[dx]

Hm, probably a result of migrating from non-libpurple to libpurple. Libpurple calls the protocols 'icq' and 'aim', non-libpurple calls it 'oscar', bitlbee aliases 'oscar' to 'aim' so that at least something works.

Workaround: edit /var/lib/bitlbee/<nick>.xml, change the protocol field for this account from oscar to icq. Alternatively delete the account and re-add it as icq.

[km@…]

Replying to dx:

Hm, probably a result of migrating from non-libpurple to libpurple. Libpurple calls the protocols 'icq' and 'aim', non-libpurple calls it 'oscar', bitlbee aliases 'oscar' to 'aim' so that at least something works.

Workaround: edit /var/lib/bitlbee/<nick>.xml, change the protocol field for this account from oscar to icq. Alternatively delete the account and re-add it as icq.

That appears to have done the trick. Editing the xml file didn't do it for me, but deleting the account and adding it again did, so I guess you can close the bug :)

Perhaps the bitlbee-libpurple client should let the user know if the account is set as oscar, saying something to the effect of "this is oscar, assuming you mean AIM" so that the behavior won't be as mysterious to others. Or it could do what non-purple bitlbee does to determine whether it's AIM or ICQ and then call the purple library with the correct servers.

[dx]

Fixed in ​https://github.com/bitlbee/bitlbee/commit/50988d1f5048cc1ca1f8b3af77eb3ad6f909c1c0

Now "oscar" type accounts in libpurple check the first character of the username, just like the builtin oscar protocol does. "aim" and "icq" purple accounts remain unchanged.