Thanks for the update, the functionality seems better but strange. It
connects to both addresses and closes then, and then makes a third connection to do the actual work.

I think the correct functionality is to connect to each address in turn and
use the first one that works. Below is an extract from "strace xmppc -m message chat $ADDR".

connect(3, {sa_family=AF_INET, sin_port=htons(5222), sin_addr=inet_addr("144.76.186.21")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(57596), sin_addr=inet_addr("115.64.7.71")}, [28 => 16]) = 0
close(3) = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(5222), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2a01:4f8:200:641c::d0d0:c0de", &sin6_addr), sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(43981), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2001:4479:6804:6c00:c472:15ff:fe25:e183", &sin6_addr), sin6_scope_id=0},
[28]) = 0
close(3) = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(5222), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2a01:4f8:200:641c::d0d0:c0de", &sin6_addr), sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Feedback from upstream. The first and second call is because of
resolver routines. The 3. connection is the "libstrophe"
connection.

When I understood well, the reason of the bugs was a wrong IPv6
configuration. After failed IPv6 connection, libstrophe didn't
try IPv4 as fallback. Am I right?

TIL: There are some information in RFC 6724 - Default Address
Selection for Internet Protocol Version 6 (IPv6).

--
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)