gtalk accounts now need to set explicit "server" param

[el_goretto]

Hi,

bitlbee was working fine until some days ago... my gmail accounts ended up showing: gtalk - Logging in: Connecting gtalk - Login error: Connection timeout gtalk - Logging in: Signing off.. gtalk - Login error: Short write() to server

After troubleshooting a bit, I find out that the "server" param of my gtalk accounts was empty. No problem so far, but it seems that some change google side requires now it to be explicitly set to "talk.google.com". I guess bitlbee default value (i.e. when not set) is not "correct" anymore. I don't know how to "treat" this, if some text could added to help command, or some specific default param could be set (maybe not the best). Or maybe just in bitlbee regular documentation (like getting this procedure ​http://wiki.bitlbee.org/GoogleApps applied for all gtalk accounts).

[wilmer]

Several people have appeared in #bitlbee now with this problem, and I don't know what's happening. This still works for me, with a freshly-compiled-from-head binary. I wonder if something changed in libc, but no idea.

This is on a Debian testing machine. Problem has been observed on Gentoo and Arch so far AFAIK. Possibly more than just that..

There's definitely no change on Google's side. The SRV record is still there and I don't see why it'd get removed.

[wilmer]

trac3r in #bitlbee could sometimes reproduce it and found out his home router's caching DNS server was sometimes serving empty responses for the SRV request.

​http://pastebin.com/uT546Wmw

What NS are you using, and do you see similar behaviour? Does the problem go away when you switch to another nameserver?

[el_goretto]

Hi, I'm using indeed DNS cache from dnsmasq in OpenWRT (trunk when problem arised, now backfire). Your idea may be right:

$ dig @8.8.8.8 talk.google.com SRV [...] ; ANSWER SECTION: talk.google.com. 43141 IN CNAME talk.l.google.com.

$ dig talk.google.com SRV --> empty reply (server section refers to my local router).

[el_goretto]

Hi again, I did some search, and narrowed it down to this, as every SRV request (on talk.google.com) I made was getting an empty answer:

--filterwin2k

Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by triggering dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests.

They may have a bug as our SRV request doesn't imply an underscore. Disabling this filter seems to fix it.

I'll have a look later if this is a bug of dnsmasq or a "feature" and they didn't updated their manpage.

[wilmer]

Wow. That must be the most retarded feature they could ever think of, if it's enabled by default.

The SRV request does in fact have an underscore BTW, as it should according to the standard: ​http://xmpp.org/rfcs/rfc3920.html#rfc.section.14.3

[ceilfors]

It would be nice if the Gtalk wiki is updated to include the port change too. I couldn't manage to connect to Gtalk server until I change the port from 5222 to 5223.

[wilmer]

No, that should *not* be done. If you had to change the port# to 5223 you were doing something wrong because that's the extremely obsolete raw-SSL (as opposed to starttls recommended by XMPP RFCs for years already) port. Likely you set "ssl" to true as well?

[ceilfors]

Glad I'd asked! I should have checked the help command from bitlbee first. The help for ssl and tsl settings explain them very well. I was following the wiki as my server param was empty too; it asked me to set the ssl to true at the very bottom. Sorry for the trouble.