After 46bb820be3 `init_by_resolv_conf`
errors are no longer swallowed in `ares_init_options`. This has exposed
a previously unknown bug in `lookups` initialization code.
If there is no lookup configuration in `resolv.conf`,
`init_by_resolv_conf` will attempt to read it from other files available
on the system. However, some of these files may have restricted
permissions (like `600`), which will lead to `EACCESS` errno, which in
turn is handled like a fatal error by `init_by_resolv_conf`.
However, it sounds illogical that this error should be handled as a
fatal. There is a `init_by_defaults` call that overrides `lookups` with
default value, and certainly possible absence of lookup information is
the reason why this function exists in a first place!
I suggest handling any `fopen` errors as non-fatal ones, allowing to
pick up the `lookups` value from different config files, or to pick up
default value.
Add user-visible entrypoints ares_{get,set}_servers_ports(3), which
take struct ares_addr_port_node rather than struct ares_addr_node.
This structure includes a UDP and TCP port number; if this is set
to zero, the channel-wide port values are used as before.
Similarly, add a new ares_set_servers_ports_csv(3) entrypoint, which
is analogous to ares_set_servers(3) except it doesn't ignore any
specified port information; instead, any per-server specified port
is used as both the UDP and TCP port for that server.
The internal struct ares_addr is extended to hold the UDP/TCP ports,
stored in network order, with the convention that a value of zero
indicates that the channel-wide UDP/TCP port should be used.
For the internal implementation of ares_dup(3), shift to use the
_ports() version of the get/set functions, so port information is
transferred correctly to the new channel.
Update manpages, and add missing ares_set_servers_csv to the lists
while we're at it
Allow explicit configuration of the channel's sortlist, by
specifying a string in the same format as the equivalent
/etc/resolv.conf option.
This allows library users to perform the same configuration
that is available via /etc/resolv.conf, but without needing
to change that file.
Add a new ares_library_init_mem() initialization function for the
library which allows the library user to specify their own malloc,
realloc & free equivalents for use library-wide.
Store these function pointers in library-wide global variables,
defaulting to libc's malloc(), realloc() and free().
Change all calls to malloc, realloc and free to use the function pointer
instead. Also ensure that ares_strdup() is always available
(even if the local environment includes strdup(3)), and change the
library code to always use it.
Convert calls to calloc() to use ares_malloc() + memset
Add comments for the benefit of the lcov tool, marking
lines that cannot be hit. Typically these are fall-back
protection arms that are already covered by earlier checks,
and so it's not worth taking out the unhittable code (in case
someone changes the code between the two places in future).
If we get an allocation failure on 2nd or later entry in the sortlist, the
code would return ENOMEM but still leave the initial entries allocated.
Ensure that *sortlist is set to NULL whenever ENOMEM is returned.
If the attempt to transfer IPv6 servers from the old to the new channel
fails, the previous code would still return a channel to the user even though
an error return code was generated. This makes it likely that users would
leak the channel, so explicitly clear the channel in this case.
If (say) init_by_options() fails, the subsequent call to
init_by_defaults() was overwriting the return code with
success. Still call init_by_defaults() regardless, but track
its return value separately
Update for commit affc63cba8.
The original patch from Gregor Jasny did not have the break
statement; I incorrectly added it to prevent continuing the loop.
However, the later entries in the array would then be left
uninitialized, causing problems for later cleanup.
So fix to match Gregor's original patch, with apologies.
On iPhone targets like iOS, watchOS or tvOS the file
/etc/resolv.conf cannot be used to configure cares.
Instead the resolver library is queried for configuration
values.
CC: Yury Kirpichev <ykirpichev@yandex-team.ru>
This patch is fixing the dns lookup issue due to dummy dns information
of a disconnected adapter(in my case is a bluetooth adapter). I changed
the dns lookup policy to try GetNetworkParams first because the
GetNetworkParams provides the most reliable dns information (lots of
checks were done by system). I also filter out inoperable adapter in
DNS_AdaptersAddresses in case GetNetworkParams fail.
It's possible that, if ares_save_options failed, the opts structure
would contain some allocated memory. Calling ares_destroy_options in
this case is safe, because ares_save_options zeroes out the memory
initially.
When attempting to build a search domain from the local hostname
(used as a fallback when no other methods have given a search
domain), the code doubles the buffer size on each loop iteration.
However, the loop previously had a WHILE_FALSE terminator so the continue
statement exited the loop rather than going round again.
Make sure that the symbols are always exported and present in c-ares.
Make the headers prefixed with 'ares'.
Removed the inet_ntop.h version as it no longer features any content.
The UDP and TCP port are stored in network byte order in the
ares_channeldata, but are passed in to ares_init_options() in host byte
order. Thus we must return them from ares_save_options() in host byte
order too, or a duplicated channel will convert them again, leading to a
nonfunctional channel and a mysterious connection refused error from
ares_gethostbyname(). This breaks ares_dup(), thus the curl easy API
when c-ares is used by curl, and thus all the curl easy API's users.
Before, c-ares always used the first DNS server on Android, causing
network problems if this DNS server was not available.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
I experienced a buffer overrun exception in c-ares on Windows and
tracked it down to be an error in the calculation of the 'left' variable
in get_iphlpapi_dns_info().
I changed the variable type of 'left' to a _signed_ type because of the
subtraction arithmetic; not sure if a long is the best choice
Without an else there, contents of "pat" that could have been
successfully set just above, may be clobbered by successive unsuccessful
calls to "xxx_pton" or "ip_addr".
