Resolving addresses with A and AAAA entries may fail in some cases

[maksis]

Consider the following case:

1. The client tries to connect to an address that has both A and AAAA entries
2. ::getaddrinfo returns the AAAA entry first
3. The client tries to connect via IPv6 but there's no IPv6 connectivity available (or it doesn't work for other reasons)
4. Socket::connect throws immediately instead of continuing with the A entry

I haven't seen this happening on Windows because it doesn't seem to return the AAAA entry if there is no (public) IPv6 connectivity available. However, Linux systems seem to generally return the AAAA first by default, regardless of the available connectivity. The attached patch should fix this issue.

[maksis (maksis)]

"In Progress: The assigned person is working on it."

Hmm?

[Fredrik Ullner (ullner)]

I have moved any bug that contains a patch that is previously unattended and should be looked at more closely.

[poy (poy)]

in rev 3382.

i changed the success check to rely on errors rather than an IP being set.

[maksis (maksis)]

The edit that you made is wrong so the problem remains.

If resolving the first address fails, lastError gets set. The client will still continue with the other addresses and they may success, but since the error was set, the function will throw. Maybe lastError isn't a good name for it though. You either need to clear the error in case of successful attempt, use a success bool, or just check if the IP was set to avoid adding an extra bool :p

[maksis (maksis)]

Or the purpose of "lastError" was to explain that it only stores the last error that was received... there may have been other errors as well

[maksis (maksis)]

.... my bad, even clearing the error wouldn't work, as one of the later attempts may still set it (I've already forgotten what I was thinking when I made that fix...). That fix is part of the latest stable versions of AirDC++ and AirDC++ nano so I consider it to be reliable. The version URL used by AirDC++ has A and AAAA records which makes noticing such errors easy (even though I missed this bug first because I have IPv6 connectivity on every Linux machine...).

[maksis (maksis)]

... and what comes to the bug description, this is more about fixing connections to IPv4 addresses when IPv6 isn't available/functioning properly (it's not often the other way around)

[poy (poy)]

indeed... try rev 3383 (not tested).

[maksis (maksis)]

It's still doesn't work in the same way as my original patch. Please read this: https://bugs.launchpad.net/dcplusplus/+bug/309402/comments/23

It should try connect via both protocols according to the original idea, and I'd say that it's worth of keeping like that (for some reason I've had quite a few issues with IPv6...). Your commit changes that behavior.

[poy (poy)]

ok, rev 3384 has your initial version.

[maksis (maksis)]

It doesn't, now the function throws if the IP is set :p

[poy (poy)]

fixed in rev 3386...

[poy (poy)]

Fixed in DC++ 0.840.