Menu
▾
▴
#197 Account stays in connecting stage
In adium when a private key is generated for a LCS or lync office communicator using the sipe-1.15.1 extension the account stays in connecting stage, debug logs are showing that the service does not even connect to any server.
Only solution to get the account working again is to delete and re-create the account.
Related
13:54:26: (GLib : general): CRITICAL: const char purple_status_type_get_id(const PurpleStatusType ): assertion
status_type != NULL' failed 13:54:26: Setting d81fc60 disabled and offline ((null))... 13:54:26: <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net: Updating status for key: isOnline 13:54:31: (GLib): (13:54:31) util: Writing file accounts.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple 13:54:31: (Libpurple: util) Writing file accounts.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple 13:54:31: (GLib): (13:54:31) util: Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/accounts.xml 13:54:31: (Libpurple: util) Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/accounts.xml 13:54:31: -[AIAccount(Abstract) retrievePasswordThenConnect]:448: Retrieving <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net's password (promptOption 2) 13:54:31: <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net: Updating status for key: isOnline 13:54:31: <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net: Original image of size 128.000000 128.000000 13:54:31: -[CBPurpleAccount setAccountUserImage:withData:]:2717: <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net: Setting icon data of length 0 13:54:31: <ESPurpleSIPEAccount:334b5b0 9>:sbuxhofer@juniper.net: Updating status for key: User Icon 13:54:31: Adium: Connect: sbuxhofer@juniper.net initiating connection using status state <AIStatus: 311eb60 [Available]> ((null)). 13:54:31: Setting status on d81fc60 (sbuxhofer@juniper.net,sbuxhofer@juniper.net): ID available, isActive 1, attributes { } 13:54:31: (GLib : general): CRITICAL: PurpleStatus *purple_presence_get_status(const PurplePresence *, const char *): assertionpresence != NULL' failed13:54:31: (GLib): (13:54:31) account: Invalid status ID 'available' for account sbuxhofer@juniper.net,sbuxhofer@juniper.net (prpl-sipe)
13:54:31: (Libpurple: account) Invalid status ID 'available' for account sbuxhofer@juniper.net,sbuxhofer@juniper.net (prpl-sipe)
13:54:31: (GLib : general): CRITICAL: PurpleStatus purple_presence_get_active_status(const PurplePresence ): assertion
presence != NULL' failed 13:54:31: (GLib : general): CRITICAL: gboolean purple_status_is_online(const PurpleStatus *): assertionstatus != NULL' failed13:54:36: (GLib): (13:54:36) util: Writing file accounts.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple
13:54:36: (Libpurple: util) Writing file accounts.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple
13:54:36: (GLib): (13:54:36) util: Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/accounts.xml
13:54:36: (Libpurple: util) Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/accounts.xml
13:54:36: (GLib): (13:54:36) util: Writing file blist.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple
13:54:36: (Libpurple: util) Writing file blist.xml to directory /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple
13:54:36: (GLib): (13:54:36) util: Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/blist.xml
13:54:36: (Libpurple: util) Writing file /Users/sbuxhofer/Library/Application Support/Adium 2.0/Users/Default/libpurple/blist.xml
Sascha,
You mention that this has something to do with generating the private key. What specifically are you seeing that leads you to that conclusion? The logs above do not indicate that.
This particular issue is something that I have been trying to track down for a while, and have been unable to pin-point. As I'm only able to devote some of my time to this, I haven't figured it out yet. If you have any additional context that can help me, that would be very helpful.
I have found that a work-around that is quicker than deleting the entire account, is to modify the username to something invalid (I usually just append a 1 to my username), and then attempt a connection. The server will reject the connection and something in that process resets the internal state enough to allow connections.
Hi Michael,
In adium preferences -> advanced -> encryption you have the option to
generate a private key. As soon as I did this for the lync account, it
didn't even start connecting to the server. Hence there is not really
any log to show.
The only way I could get the account to initiate the connection again
was to delete the account and re-create it. This seems to have wiped
out the private key settings and made the account possible to connect
again.
Let me try out modifying the username and modifying it back after a
creating a private key to see if anything changes.
Is the workaround working for you?
I think I've narrowed down the "how" this is happening... (libpurple isn't serializing the presence info to the accounts.xml file) now I just have to figure out the "why". :)
Workaround works for me, but it is annoying, since I have to do it once or twice a day.
Got a Mac loaner over the weekend with OS X 10.9.
Yes, this is really annoying.
IMHO the subject is misleading. The problem has nothing to do with private keys or not. From the log I see that the account enabling is aborted due to missing preferences.
Last edit: Michael Lamb 2013-11-08
Verified that this problem still exists in 1.17.0
Correct. This isn't in the SIPE code (core or Adium plugin)... I believe it's in the Adium core code. I haven't narrowed down the place where it breaks, so I haven't filed a bug (or submitted a patch) to the Adium team yet.
I have updated the bug report subject though.
Well, Harris proved that it was actually a problem in the SIPEAdiumPlugin code and fixed it in git commit c0a0fa2.
On my test machine this problem appeared every time I started Adium. I can no longer reproduce it with the latest git HEAD. CLOSING.
is a release with this fix forthcoming?
Release 1.18.0 will include this. We're targeting beginning of the year for that release.