Long login period

Same thing started happening to me after upgrading to Leopard. I am running the latest Adium, same version as in this report. I wiped out everything in ~Library/Application Support/Adium 2.0/ and reinstalled but the issue continues to occur. I took some packet captures and don't see anything really unusual but I am not that familiar with the protocols.

This is very likely because Apple changed the behavior of getaddrinfo() in Leopard. It now appears that getaddrinfo() is making SRV requests before it makes an A record request. You'll get the delay if there are no SRV records available for the hostname.

This new behavior is following the "should" recommendation of the RFC. But a lot of DNS servers don't properly reply to SRV requests with NXDOMAIN but instead just drop the request, resulting in a timeout, and teh client retrying the SRV request again until finally it fails down to an A request. Bad DNS servers, no biscuit!

Developers, please review RFC 2782 ( http://tools.ietf.org/html/rfc2782 ) and decide if you need to be using getaddrinfo() or should rather be using gethostbyaddr() . The RFC says you should NOT use SRV requests if the protocol doesn't require them. gethostbyaddr() just makes an A record request. But for authentication requests (eg, hitting a LDAP server), SRV requests may be required, but getting the address ofthe connection hosts may not require them and an A request with gethostbyaddr() may be sufficient. :-/

developers, should this be changed this to "high", but a quick 2 line fix might fix it? change the 2 calls, rebuild, and run on Leopard, see if connectivity speed improves?

A quick search of the code shows getaddrinfo() is called in AsyncSocket.m and in adiumPurpleDnsRequest.m . I didn't find any calls to gethostbyaddr().

your sniffing should see SRV requests on port 53.

Looks like you are right. I switched the DNS from my router's forwarding service to a known external DNS server and login happened immediately.

so in english please for laymen like me :).....

DNS is how names get translated to addresses - "John Doe" to "123 main street", or actually "example.com" to "1.2.3.4" (A record). But DNS can also answer questions like "where do I send mail and what priority to check mail servers" (MX record) or "where do I send LDAP (authentication) or other special service requests" (SRV records).

In programs, there are a couple of ways to make a function call to get the address to send information or make a connection, if you know the name (get an A record). Two common ones are "getaddrinfo()" and "gethostbyaddr()".

A few years ago, somebody proposed a way of making it easier to manage how to handle "service" type requests, that is, make it easier for site admins to announce "all authentication requests go here", without application writers having to make multiple guesses. This proposal is known as "RFC 2782", and all about how it is supposed to work is described in that RFC (internet request for comments, the closest thing to THE LAW on how the Internet works).

In Leopard (10.5), Apple added this "SRV record" functionality to the "getaddrinfo()" function call. So, when this function is called, it first tries to make a SRV request to the DNS server that the client machine uses for figuring out where to go.

Unfortunately, it's not a fully perfect world. DNS requires that all fields are filled out and passed on from one server to another correctly. Some DNS servers don't properly handle SRV record requests, and they end up ignoring them instead of correctly saying "I don't know what you're talking about", so that function call thinks nobody is listening and tries again and again until it says "forget it, just tell me the plain old name to address answer (A record)", at which time the DNS server says "OK, here you go!".

SRV records and requests can be very valuable, but they're not always needed. A proposed quick fix is to change what function call the application calls from the fancy smart call (getaddrinfo()) to the nothing fancy but gets the job done one (gethostbyaddr()). In other words, if you know what you don't need, don't ask for it.

Take a look at the link about that describes RFC 2782, it's actually a pretty simple and straightforward one, relative to some of those that are out there.

How's that? :-)

Yeah, what he said. I would say further that in my case my router was configured to act as a DNS proxy, in other words it told you to come directly to it to get DNS requests and then it forwarded them to your real ISP's DNS servers. The router apparently did not properly address the SRV requests so I configured it to stop serving DNS requests. Look in your configuration and see if your DNS server is the same address as your router, if so you must have the same problem and it can probably be fixed by configuring the router to stop acting as a DNS proxy.

Thanks for clarifying all this.

I checked my router and it was acting as a DNS proxy. I turned that off but it did not have any impact on the connection speed for adium.

#8178

This is not a duplicate to 8178 since it has little to do with MSN as I am not trying to connect to MSN in this case. I am getting VERY long connection periods to all other protocols.

Just for the interim you might try the OpenDNS servers 208.67.222.222 and 208.67.220.220 and see if it works better for you.

This issue should have been resolved in Mac OS X 10.5.1.

Using the OpenDNS servers is probably not a good idea: they redirect Google traffic to their own hosts among other not-very-well-known things.

easy way to find out if it was fixed in 10.5.1, and also if this is a problem with SRV requests: sniff port 53 traffic and look at the outgoing requests. I'm willing to look at the trace if anybody wants, but I'm personally staying on 10.4 for a bit more.

I am already on 10.5.1

How do I sniff?

It still sends sends SRV requests in 10.5.1. I am not at home at the moment so I can't test it in the same environment to see if it still times out.

If you want to sniff for yourself you can use 'tcpdump -i en1 -w dumpfile' where en1 is the interface you are connecting through. Then you can open the capture file with wireshark (through Finks or elsewhere) and look at the packets. Kind of complicated if you're new to it all.

So I ran tcpdump -i en1 -w dumpfile using sudo and the strange thing is that after doing that adium connected almmost immediately. I have a dumpfile in my home dir..

-rw-r--r-- 1 root staff 24 Nov 22 18:50 dumpfile

unreadable using cat.

If a lookup for an SRV record is causing a significant slowdown there is a broken DNS server in the mix somewhere.

tcpdump files are a binary format that are not meant to be human-readable. You must use tcpdump, wireshark (used to be ethereal) to read them.

You can use 'tcpdump -e -r dumpfile port 53' to print the IP headers from the dump file that correspond to port 53 (DNS) activity.

yocalhost:~ levinela$ tcpdump -e -r dumpfile port 53 reading from file dumpfile, link-type EN10MB (Ethernet)

#8178 is not a duplicate. #8178 is about Leopard's DNS client not finding the MSN servers, and not being able to connect; this is about Adium/libpurple using an inappropriate function to look up servers (including, but not limited to, MSN's), and taking a long time to connect.

Is this still a problem with 1.2.5 and 10.5.2?

This problem appears to be resolved. Not a problem with 1.2.5 and 10.5.2.

Thanks! Larry