Adium will not connect if host has AAAA record and IPv6 unavailable

[jorj]

If the jabber server has both A and AAAA records, and the client has no IPv6 connectivity, Adium 1.4hgr2538 reports "Network Offline" and refuses to connect, even though the IPv4 path is clear.

[jorj]

I've confirmed this behavior as far back as hgr2190, so it is not caused by a recent change.

[erdgeist]

I've uploaded a patch that will skip any sockaddr record returned by CFHostGetAddressing that is not of AF_INET. While I could not actually build the file, it's intention should be clear.

Another thing: why is it binding to 127.0.0.1 and not to 0.0.0.0, as it should in

inet_aton("127.0.0.1", &localAddr.sin_addr);

I wonder why that works, anyway.

[erdgeist]

A patch that searches for the first AF_INET sockaddr returned, since Adium speaks v4 only, ATM

[erdgeist]

Finally compiled Adium locally and fixed a dereference problem in my patch.

[jorj]

Not sure what "since Adium speaks v4 only, ATM" means, since I connect over IPv6 regularly. (An important feature for me, too.)

[zacw]

Indeed, this patch will not work for XMPP servers that specify AAAA (AF_INET6 addresses) and no A records. A better fix would allow both to work.

[Zachary West <zacw@…>]

(In  f8d77bb2192d) Add an observer for both AF_INET (IPv4) and AF_INET6 (IPv6) DNS records for connection hosts. Fixes #12632.

When we're determining reachability, we consult all entries for a host, instead of the one that changed. We only add one observer for each record type.

[Zachary West <zacw@…>]

(In  6ba5f8f8102a) Add an observer for both AF_INET (IPv4) and AF_INET6 (IPv6) DNS records for connection hosts. Fixes #12632.

When we're determining reachability, we consult all entries for a host, instead of the one that changed. We only add one observer for each record type.

[zacw]

Ticket #12967 has been marked as a duplicate of this ticket.

[jorj]

This appears to have regressed as of 1.5hgr3055.

[jorj]

Seems it was probably earlier that it broke - I had a teredo tunnel enabled and forgot about it. I'll see about tracking down where it died when I have a chance.

Logs:

16:05:24: (Libpurple: account) Connecting to account jorj@upenn.edu/Adium.
16:05:24: (Libpurple: connection) Connecting. gc = 0x1187a5c20
16:05:24: Connecting: gc=0x187a5c20 (Connecting) 1 / 5
16:05:24: (Libpurple: dns) DNS query for 'jabber.upenn.edu' queued
16:05:24: ************ jorj@upenn.edu --step-- 1
16:05:24: -[AdiumPurpleDnsRequest startLookup]: Performing DNS resolve: jabber.upenn.edu:5222
16:05:24: DNS resolve complete for jabber.upenn.edu:5222
16:05:24: (Libpurple: dnsquery) IP resolved for jabber.upenn.edu
16:05:24: (Libpurple: proxy) Attempting connection to ::2001:468:1802:101:0:0
16:05:24: (Libpurple: proxy) Connecting to jabber.upenn.edu:5222 with no proxy
16:05:24: (Libpurple: proxy) Connection attempt failed: No route to host
16:05:24: (Libpurple: jabber) Couldn't connect directly to upenn.edu. Trying to find alternative connection methods, like BOSH.
16:05:24: (Libpurple: dnssrv) querying TXT record for upenn.edu: _xmppconnect.upenn.edu
16:05:24: (Libpurple: dnssrv) res_query returned an error
16:05:24: (Libpurple: connection) Connection error on 0x1187a5c20 (reason: 0 description: Unable to find alternative XMPP connection methods after failing to connect directly.)
16:05:24: Connection Disconnected: gc=187a5c20 (Unable to find alternative XMPP connection methods after failing to connect directly.)
16:05:24: <ESPurpleJabberAccount:16d2efe0 16>:jorj@upenn.edu accountConnectionReportDisconnect: Unable to find alternative XMPP connection methods after failing to connect directly.
16:05:24: (Libpurple: account) Disconnecting account jorj@upenn.edu/Adium (0x118754d00)
16:05:24: (Libpurple: connection) Disconnecting connection 0x1187a5c20
16:05:24: Disconnected: gc=187a5c20
16:05:24: <ESPurpleJabberAccount:16d2efe0 16>:jorj@upenn.edu: Telling the core we disconnected
16:05:24: <ESPurpleJabberAccount:16d2efe0 16>:jorj@upenn.edu: Disconnected ("Unable to find alternative XMPP connection methods after failing to connect directly."): Automatically reconnecting in 5.000000 seconds (0 attempts performed)

[evands]

The log above is a failed connection attempt, not a failure of the autoconnect subsystem to realize the host is available. I have not retested the original problem here, but Zac's fix looks reasonable. I'm closing this as fixed. Please reopen if the original problem has in fact recurred.

Please open a new ticket for this libpurple connection failure, if that's the new actual problem being reported.