Hide Forgot
On one Fedora 16 machine I cannot log in to Google Talk from empathy. The UI tells me "Authentication failed.". I tried retyping my password over and over again, to make sure I had it right, and I even logged in from another machine to make sure I had the correct password. In fact is looks like the error handling is just completely broken, and it's lying to me about the error. The part of the telepathy-gabble debug output that looks relevant is this: (telepathy-gabble:3737): gabble-DEBUG: gabble_server_tls_manager_verify_async (server-tls-manager.c:219): verify_async() called on the GabbleServerTLSManager. (telepathy-gabble:3737): gabble-DEBUG: gabble_server_tls_channel_constructed (server-tls-channel.c:247): Server TLS channel constructed at /org/freedesktop/Telepathy/Connection/gabble/jabber/lalalalalala_40googlemail_2ecom_2f730cdda4/ServerTLSChannel (telepathy-gabble:3737): tp-glib/channel-DEBUG: tp_base_channel_close_dbus: called by :1.70 (telepathy-gabble:3737): gabble-DEBUG: gabble_server_tls_channel_close (server-tls-channel.c:344): Close() called on the TLS channel 0x9578728 (telepathy-gabble:3737): gabble-DEBUG: server_tls_channel_closed_cb (server-tls-manager.c:137): Server TLS channel closed. (telepathy-gabble:3737): gabble-DEBUG: server_tls_channel_closed_cb (server-tls-manager.c:142): Channel closed, but unhandled, falling back... (telepathy-gabble:3737): gabble-DEBUG: gabble_server_tls_channel_dispose (server-tls-channel.c:143): Dispose TLS channel (telepathy-gabble:3737): gabble-DEBUG: gabble_server_tls_channel_finalize (server-tls-channel.c:126): Finalize TLS channel (telepathy-gabble:3737): gabble-DEBUG: gabble_server_sasl_channel_start_auth_async (server-sasl-channel.c:814): Starting authentication (telepathy-gabble:3737): tp-glib/channel-DEBUG: tp_base_channel_close_dbus: called by :1.70 (telepathy-gabble:3737): gabble-DEBUG: gabble_server_sasl_channel_close (server-sasl-channel.c:965): called on 0x957bd60 (telepathy-gabble:3737): gabble-DEBUG: gabble_server_sasl_channel_close (server-sasl-channel.c:971): closed channel (telepathy-gabble:3737): gabble-DEBUG: connector_error_disconnect (connection.c:1673): connection failed: WOCKY_AUTH_ERROR_FAILURE (#6): Client aborted authentication. (telepathy-gabble:3737): tp-glib/connection-DEBUG: tp_base_connection_change_status: was 1, now 2, for reason 3 On another Fedora 16 machine, I *can* log in, but I get asked to confirm my acceptance of the SSL certificate before I do so. The corresponding part of the debug log looks like this: (telepathy-gabble:11365): gabble-DEBUG: gabble_server_tls_manager_verify_async (server-tls-manager.c:219): verify_async() called on the GabbleServerTLSManager. (telepathy-gabble:11365): gabble-DEBUG: gabble_server_tls_channel_constructed (server-tls-channel.c:247): Server TLS channel constructed at /org/freedesktop/Telepathy/Connection/gabble/jabber/lalalalalala_40googlemail_2ecom_2fee4f26a3/ServerTLSChannel (telepathy-gabble:11365): tp-glib/connection-DEBUG: tp_presence_mixin_get_contacts_dbus_property: called. (telepathy-gabble:11365): gabble-DEBUG: gabble_tls_certificate_accept (tls-certificate.c:264): Accept() called on the TLS certificate; current state 0 (telepathy-gabble:11365): gabble-DEBUG: tls_certificate_accepted_cb (server-tls-manager.c:176): TLS certificate accepted The dialog I get on the "working" machine is odd; it says "This certificate is self-signed", but then in the details of the certificate it is clear that it's signed by Equifax. So I have no clue what it's complaining about anyway.
If I run empathy-auth-client manually, it manages to log in OK.
Rebooting (the first reboot since I installed telepathy) seems to make that problem go away, although the error handling looks to be broken and it's not clear why a reboot was necessary. Now I have other issues. I log in to two separate accounts from the two separate F16 machines. There is 'shinybook' logged in as myself, and 'lenovo' logged in as another user. Logs here: http://david.woodhou.se/gabble-lenovo-calls-shinybook.txt http://david.woodhou.se/gabbel-shinybook-called-by-lenovo.txt As you might infer from the filenames, the 'lenovo' machine is making an outbound call to 'shinybook'. I was going to do it the other way round, but on *shinybook*, right-clicking on the user in empathy showed the 'audio call' and 'video call' options greyed out. So I called 'shinybook' from 'lenovo'... a notification of the incoming call appears on shinybook, but on trying to manoeuvre the mouse over it using my trackpad, it disappeared. Then I wasn't sure how to accept the call at all. It was still making a noise at me, but wasn't clear what I was supposed to do. Thankfully, clicking on the calling user in empathy brought up another dialog asking if I wanted to accept the call. So I clicked 'accept' and a call window came up. It said 'Connecting...' for a few seconds, and then 'Connected'. I looked back at the *calling* machine, which said 'Disconnected'. Look back at the callee, which still thinks it's connected. Confused now...
Next attempt. This time for some reason the shinybook *does* let me make calls to the lenovo, so I made a video call. (The lenovo doesn't have a camera but I ought to get one-way video, right?). I don't get any video at all though; I get an error on the Lenovo side saying Can't establish video stream There was a failure in the call engine Technical Details: Could not link source http://david.woodhou.se/gabble-shinybook-video-call-to-lenovo.txt http://david.woodhou.se/gabble-lenovo-receives-video-call.txt
I am also unable to login into google chat. I have tried not using the option to remember password. I would expect it then to ask for my password when logging in, but it does not. Seems strange. I think something is wrong with the authentication code.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.