IPv6-enabled client fails to connect to IPv4-only hosts
Development toolkit for Web Services and XML data bindings for C & C++
Brought to you by:
engelen
tcp_connect in stdsoap2.cpp calls
err = getaddrinfo(host, soap_int2s(soap, port), &hints, &res);
and later
#ifdef WITH_IPV6
if (connect(sk, res->ai_addr, (int)res->ai_addrlen))
However, when the connect call returns ECONNREFUSED - which is possible if a server process listens on IPv4 only -, gsoap will not attempt to try res->ai_next.
I'm having IPv6 problems with a certain app and the developer thinks it is a gSOAP problem (although he has provided a workaround for his software too). Discussion is here: http://kin.klever.net/iii#comment-1222008691
He points to this gSOAP patch that Jan has proposed: https://build.opensuse.org/package/view_file?file=gsoap-05-ipv6.diff&package=gsoap&project=home%3AGrieff&rev=4756be2c2b3d5de90bb1f82aa28ae0ba
I'd like to know if this is going to be applied any time soon.
Thank you in advance.
A patch based on the above mentioned opensuse patch.
I am very sorry, but this patch is IMHO not the ultimate answer for this issue.
Fedora is shipping gSOAP with IPv6 enabled as part of the distribution; system itself is dual-stacked for example. If now a software, in this case Zarafa, is linked against the system gSOAP it tries to connect using tcp_connect() always to IPv6 (if the DNS name resolves to IPv6 (and IPv4)). Looking into it using strace(1) the connect() call to ::1 returns EINPROGRESS but the SOAP server is not IPv6 enabled (not listening on IPv6, just IPv4). There is no retry afterwards using IPv4 (like telnet(1) does) and I wasn't able to find a run-time option (but I might be wrong with last).
Just post the right patches.
First,
https://build.opensuse.org/source/devel:libraries:c_c++/gsoap/gsoap-05-ipv6.diff?rev=19a0c675af967e93bce41d4d4a5611ab
is needed because IPV6_V6ONLY on an AF_INET will fail and make gsoap bail out.
Second, something like
https://build.opensuse.org/source/devel:libraries:c_c++/gsoap/gsoap-06-ipv6retry.diff?rev=19a0c675af967e93bce41d4d4a5611ab
is needed, so that all getaddrinfo results are tried (which is a must).
Very interesting observations and thanks for the discussion!
The improvements will be available in the upcoming 2.8.18 release.
Sorry, but
"Remove pointless casts to void *; this implicit even in C++."might be true from a purist standards point of view, but we ran into C compilers that produced warnings! We're also getting type punning warnings (in other places, and no... there are no aliases to worry about), so sprinkling (void*) here and there is ugly but ensures the intended implementation works. I don't want users to get annoyed when they can no longer compile the code on their (legacy) system.Are you still building with compilers that don't understand ANSI C?
Are you still building with compilers that don't understand ANSI C?Yep, blame me for taking our users very seriously and not treat them the cold shoulder. We have folks that still need support for DOS, VAX, Tandem and several embedded platforms that require both old and new stuff to work.
I have seen it all, working 20+ years with C/C++. Worst offenders are/used to be compilers from proprietary vendors.