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

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

(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.

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?)

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?

(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.

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?

(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>.

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

(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

your.facebook.name@chat.facebook.com

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

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

Goooood!

1. Logging in to Facebook chat with a normal Jabber account and correct login information (LoginID=my.facebook.name@chat.facebook.com, 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)

Created attachment 35656 [details]
gabble_terminal_DEBUGALL

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

Created attachment 35657 [details]
gabble_terminal_DEBUGALL_good

Proper command-line debug log.

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

Relevant CM parameters:

(telepathy-gabble:10152): tp-glib/params-DEBUG: tp_cm_param_setter_offset: account = "bla.bla@chat.facebook.com"
(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: */

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.

(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

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

review+

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

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

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.

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