This behaves like router_new_address_suggestion() but differs in couple of
ways:
1. It takes a tor_addr_t instead of an address string and supports both
AF_INET and AF_INET6.
2. It does _not_ use the last_guessed_ip local cache and instead only relies
on the last resolved address cache in resolve_addr.c
It is not used at this commit. This function is made to process a suggested
address found in a NETINFO cell exactly like router_new_address_suggestion()
does with the address a directory suggests us.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
Rename the static function update_resolved_cache() to resolved_addr_set_last()
and make it public.
We are about to use it in order to record any suggested address from a NETINFO
cell.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
The find_my_address() function now prioritize the local interface over the
local hostname when guessing the IP address.
See proposal 312, section 3.2.1, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n359
The entire unit tests had to be refactored to make this possible. Instead of
hot patching it, it has been rewritten to cover all possible cases and the
test interface has been changed to accomodate both IPv4 and IPv6 in order for
them to be tested identically.
Closes#33238
Signed-off-by: David Goulet <dgoulet@torproject.org>
This function is about learning if a given address is local to us as in the
resolved address as a relay.
Closes#40009
Signed-off-by: David Goulet <dgoulet@torproject.org>
If at least one Address line is given but invalid, we should not attempt to
guess our address.
This commit sends back the "bail" signal so find_my_address() can return an
error if the requested family doesn't exists but still an Address line is
found which is likely another family.
Fixed in #33235
Related to #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
When going over all Address lines from the configuration, continue to attempt
resolving other lines if one fails.
Before that, we would bail right away and never noticed the other Address
lines.
Fixed in #33235
Related to #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
In get_address_from_config(), we would attempt to resolve an Address line that
is not from the requested family but that line could be a valid address from
another family (v4 vs v6).
This makes it that we don't attempt to resolve a valid address from another
family.
Found with unit test config/find_my_address_mixed.
Fixed in #33235
Related to #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Instead of a complex if/else block, use a table of functions that have the
same interface and each of them attempt to find the address one after the
other.
Pointed out by nickm's during review.
Signed-off-by: David Goulet <dgoulet@torproject.org>
By doing this, a memory leak was found with "hostname_used" that could have
been overwritten by another function.
This commit changes that by making it a NULL string instead.
Found by nickm's review.
Signed-off-by: David Goulet <dgoulet@torproject.org>
The last resolved address cache uses an index that is mapped to an address
family (AF_INET and AF_INET6).
This commit adds a conversion function from af to index and change the code to
use that all the time only.
In the process, this commit fixes a bug that the last resolved address
accessors were using the af value insted of the index.
Spotted by nickm during review
Signed-off-by: David Goulet <dgoulet@torproject.org>
Replace it by find_my_address() everywhere. This changes many parts of the
code that uses it to use a tor_addr_t instead of a plain uint32_t for IPv4.
Many changes to the unit test to also use the new interface.
Part #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Series of changes:
1. Rename function to reflect the namespace of the file.
2. Use the new last resolved cache instead of the unused
last_resolved_addr_v4 (which is also removed in this commit).
3. Make the entire code base use the new resolved_addr_is_local() function.
You will notice that this function uses /24 to differentiate subnets where the
rest of tor uses /16 (including documentation of EnforceDistinctSubnets).
Ticket #40009 has been opened for that.
But that the moment, the function keeps looking at /24.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Series of things done in this commit:
1. Rename the functions to better reflect the namespace of the file.
2. Make both reset and get function to operate on the last_resolved_addrs
cache that is per family.
3. Make the get function to take a tor_addr_t.
4. Change all callsite to use the new convention.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
In order to transition smoothly, maek resolve_my_address_v4() call the new
fancy find_my_address() with AF_INET.
Next commits should remove the use of resolve_my_address_v4() accross the code
to use find_my_address().
This commit is so the unit tests would be more easily fixed and port to the
new find_my_address() internals.
Part of #33233.
Signed-off-by: David Goulet <dgoulet@torproject.org>
resolve_my_address() was beyond repair in terms of refactoring. Way too
complex and doing too many things.
This commit implements find_my_address() which in theory does the same as
resolve_my_address() but in a more clean, concise and modern way using the
tor_addr_t interface and for multiple address family.
The caller needs to pass the address family (IPv4 or IPv6) which this
interface supports. For both, a last resolved cache is used as well.
Implements #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
With prop312, we want to support IPv4 and IPv6 thus multiple Address statement
(up to 2) will be accepted.
For this, "Address" option becomes a LINELIST so we can properly process the
IPv4 or/and IPv6.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Per ticket #32888 this should address logging "the Address torrc
option", "and whether it is an IP address, or a DNS name"; or the
detected "local hostname", "and whether it is an IP address, or a DNS
name". Some of these details already seem to be logged, so just add
what's missing.
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
(In order to avoid conflicts, I'm applying this script separately to
each maint branch. This is the 0.4.3 version.)
Move a series of function from config.c into that new file which is related to
address resolving.
Part of #33789
Signed-off-by: David Goulet <dgoulet@torproject.org>
This change broke torsocks that by default is expecting an IPv4 for hostname
resolution because it can't ask tor for a specific IP version with the SOCKS5
extension.
PreferIPv6 made it that sometimes the IPv6 could be returned to torsocks that
was expecting an IPv4.
Torsocks is probably a very unique case because the runtime flow is that it
hijacks DNS resolution (ex: getaddrinfo()), gets an IP and then sends it back
for the connect() to happen.
The libc has DNS resolution functions that allows the caller to request a
specific INET family but torsocks can't tell tor to resolve the hostname only
to an IPv4 or IPv6 and thus by default fallsback to IPv4.
Reverting this change into 0.4.3.x series but we'll keep it in the 0.4.4.x
series in the hope that we add this SOCKS5 extension to tor for DNS resolution
and then change torsocks to use that.
Fixes#33804
Signed-off-by: David Goulet <dgoulet@torproject.org>
LOG_PROTOCOL_WARN was in core/or.h, but the function it depends on is in
app/config.h. Put them in the same header, to reduce dependencies.
Part of 33633.
