telepathy-gabble 0.9.11-1~ppa10.04+1 breaks facebook login

[Ronan Jouchet]

Hello,

- Using Ubuntu 10.04 stock 0.8.12-0ubuntu1, Empathy logs in Facebook chat
correctly (I can see friends and chat with them)
- Using 0.9.11-1~ppa10.04+1, the login is unsuccessful and Empathy shows its
red "Network error" header; please see the attached log

I'm using Empathy 2.30.1 (from Telepathy official PPA) under Ubuntu 10.04 x86

[Ronan Jouchet (ronj)]

Bug on Launchpad: https://bugs.launchpad.net/empathy/+bug/578265

[Ronan Jouchet (ronj)]

Hello,

- Using Ubuntu 10.04 stock 0.8.12-0ubuntu1, Empathy logs in Facebook chat
correctly (I can see friends and chat with them)
- Using 0.9.11-1~ppa10.04+1, the login is unsuccessful and Empathy shows its
red "Network error" header; please see the attached log

I'm using Empathy 2.30.1 (from Telepathy official PPA) under Ubuntu 10.04 x86

[Ronan Jouchet (ronj)]

I couldn't properly register the upstream bug: LP doesn't seem to know telepathy uses freedesktop bugzilla and doesn't asks me for an bugzilla link. Can somebody set this up?
So I registered it as an Empathy bug, linked against Freedesktop bugzilla bug

[Dominique-freedesktop-org (dominique-freedesktop-org)]

Same can be observed on openSUSE Factory with Empathy 2.30.1 and telepathy-gabble 0.9.11.

[Brian Curtis (bcurtiswx)]

Thanks for your bug report and helping to make Ubuntu better. This is a Gabble problem not empathy. Upstream might have an issue with this being a PPA, but we'll wait for their input first.

[Ronan Jouchet (ronj)]

Brian,

Thanks for correcting this; I assigned to Empathy because it was the only way I found to link to the upstream freedesktop bug.
How did you assign properly the upstream bug to telepathy-gabble??

[Brian Curtis (bcurtiswx)]

The "Also Affects Project" link at the top allows you to do so.

[Will Thompson (wjt)]

(In reply to comment #0)
> - Using Ubuntu 10.04 stock 0.8.12-0ubuntu1, Empathy logs in Facebook chat
> correctly (I can see friends and chat with them)
> - Using 0.9.11-1~ppa10.04+1, the login is unsuccessful and Empathy shows its
> red "Network error" header; please see the attached log

So I seem to remember someone saying that Facebook's SRV record is wrong. But it seems like LM copes (if 0.8 works) so maybe we should fix GResolver to cope, too.

[Will Thompson (wjt)]

I've just tested this on Debian using telepathy-gabble 0.9.11, and it works fine for me. The SRV look-up fails, so it falls back to connecting to chat.facebook.com, which works.

Could you try again to see if this still occurs? It might have been a transient issue. If so, please could you get another debug log, this time setting WOCKY_DEBUG=all as well as GABBLE_DEBUG=all ? Thanks!

(Also, what version of libglib2.0-0 do you have installed?)

[Ronan Jouchet (ronj)]

Hello Will, Dominique,

1. The problem still persists for me. Dominique, same for you?
2. My libglib2.0-0 is the standard ubuntu 10.04 version, 2.24.0-0ubuntu4
3. I noticed the logs returned by the "gabble" dropdown item in Help>Debug are actually all relative to my GTalk account. When I disable it (making facebook as my only gabble account), there is no gabble log (no "gabble" item in the dropdown, the only items I have are Empathy, mission-control and butterfly)! Any idea why? How can I produce a log anyway to know what's going on on gabble side?

[Will Thompson (wjt)]

(In reply to comment #5)
> Hello Will, Dominique,
>
> 1. The problem still persists for me. Dominique, same for you?
> 2. My libglib2.0-0 is the standard ubuntu 10.04 version, 2.24.0-0ubuntu4
> 3. I noticed the logs returned by the "gabble" dropdown item in Help>Debug are
> actually all relative to my GTalk account. When I disable it (making facebook
> as my only gabble account), there is no gabble log (no "gabble" item in the
> dropdown, the only items I have are Empathy, mission-control and butterfly)!
> Any idea why? How can I produce a log anyway to know what's going on on gabble
> side?

Are you sure your Facebook account is using XMPP? In the Empathy account dialog, does it have a blurb about "if your facebook profile is http://facebook.com/badger, enter 'badger'"? If not, you're using the old-school screen-scraping libpurple implementation of Facebook chat via Haze; try deleting your account and creating a new Facebook account.

[Ronan Jouchet (ronj)]

Yes, I see the text you are mentioning.
I tried removing and recreating the account, same result.

Do you see a way for me to provide you more logs?

[Will Thompson (wjt)]

(In reply to comment #7)
> Yes, I see the text you are mentioning.
> I tried removing and recreating the account, same result.
>
> Do you see a way for me to provide you more logs?

Follow <http://telepathy.freedesktop.org/wiki/Debugging#Gabble>.

[Ronan Jouchet (ronj)]

I already had set the WOCKY_DEBUG and GABBLE_DEBUG env variables to all. But even with this, there is no "gabble" in the dropdown list in the Debug log...

Also, I tried logging in with a manually configured Jabber account, it doesn't work (should it?).
Login ID: my facebook name
Resource: {Empathy, Pidgin}
Priority: 0
Server: chat.facebook.com
Port: 5222

[Will Thompson (wjt)]

(In reply to comment #9)
> I already had set the WOCKY_DEBUG and GABBLE_DEBUG env variables to all. But
> even with this, there is no "gabble" in the dropdown list in the Debug log...

You have to start Gabble manually from a terminal with those options, and you get debug output in the terminal. http://telepathy.freedesktop.org/wiki/Debugging explains how to do so.

> Also, I tried logging in with a manually configured Jabber account, it doesn't
> work (should it?).
> Login ID: my facebook name

<email address hidden>

> Resource: {Empathy, Pidgin}
> Priority: 0
> Server: chat.facebook.com
> Port: 5222

but otherwise this is roughly what the Facebook option in Empathy does.

[Ronan Jouchet (ronj)]

Goooood!

1. Logging in to Facebook chat with a normal Jabber account and correct login information (<email address hidden>, Resource=Empathy, Priority=0, Server=chat.facebook.com, Port=5222) works in 0.9.11
2. Thanks for pointing me to this part of the documentation, I had missed it when you first mentioned this wiki page. The results are in the new attached log (gabble_terminal_DEBUGALL.log)

[Ronan Jouchet (ronj)]

Created an attachment (id=35656)
gabble_terminal_DEBUGALL

[Ronan Jouchet (ronj)]

First log didn't show anything anything, preparing a new one.

[Ronan Jouchet (ronj)]

Created an attachment (id=35657)
gabble_terminal_DEBUGALL_good

Proper command-line debug log.

[Guillaume-desmottes (guillaume-desmottes)]

Not sure if it's related but https://bugzilla.gnome.org/show_bug.cgi?id=618375 reports issue regarding facebook:

gabble/connection-DEBUG: 17-05-2010 14:13:48.13353: connector_error_disconnect: connection failed: Bad SRV record: Unknown error on connect

[Andrea Calabrò (mastropino)]

A workaround is this:
Make a new Jabber account

Login:
<email address hidden>

Override server settings:
chat.facebook.com
5222

[Simon McVittie (smcv)]

Relevant CM parameters:

(telepathy-gabble:10152): tp-glib/params-DEBUG: tp_cm_param_setter_offset: account = "<email address hidden>"
(telepathy-gabble:10152): tp-glib/params-DEBUG: tp_cm_param_setter_offset: password = <hidden>
(telepathy-gabble:10152): tp-glib/params-DEBUG: parse_parameters: server not given, using default behaviour
(telepathy-gabble:10152): tp-glib/params-DEBUG: tp_cm_param_setter_offset: port = 5222 = 0x1466
(telepathy-gabble:10152): tp-glib/params-DEBUG: tp_cm_param_setter_offset: old-ssl = FALSE

So we'll connect to the result of a SRV lookup for _xmpp-client._tcp.chat.facebook.com, or failing that, to chat.facebook.com. However, the SRV lookup fails, and fails with an error that doesn't cause us to fall back.

For anyone who gets this bug, I'd be interested to see the results of these two commands on the same machine:

host -t SRV _xmpp._tcp.chat.facebook.com

host -v -t SRV _xmpp._tcp.chat.facebook.com

From the GIO source code, it seems that the error you got, "Unknown error on connect", is raised with code G_IO_ERROR_FAILED if g_socket_address_enumerator_next or g_socket_address_enumerator_next_finish returns NULL without setting its @error parameter. That looks like a GIO bug, because g_socket_address_enumerator_next returns NULL without setting @error if there are no more addresses... GIO should probably set a more specific error code for that.

Wocky, in turn, interprets the domain G_IO_ERROR to be fatal:

      /* An IO error implies there IS a SRV record but we could not
       * connect: we do not fall through in this case: */

[Simon McVittie (smcv)]

Reducing severity: this works in at least some networks (we can't reproduce it here). If this bug affects you, please provide the information I requested in Comment #16 and we can try to work out what's going wrong.

[Simon McVittie (smcv)]

Passing on my request from the upstream bug report:

This doesn't seem happen on all networks (I can't reproduce the bug here). If this bug affects you, please provide the output of these commands, and we might be able to work out what's causing it to fail for you:

host -t SRV _xmpp._tcp.chat.facebook.com

host -v -t SRV _xmpp._tcp.chat.facebook.com

[Will Thompson (wjt)]

(In reply to comment #17)
> Reducing severity: this works in at least some networks (we can't reproduce it
> here). If this bug affects you, please provide the information I requested in
> Comment #16 and we can try to work out what's going wrong.

I can now reproduce this on one of my internet connections, and have worked around it in Wocky. The problem is that _xmpp-client._tcp.chat.facebook.com is a CNAME for chat.facebook.com, rather than an SRV record.

See http://git.collabora.co.uk/?p=user/wjt/wocky.git;a=commitdiff;h=refs/heads/work-around-chat.facebook.com for the patch!

 % host -t SRV _xmpp-client._tcp.chat.facebook.com
_xmpp-client._tcp.chat.facebook.com is an alias for chat.facebook.com.
 % host -v -t SRV _xmpp-client._tcp.chat.facebook.com
Trying "_xmpp-client._tcp.chat.facebook.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19955
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;_xmpp-client._tcp.chat.facebook.com. IN SRV

;; ANSWER SECTION:
_xmpp-client._tcp.chat.facebook.com. 7 IN CNAME chat.facebook.com.

;; AUTHORITY SECTION:
facebook.com. 37 IN SOA glb01.sf2p.tfbnw.net. hostmaster.facebook.com. 2157 10800 3600 604800 60

Received 134 bytes from 192.168.99.1#53 in 43 ms

[Simon McVittie (smcv)]

(In reply to comment #18)
> I can now reproduce this on one of my internet connections, and have worked
> around it in Wocky.

review+

[Will Thompson (wjt)]

Merged to Wocky master, and into Gabble! Will be fixed in Gabble 0.9.18.

[Simon McVittie (smcv)]

It's not just Facebook, <https://bugzilla.gnome.org/show_bug.cgi?id=629209> also seems to be this server misconfiguration:

smcv@reptile% dig -t SRV _xmpp-client._tcp.jabber.rwth-aachen.de

; <<>> DiG 9.7.1-P2 <<>> -t SRV _xmpp-client._tcp.jabber.rwth-aachen.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22023
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;_xmpp-client._tcp.jabber.rwth-aachen.de. IN SRV

;; ANSWER SECTION:
_xmpp-client._tcp.jabber.rwth-aachen.de. 172639 IN CNAME vm01.jabber.rwth-aachen.de.

;; AUTHORITY SECTION:
rwth-aachen.de. 10759 IN SOA zs1.rz.rwth-aachen.de. hostmaster.rwth-aachen.de. 2010091007 43200 7200 1814400 10800

;; Query time: 4464 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 10 13:24:34 2010
;; MSG SIZE rcvd: 130

[Simon McVittie (smcv)]

RFC 2782 says:

   A SRV-cognizant client SHOULD use this procedure to locate a list of
   servers and connect to the preferred one:

        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
        QTYPE=SRV.

        If the reply is NOERROR, ANCOUNT>0 and there is at least one
        SRV RR which specifies the requested Service and Protocol in
        the reply:

            [...]

        else

            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A

So our workaround is right, but GLib probably shouldn't be failing with such a nonspecific error: it should just go for the A record itself.

[Simon McVittie (smcv)]

Forwarded to https://bugzilla.gnome.org/show_bug.cgi?id=629274