[ There is some blabla here about SRV records, See last paragraph for the direct solution ]
Recently, the bus home was replaced with a shiny new one, which also provides Wi-Fi access. That's brilliant - as long as I have a seat, I don't mind how long the ride home takes. I just hope it doesn't radiate too much =)
Anyway, I've noticed that I fail to connect to Google talk through my favorite client, Pidgin, when connected to this Bus' wireless LAN. It's really fun to do some debugging with xterm and wireshark with passengers watching with curiosity.
And to the point - I'm not sure where this standard is defined (XMPP?), but Google recommends setting the Google Talk "domain" as gmail.com. But where is the XMPP server ip/name taken from? It's not gmail.com, as the telnet gmail.com 5222 fails.
Quick sniffing tells that my pidgin (and probably other clients) use DNS SRV records. SRV records (RFC2782) are a pretty neat idea: it lets you query your domain for services. Why remember (or worse: guess) what's the name of the SMTP server? Instead, SRV records suggest a way to ask a domain what's the IP of the domain's major SMTP service.
The DNS name is of the following structure: _<service name>._<protocol>.domain.
In our case: _xmpp-client._tcp.gmail.com. Let's run this nice command line:
# host -t SRV _xmpp-client._tcp.gmail.com
_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk2.l.google.com._xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk3.l.google.com._xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk4.l.google.com._xmpp-client._tcp.gmail.com has SRV record 5 0 5222 talk.l.google.com._xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk1.l.google.com.
So briefly, each SRV record holds host name, port number, priority and weight. A single service may have several records, thus providing some kind of high availability and load balancing.
SRV records are intensively used in Microsoft Domains since Windows 2000, and it's even possible that they invented it (they're signed in the RFC after some non-microsoft guy). In that case, kudos to Microsoft for either inventing or pushing forward a good technological standard. Haven't seen this frequently.
So, it seems that the DNS in this bus disrespects my SRV queries, and thus my Pidgin can't figure out who is the Google Talk server. Setting another DNS server solved the problem.
I have the same problem in collage with empathy, how exactly did you fix it?
How do you set a dns server?
I have been getting dissconnections from Bezeq and Netvision for months now ((also using pidgin, but also psi), from both google talk and jabber. Do yo think this might be the case too?
Well I guess I wasn't clear enough 🙂
In my case, the default (DHCP-sent) DNS *server* didn't cope with SRV queries.
So that
$ host -t SRV _xmpp-client._tcp.gmail.com query just failed.
Fortunately, I had access to netvision's DNS server, so the command
$ host -t SRV _xmpp-client._tcp.gmail.com 194.90.1.5
Simply worked.
So the only thing to solve was update /etc/resolv.conf with a working DNS server.
There are publicly available DNS servers such as OpenDNS and Google's DNS (8.8.8.8, 8.8.4.4).
If there's a case that the *router* (or firewall) filters the SRV queries, then I guess that there's no easy solution there. Maybe configuring the clients to use 'talk.l.google.com' would help, if clients would also try A record query after SRV has failed.
Ok, next time it falls here I'll test and update on
host -t SRV _xmpp-client._tcp.gmail.com
At the moment its strangely working.
Google has a good and easy to remember public DNS servers - 8.8.8.8 and 8.8.4.4. I'm not sure if and how they are spying users who use these service, but it is far easier to remember than 194.90.1.5...