Can't login to ICQ or AIM servers "Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession"

Bug #506647 reported by SchnacK on 2010-01-12
134
This bug affects 29 people
Affects Status Importance Assigned to Milestone
Empathy
Invalid
Undecided
Unassigned
empathy (Fedora)
Fix Released
High
empathy (Ubuntu)
Undecided
Unassigned
pidgin (Debian)
New
Undecided
Unassigned
pidgin (Fedora)
Invalid
High
pidgin (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: pidgin

After an Pigdin crash i couldn't re-login with my ICQ Account, i didn't changed anything at the Programm Failure msg. "Unexpectet Answer from* http://api.oscar.aol.com/aim/startOSCARSession" (*Translation from German sry for gramma fails).
OS: Ubuntu 9.04

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/pidgin
NonfreeKernelModules: nvidia
Package: pidgin 1:2.6.5-0ubuntu1~pidgin2.9.04
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: pidgin
Uname: Linux 2.6.28-17-generic i686
UnreportableReason: Das Paket stammt nicht von Ubuntu.

Related branches

SchnacK (captainstern) wrote :

This is filed against Empathy 2.28.2.

After performing a system update, Empathy is unable to login to AIM and ICQ. Interestingly, Pidgin is also experiencing the same error, reporting the problem as "Received unexpected response from https://api.screenname.aol.com/auth/clientLogin". Empathy didn't specify what the problem was.

On the basis of that error, I ran Wireshark and watched the login attempt.

Empathy sends the following request to the server (with personal details omitted):

----------
GET http://api.oscar.aol.com/aim/startOSCARSession?a=[...]&f=xml&k=[...]&ts=1263348414&useTLS=1&sig_sha256=[...]
HTTP/1.0

Connection: close

Accept: */*

Host: api.oscar.aol.com
----------

The response from the server is then as follows:

----------
HTTP/1.1 200 OK

Date: Wed, 13 Jan 2010 02:06:54 GMT

Server: Apache

Content-Length: 286

Pragma: no-cache

Cache-Control: no-store,no-cache,must-revalidate

Keep-Alive: timeout=1, max=61

Connection: Keep-Alive

Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="http://developer.aim.com/xsd/aim.xsd"><statusCode>400</statusCode><statusText>useTLS=1 is not allowed for non secure requests.</statusText><data><ts>1263348414</ts><upgradeData></upgradeData><betaData></betaData></data></response>
----------

Empathy then reports that the login failed. I have verified that my accounts are still valid: they successfully connect using the website Meebo.

It is interesting that both Empathy and Pidgin are suddenly experiencing the same error. Thinking that the bug must be on AOL's side, I checked with other (non-Fedora) Empathy/Pidgin users, but haven't been able to find anyone else who could reproduce the bug.

The output of `rpm -ql --last` | head -75` is provided in the attachment.

Created attachment 383392
rpm -ql --last | head -75

Psy[H[] (vovik-wfa) wrote :

Maybe those bad people changed protocol again.

Brian Rogers (brian-rogers) wrote :

Also affects ICQ, so I updated the title and changed the message to the English message.

Changed in pidgin (Ubuntu):
status: New → Confirmed
summary: - I Can't login at the ICQ servers "unexpectet answer from
- "http://api.oscar.aol.com/aim/startOSCARSession"
+ Can't login to ICQ or AIM servers "Received unexpected response from
+ http://api.oscar.aol.com/aim/startOSCARSession"
CC (rabidsignup) wrote :

I to am having the same problem. I was logged in at around 3pm today, I turned my computer off and when I turned it back on around 9pm I got this error. I made no changes in between

Wladimir Mutel (mwg) wrote :

The crude fix is to open your ICQ account properties, tab "Advanced", and turn off "clientLogin"

@Wladimir Mutel: Awesome, that did it. Thanks!

Description of problem:
Today I was not able to login to ICQ using pidgin. I've got the message
"Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession" instead.

Version-Release number of selected component (if applicable):
pidgin-2.6.5-1.fc12.i686
libpurple-2.6.5-1.fc12.i686

How reproducible:
Always.

Steps to Reproduce:
1. Install pidgin
2. Setup an icq account with default options.
3. Try to login

Actual results:
"Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession"

Expected results:
Normal work

Additional info:
The problem can be 'fixed' by disabling 'use clientLogin' in the advanced settings tab.

SchnacK (captainstern) wrote :

@Wladimir Mutel: Your comment fixed my Problem Thanks very much

IanExMachina (ianhess) wrote :

I use pidgin on my windows machine too and it had the same problem, Wladimir Mutel's fix did the trick.

I am able to replicate this same error message in Windows 7 x64 using Pidgin 2.6.4.

I am trying to sign-in to a AIM account. Figured I'd append it to this ticket, it may be a AOL issue causing this error, and not a bug.

JF (jfuchs) wrote :

Ubuntu Jaunty 9.04 64bit . Pidgin 2.6.5 . same problem here

Psy[H[] (vovik-wfa) wrote :

Confirming: turning clientlogin (and also ssl) off is a valid workaround.

There will be a package update that forces this option... but only after upstream decides what to do about this.

I am experiencing the same error (confirmed with Wireshark) in Empathy after updating from libpurple-2.6.4-2.fc12.i686 to 2.6.5-1.fc12.i686.

I undid a batch of updates applied at 2010-01-13 12:54, which brought me back to libpurple-2.6.3-2.fc12.i686. After rebooting, I was able to connect to the AIM network in Empathy. Then I updated Empathy only, to 2.6.5-1.fc12.i686, and I started getting the same error again.

libpurple is part of the pidgin component, but I don't know whether the problem is in Empathy or libpurple code.

Similar problems in Empathy after update to libpurple-2.6.5-1 (Bug 554923 for AIM, possibly Bug 555297 for ICQ), but the noted workaround cannot be applied.

According to Bug 554978, Pidgin upstream is working on a fix.

Changed in pidgin (Ubuntu):
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pidgin - 1:2.6.5-2ubuntu1

---------------
pidgin (1:2.6.5-2ubuntu1) lucid; urgency=low

  * Sync on Debian
    - fix login on aim and icq (lp: #506647)
  * debian/control:
    - Build-Depends on liblaunchpad-integration-dev and libtool
    - Drop libpurple0 dependency from libpurple-bin
    - Drop pidgin-data dependency from libpurple0
    - Recommends pidgin-libnotify
  * debian/libpurple0.symbols:
    - add epochs
  * debian/patches/02_lpi.patch:
    - launchpad integration
  * debian/patches/04_let_crasher_for_apport.patch:
    - stop catching the SIGSEGV signal and let apport handle it
  * debian/patches/05_default_to_irc_ubuntu_com.patch:
    - set the default IRC server to irc.ubuntu.com
  * debian/patches/10_docklet_default_off.patch:
    - default behavior to have no notification area icon.
  * debian/patches/11_buddy_list_really_show.patch:
    - the buddy list tries harder to appear. This fixes some issues with it
      not appearing.
  * debian/patches/ 13_sounds_and_timers.patch:
    - adjusts the time out for sounds to be 15 seconds,
      which helps get fewer spurious login notifications on slow connections.
  * debian/patches/60_1024x600_gtk*.c.patch:
    - add scrollbars into preferences and pounce dialogs
  * debian/patches/62_tray_icon_size_kde.patch:
    - always use default tray icon size on KDE
  * debian/prefs.xml:
    - Update to set the notify plugin prefs /plugins/gtk/X11/notify/*,
      set /pidgin/plugins/loaded to load the notify plugin and enable
      the standard logging options by default
  * debian/rules:
    - install a launcher in the message indicator
    - set translation domain and update template
    - use simple-patchsys rules

pidgin (2.6.5-2) unstable; urgency=low

  * debian/patches/libnssckbi_path.patch:
    - Fix path to libnssckbi.so (Closes: #564711)
  * debian/patches/clientlogin-fix.patch:
    - Fixes ICQ/AIM login issue (Closes: #565147)
 -- Sebastien Bacher <email address hidden> Mon, 11 Jan 2010 15:44:51 +0100

Changed in pidgin (Ubuntu):
status: Confirmed → Fix Released

This bug is closed by empathy-2.28.2-2.fc12, which is currently in updates-testing.

I believe AOL have fixed their servers.

I've got empathy-2.8.2-2.fc12.x86_64, and I am still having this problem this morning. Pidgin wasn't working for me either, but I was able to get it to work by disabling clientlogon in the advanced settings. I can't find that setting anywhere in empathy, so I believe this is still an issue.

I can confirm Jonathans statement for empathy-2.8.2-2.fc12.x86_64.
I receive "network connection error" for AIM as stated and for ICQ and IRC that were working before. Jabber (Googlemail) amd YIM are working still fine.

I still see this problem with empathy-2.8.2-2.fc12.x86_64 and libpurple-2.6.5-1.fc12.x86_64. Tracing the connection, I see the same TLS error as Sean. It appears that the site api.oscar.aol.com is listening on port 443 as well as port 80.

There was an outage for a few hours for me, but everything's working fine now. Are others still experiencing this problem?

AIM, ICQ, Jabber and Yahoo are fine now for me (same sw as described above). Only IRC still breaks. Maybe a user settings issue; will have to verify

Tentatively closing again...

Empathy is working for me again, but I don't think this means that the bug has been resolved, so I am reopening the ticket to make sure that my comment is addressed. I'm perfectly fine if you disagree with me and they way you "address" my comment is by closing the ticket again; I just want to make sure that the issues I am raising here are known to the maintainer of the package.

When empathy was failing on Fedora 12, the official AIM was working fine on Windows, and pidgin worked when I disabled clientlogin. Now, while it may be true that AOL did something to their servers to make empathy start working again, if there is a time during which other clients work and empathy didn't, then that strikes me as a bug in empathy, regardless of whether that time passed. It has happened several times now, and I assume will continue to happen in the future, so whatever the problem with the servers is, empathy needs to be fixed to cope with it.

Savvas Radevic (medigeek) wrote :

This affects ICQ and AIM connection on empathy / telepathy-haze too:

purple/util-MESSAGE: 02/19/2010 13:33:19.553309: requesting to fetch a URL
purple/dns-MESSAGE: 02/19/2010 13:33:19.566464: DNS query for 'api.oscar.aol.com' queued
purple/dns-MESSAGE: 02/19/2010 13:33:19.566776: Successfully sent DNS request to child 6308
purple/dns-MESSAGE: 02/19/2010 13:33:19.677126: Got response for 'api.oscar.aol.com'
purple/dnsquery-MESSAGE: 02/19/2010 13:33:19.677222: IP resolved for api.oscar.aol.com
purple/proxy-MESSAGE: 02/19/2010 13:33:19.677269: Attempting connection to 205.188.101.136
purple/proxy-MESSAGE: 02/19/2010 13:33:19.677311: Connecting to api.oscar.aol.com:80 with no proxy
purple/proxy-MESSAGE: 02/19/2010 13:33:19.677405: Connection in progress
purple/proxy-MESSAGE: 02/19/2010 13:33:19.813373: Connecting to api.oscar.aol.com:80.
purple/proxy-MESSAGE: 02/19/2010 13:33:19.813458: Connected to api.oscar.aol.com:80.
purple/util-INFO: 02/19/2010 13:33:19.813513: request constructed
purple/util-INFO: 02/19/2010 13:33:19.993766: Response headers: 'HTTP/1.1 200 OK

Date: Fri, 19 Feb 2010 12:32:37 GMT

Server: Apache

Content-Length: 286

Pragma: no-cache

Cache-Control: no-store,no-cache,must-revalidate

Keep-Alive: timeout=1, max=75

Connection: Keep-Alive

Content-Type: text/xml

'
purple/util-INFO: 02/19/2010 13:33:19.993854: parsed 286
purple/oscar-CRITICAL: 02/19/2010 13:33:19.993994: startOSCARSession response statusCode was 400: <?xml version="1.0" encoding="UTF-8"?>
<response xmlns="http://developer.aim.com/xsd/aim.xsd"><statusCode>400</statusCode><statusText>useTLS=1 is not allowed for non secure requests.</statusText><data><ts>1266582757</ts><upgradeData></upgradeData><betaData></betaData></data></response>
purple/connection-MESSAGE: 02/19/2010 13:33:19.994050: Connection error on 0x13edb30 (reason: 16 description: Received unexpected response from http://api.oscar.aol.com/aim/startOSCARSession)
haze/haze-DEBUG: 02/19/2010 13:33:19.994101: close_all: closing im channels
purple/account-MESSAGE: 02/19/2010 13:33:19.994226: Disconnecting account 482073771 (0x13ebda0)
purple/connection-MESSAGE: 02/19/2010 13:33:19.994271: Disconnecting connection 0x13edb30
purple/oscar-MESSAGE: 02/19/2010 13:33:19.994358: Signed off.
purple/connection-MESSAGE: 02/19/2010 13:33:19.994405: Destroying connection 0x13edb30
haze/haze-DEBUG: 02/19/2010 13:33:19.994462: haze_connection_dispose: disposing of (HazeConnection *)0x13e7120
haze/haze-DEBUG: 02/19/2010 13:33:19.996658: close_all: closing im channels
haze/haze-DEBUG: 02/19/2010 13:33:19.996748: haze_connection_finalize: deleting account 482073771
purple/account-MESSAGE: 02/19/2010 13:33:19.996814: Destroying account 0x13ebda0

Changed in empathy:
importance: Unknown → Undecided
status: Unknown → New
Savvas Radevic (medigeek) wrote :

apologies, it seems like a local package problem

Changed in empathy:
status: New → Invalid
Changed in empathy (Ubuntu):
status: New → Invalid

I am having this problem now, the first time I am using empathy.

Wireshark confirms that it is the same message from aol as in the description.

The issue seems that empathy is connecting to api.oscar.aol.com on port 80 (non encrypted) and providing the startOSCARsession request including useTLS=1.

I would expect that connecting to 443 and giving the exact same request would work just fine, or connecting to 80 and not asking for useTLS=1.

AOL is effectively saying that if you want to have a secure (useTLS=1) connection, you should use https (443) to start it, or you're exposing a bunch of stuff (the startOSCARsession parameters which can probably be decoded pretty easily).

Confirmed that applying this upstream patch fixes the issue.

Note, it must be applied to the pidgin SRPM since it applies to libpurple. I can't reassign the component of this bugzilla.

http://developer.pidgin.im/viewmtn/revision/diff/267f28808ab6eeda6b5d68f6433f2b3fcf230d4f/with/0e3079d15adeb12c1e57ceaf5bf037f9b71c8abd/libpurple/protocols/oscar/clientlogin.c

Created attachment 395391
Patch against pidgin SRPM

thanks for the reassign brian.

AOL changed their server for the previous clientLogin issue more than once within a week. Upstream is not yet sure that this is the only issue that will need to be fixed.

pidgin-2.6.6-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pidgin-2.6.6-2.fc12

pidgin-2.6.6-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pidgin-2.6.6-2.fc13

pidgin-2.6.6-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/pidgin-2.6.6-2.fc11

pidgin-2.6.6-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

*** Bug 563812 has been marked as a duplicate of this bug. ***

pidgin-2.6.6-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

pidgin-2.6.6-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.

Inoki  (inoki) wrote :

Today I started my Pidgin and got this error: https://api.oscar.aol.com/aim/startOSCARSession: Ok but cannot connect to ICQ. Any ideas?

Thomas U. (thomas-unterthiner) wrote :

I have the same problem as Anathaen.

Robert Henjes (henjes) wrote :

after ubuntu update this morning the same problem as Anathaen applies for me.

AmenophisIII (amenophisiii) wrote :

i can confirm that there is again a problem with login in to icq.
but this time it is only for ssl connections: disabling SSL in pidgin "fixes" it.
either it's a temporary problem with the ssl icq servers, or this is a new bug and should be treated as such.

Robert Pastierovic (just-me) wrote :

Also confirming problem with ICQ login; turning off the SSL solves the issue

FetteNase (fettenase) wrote :

Deselect of SSL is not a solution of the problem.

Max Liebkies (mliebkies) wrote :

Well. For the moment it actually is because someone at the new icq-hq decided to switch off ssl on the server side. So: mc-tool update <account-name> bool:use-ssl=0 does the trick for empathy.

Ard (termernator) wrote :

>> Deselect of SSL is not a solution of the problem.
It helps me to solve theproblem In pidgin 2.7.4 (ubuntu 10.10)

FetteNase (fettenase) wrote :

Pidgin 2.7.5 (Windows) works perfectly. Quote from http://www.pidgin.im "Pidgin 2.7.5 fixes several AIM and ICQ bugs introduced in 2.7.4." Please add Pidgin 2.7.5 into the ubuntu-packages. I use ubuntu 10.04.1 + pidgin 2.6.6. Thanks!!

I've got the same problem. Ubuntu 10.04, Pidgin 2.6.6.

According to my ICQ log (~/.purple/logs/icq/[icq-number]/.sytsem/) there is no data after November 15th, so something must have changed since then.

Read /.system/ instead of /.sytsem/ in my previous comment.

agent 8131 (agent-8131) wrote :

I realize that this bug report may not be exactly the right one but for those experiencing this issue for only the last few days (people reporting here since the 18th) it does seem that login.oscar.aol.com port 5190 no longer accepts SSL connections. Unchecking "Use SSL" will allow login. Of course those of us using SSL would prefer to keep using it, but there does not seem to be any workarounds that I have been able to find. It is true that newer versions of pidgin supposedly have this fixed. Lot's of info here:

http://developer.pidgin.im/ticket/11142

eelco.bel (eelco-bit) wrote :

installing from https://launchpad.net/~pidgin-developers/+archive/ppa/ fixed everything for maverick.

Disabling ssl and ClientLogin resulted in an unknow error and disabling of the ICQ account in pidgin.

rainer Ullrich (danzaff) wrote :

well, for me it only seemd to work with just "use ssl" unselected.

Changed in pidgin (Fedora):
importance: Unknown → High
status: Unknown → Invalid
Changed in empathy (Fedora):
importance: Unknown → High
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.