Rationale: these don't actually give the first advertised
address/port, but instead give us the first such port that we are
_configured_ to advertise. Putting them in a portconf_ namespace
therefore makes sense.
Similarly, there are no other functions that get the first
configured advertised addr/port, so the "by_type_af()" part is needless.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
get_first_advertised_addr_by_type_af portconf_get_first_advertised_addr \
get_first_advertised_port_by_type_af portconf_get_first_advertised_port
This option controls if a tor relay will attempt address auto discovery and
thus ultimately publish an IPv6 ORPort in the descriptor.
Behavior is from proposal 312 section 3.2.6.
Closes#33245
Signed-off-by: David Goulet <dgoulet@torproject.org>
Different versions of glibc use either open or openat for the
opendir function. This commit adds logic to use the correct rule
for each glibc version, namely:
- Until 2.14 open is used
- From 2.15 to to 2.21 openat is used
- From 2.22 to 2.26 open is used
- From 2.27 onwards openat is used
Dirauth code use the warn log severity when calling find_my_address() which
made it that every time we would find an address, it would log a warning.
These are not needed below info level and thus set them to info level. An IP
change is set to notice by default.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Commit b14b1f2b1d was a mistake.
In case an Address statement is missing for the wanted family but another one
exists for another family, simply continue the address discovery.
It is not a mistake to be missing an Address statement for a family because
the address could simply be discovered by the next methods. Not all address
family requires a specific Address statement.
However, we do bail if we couldn't find any valid address for the requested
family _and_ a resolve failed meaning we had a hostname but couldn't resolve
it. In that case, we can't know if that hostname would have been for v4 or v6
thus we can't continue the address discovery properly.
Couple unit tests case were removed to match this reality.
Related #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
Fix on unreleased code.
Logical || in the BUG() made it that it would always trigger the BUG().
Fixes#40034
Signed-off-by: David Goulet <dgoulet@torproject.org>
This will make sure that we always properly initialize the cache by the exact
size all the time.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
Built in tracing should _not_ be run if it was not set on purpose. Warn as
loud as we can in order to inform the user that they are running a version
with tracing capabilities built in.
This commit also adds a subsys stub because utlimately the logging will happen
in the init phase but because the default log file is not set in the
sys_logging init function, the stub is not useful for now.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This reverts commit bf2a399fc0.
Don't set by default the prefer IPv6 feature on client ports because it breaks
the torsocks use case. The SOCKS resolve command is lacking a mechanism to ask
for a specific address family (v4 or v6) thus prioritizing IPv6 when an IPv4
address is asked on the resolve SOCKS interface resulting in a failure.
Tor Browser explicitly set PreferIPv6 so this should not affect the majority
of our users.
Closes#33796
Signed-off-by: David Goulet <dgoulet@torproject.org>
If no Address statement are found in the configuration file, attempt to learn
our address by looking at the ORPort address if any. Specifying an address is
optional so if we can't find one, it is fine, we move on to the next discovery
mechanism.
Note that specifying a hostname on the ORPort is not yet supported at this
commit.
Closes#33236
Signed-off-by: David Goulet <dgoulet@torproject.org>
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>
