#988 closed task (notmyfault)

gtalk accounts now need to set explicit "server" param

Reported by: el_goretto Owned by:
Priority: normal Milestone:
Component: BitlBee Version: 3.0.5
Keywords: gtalk server Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro: Gentoo



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 "". 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 applied for all gtalk accounts).

Attachments (0)

Change History (9)

comment:1 Changed at 2012-08-19T13:28:38Z by 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.

comment:2 Changed at 2012-08-19T15:13:43Z by 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.

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

comment:3 Changed at 2012-08-22T07:35:51Z by 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 @ SRV [...] ; ANSWER SECTION: 43141 IN CNAME

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

comment:4 Changed at 2012-08-22T07:55:17Z by el_goretto

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


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.

comment:5 Changed at 2012-08-22T08:24:08Z by 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:

comment:6 Changed at 2012-09-15T14:54:16Z by wilmer

Resolution: notmyfault
Status: newclosed

comment:7 Changed at 2013-03-05T00:09:02Z by 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.

comment:8 Changed at 2013-03-05T00:20:25Z by 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?

comment:9 Changed at 2013-03-05T13:02:27Z by 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.

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.