Added a missing call to _resolv_cache_query_failed for another fail
case where it was missing (it doesn't go through the error handling
under the "fail" label). This missing notification caused requests to
have to wait for timeout instead of beeing notified on some failed
requests.
Change-Id: I904d60269c59b926784e3a397d2a860329f55142
If two or more rapid dns requests for the same server are done
from different threads it turns into separate dns reques, if
the response of the request isn't found in the cache.
This patch avoid multiple request for the same server by
letting subsequents request wait until the first request
has finished.
Change-Id: Ic72ea0e7d3964a4164eddf866feb4357ec4dfe54
32 enteries perhaps was ok for per-process caching with ipv4 only
but adding ipv6 records makes it effectively 16 entries and making
it system wide makes is pretty useless. Increasing to 640 entries.
bug:5841178
Change-Id: I879f8bf4d3c4d8c1708bb46d46a67c1f64b1861f
When looping over the current list of sockets we are connected to,
use getpeername() not getsockname() to find out who the remote
end is. This change avoids spurious close() and (rare) failure.
Origin: ISC bug #18625 and fixed in libbind 6.0
Change-Id: I5e85f9ff4b98c237978e4bf4bd85ba0a90d768e6
This patch is used to remove private C library declarations from the
public headers (that are exported to the NDK). It should *only* be
submitted after all other patches modifying the users of said
private functions have been submitted to the tree, to avoid
breakages.
Change-Id: I0a5e3014f8e3ac9ed8df86a5cdae506337c23252
TCP isn't supported on some dns servers, which makes the old code
hang forever.
NOT adding a stopship to remove debugging stuff - it was too painful
(14s timeout on failed tcp dns lookups) so we decided not to bother people.
bug:5766949
Change-Id: I381c20c3e11b8e994438d4f7c58ef643cd36554e
This happens too frequently. We should flush a per-interface cache
when it's dns server addrs changes.
Change-Id: I8a691c96ce9a775160ef55ddb8f755d649041583
Initial commit for dns cache per interface.
Added a type that holds a reference to a
cache and name of associated interface,
address of interface, name server(s)
associated with an interface etc.
New functions to set default interface,
address of name servers etc.
Change-Id: Ie991bc5592fd998409853d8bf77d7fe69035dac5
A suggestion how to make a smarter delete function when the cache
is full. First look through the entire cache and remove all entries
which have expired. If none use the old solution and just remove
the last entry in the MRU list.
Change-Id: I5f997ab35290a55dc6e1ddf37d725759edf83d36
NOTE: This is a back-port from the internal HC branch.
This patch fixes a leak that occurs when creating a new
thread-specific DNS resolver state object.
Essentially, each thread that calls gethostbyname() or getaddrinfo()
at least once will leak a small memory block. Another leak happens
anytime these functions are called after a change of the network
settings.
The leak is insignificant and hard to notice on typical programs.
However, netd tends to create one new thread for each DNS request
it processes, and quickly grows in size after a > 20 hours.
The same problem is seen in other system processes that tend to
create one thread per request too.
The leak occured becasue res_ninit() was called twice when creating
a new thread-specific DNS resolver state in _res_get_thread().
This function could not properly reset an existing thread and was
leaking a memory block.
The patch does two things:
- First, it fixes res_ninit() to prevent any leakage when resetting
the state of a given res_state instance.
- Second, it modifies the _res_get_thread() implementation to
make it more explicit, and avoid calling res_ninit() twice
in a row on first-time creation.
Fix for Bug 4089945, and Bug 4090857
Change-Id: Icde1d4d1dfb9383efdbf38d0658ba915be77942e
This patch fixes a leak that occurs when creating a new
thread-specific DNS resolver state object.
Essentially, each thread that calls gethostbyname() or getaddrinfo()
at least once will leak a small memory block. Another leak happens
anytime these functions are called after a change of the network
settings.
The leak is insignificant and hard to notice on typical programs.
However, netd tends to create one new thread for each DNS request
it processes, and quickly grows in size after a > 20 hours.
The same problem is seen in other system processes that tend to
create one thread per request too.
The leak occured becasue res_ninit() was called twice when creating
a new thread-specific DNS resolver state in _res_get_thread().
This function could not properly reset an existing thread and was
leaking a memory block.
The patch does two things:
- First, it fixes res_ninit() to prevent any leakage when resetting
the state of a given res_state instance.
- Second, it modifies the _res_get_thread() implementation to
make it more explicit, and avoid calling res_ninit() twice
in a row on first-time creation.
Fix for Bug 4089945, and Bug 4090857
Change-Id: Ie4831a8dbe82be8f07fce5ddd1d36bf95994f836
Use system property ro.net.dns_cache_size to set
the size of the cache. If the system property
is not set the default cache size is defined by
CONFIG_MAX_ENTRIES.
The number of entries in the hash table will be equal
to the number of max entries allowed in the cache.
Change-Id: I77d69d7c178937fa483d0b40512483ad29232d28
Use the the TTL of the answer as the time a query
shall remain in the resolver cache.
Added some debugging support as well, i.e.
parse answer and print a la dig.
Change-Id: I724d3392245032592f1912f3ca7a81a8987ebbac
The problem was that the 'defdname' field of res_state structure
was not properly initialized in __res_vinit(). This field is used
to store the default domain name, which is normally build from
calling gethostname() (see line 549 of res_init.c).
Unfortunately, in the typical Android case, gethostname() returns
an error (the hostname is configured) and a random stack string is
used later to build the DNS search list (see lines 556+ in res_init.c)
For the sake of illustration, let's say the search list is set to
a random value like 'xWLK'.
The end result is that when trying to result an unknown domain name
(e.g. 'www.ptn'), the query fails then the resolver tries to make a
new query with the DNS search list path(s) appended (e.g. 'www.ptn.xWLK').
The patch simply initializes 'defdname' to an empty string to avoid
this when the net.dns.search system property is not set.
Also contains whitespace/formatting fixes
Merge commit '3773d35eb98e22b5edab4d82fb72bdf86ff80494'
* commit '3773d35eb98e22b5edab4d82fb72bdf86ff80494':
Make the DNS resolver accept domain names with an underscore.
More precisely, this accepts domain labels with an underscore in
the middle (i.e. not at the start or the end of the label). This
is needed to perform complex CNAME chain resolution in certain
VPN networks.
The current solution is to read the net.dns.search property,
and expand the list during the resolve initialization. In the
future, we could implement search list per process.
Update: refine the code accordingly.
Update: remove unnecessary code.
Update: remove the unused variable.
