| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Fixes #40743
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Directory authorities and relays now interact properly with directory
authorities if they change addresses. In the past, they would continue
to upload votes, signatures, descriptors, etc to the hard-coded address
in the configuration. Now, if the directory authority is listed in
the consensus at a different address, they will direct queries to this
new address.
Specifically, these three activities have changed:
* Posting a vote, a signature, or a relay descriptor to all the dir auths.
* Dir auths fetching missing votes or signatures from all the dir auths.
* Dir auths fetching new descriptors from a specific dir auth when they
just learned about them from that dir auth's vote.
We already do this desired behavior (prefer the address in the consensus,
but fall back to the hard-coded dirservers info if needed) when fetching
missing certs.
There is a fifth case, in router_pick_trusteddirserver(), where clients
and relays are trying to reach a random dir auth to fetch something. I
left that case alone for now because the interaction with fallbackdirs
is complicated.
Implements ticket 40705.
|
|
It used to describe when the old and new routerinfos were published
when we'd decide to download a routerinfo. Now it describes what
their descriptor digests are.
|
|
Previously we'd look at the routerstatus published_on field when
deciding what to dump, which really has no point. If something's in
the consensus with an ancient published date, then we do want to
keep it.
|
|
The bridge descriptor fetching codes ends up fetching a lot of duplicate
bridge descriptors, because this is how we learn when the descriptor
changes.
This commit only changes comments plus whether we log that one line.
It moves us back to the old behavior, before the previous commit for
30496, where we would only log that line when the bridge descriptor
we're talking about is better than the one we already had (if any).
|
|
Without this change, if we have a working bridge, and we add a new bridge,
we will schedule the fetch attempt for that new bridge descriptor for
three hours(!) in the future.
This change is especially needed because of bug #40396, where if you have
one working bridge and one bridge whose descriptor you haven't fetched
yet, your Tor will stall until you have successfully fetched that new
descriptor -- in this case for hours.
In the old design, we would put off all further bridge descriptor fetches
once we had any working bridge descriptor. In this new design, we make the
decision per bridge based on whether we successfully got *its* descriptor.
To make this work, we need to also call learned_bridge_descriptor() every
time we get a bridge descriptor, not just when it's a novel descriptor.
Fixes bug 40396.
Also happens to fix bug 40495 (redundant descriptor fetches for every
bridge) since now we delay fetches once we succeed.
A side effect of this change is that if we have any configured bridges
that *aren't* working, we will keep trying to fetch their descriptors
on the modern directory retry schedule -- every couple of seconds for
the first half minute, then backing off after that -- which is a lot
faster than before.
|
|
|
|
|
|
Let external bridge reachability testing tools discard cached
bridge descriptors when setting new bridges, so they can be sure
to get a clean reachability test.
Implements ticket 40209.
|
|
First, this commit moves the launch_dummy_circuit_as_needed() function into
relay_find_addr.c and renames it to relay_addr_learn_from_dirauth(). This is
an attempt to centralize anything relate with address discovery in the right
module.
Second, when building a descriptor and we fail to discover our address,
immediately launch a dummy circuit to an authority in an attempt to learn our
descriptor.
It is still only done every 20 minutes even though the descriptor build is
done every minute. We ought to avoid load on the authority and if we can't
learn in the first place our address from them, chances are more things are
wrong.
Related to #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Tor now can learn its address from a NETINFO cell coming from an authority.
Thus, instead from launching a dummy descriptor fetch to learn the address
from the directory response (unauthenticated), we simply now launch a one-hop
testing circuit.
Related to #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Typos found with codespell.
Please keep in mind that this should have impact on actual code
and must be carefully evaluated:
src/core/or/lttng_circuit.inc
- ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+ ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)
|
|
Instead of looking at the "Address" option alone, instead check if we have an
address in our cache (that is discovered by tor). If not, then it tells us
that tor does not have an address to work with so we can then ask a directory
authority for a suggestion.
Related #2178
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
We used to have a single boolean, "FascistFirewall". Ages ago, in
tickets #17840 and #9067, we added an improved "ReachableAddresses"
mechanism. It's time to rename related identifiers in the code for
consistency. This closes #18106.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
fascist_firewall_allows_address reachable_addr_allows \
fascist_firewall_use_ipv6 reachable_addr_use_ipv6 \
fascist_firewall_prefer_ipv6_impl reachable_addr_prefer_ipv6_impl \
fascist_firewall_prefer_ipv6_orport reachable_addr_prefer_ipv6_orport \
fascist_firewall_prefer_ipv6_dirport reachable_addr_prefer_ipv6_dirport \
fascist_firewall_allows_address_addr reachable_addr_allows_addr \
fascist_firewall_allows_address_ap reachable_addr_allows_ap \
fascist_firewall_allows_base reachable_addr_allows_base \
fascist_firewall_allows_ri_impl reachable_addr_allows_ri_impl \
fascist_firewall_allows_rs_impl reachable_addr_allows_rs_impl \
fascist_firewall_allows_rs reachable_addr_allows_rs \
fascist_firewall_allows_md_impl reachable_addr_allows_md_impl \
fascist_firewall_allows_node reachable_addr_allows_node \
fascist_firewall_allows_dir_server reachable_addr_allows_dir_server \
fascist_firewall_choose_address_impl reachable_addr_choose_impl \
fascist_firewall_choose_address reachable_addr_choose \
fascist_firewall_choose_address_base reachable_addr_choose_base \
fascist_firewall_choose_address_rs reachable_addr_choose_from_rs \
fascist_firewall_choose_address_ls reachable_addr_choose_from_ls \
fascist_firewall_choose_address_node reachable_addr_choose_from_node \
fascist_firewall_choose_address_dir_server reachable_addr_choose_from_dir_server
|
|
This changes a LOT of code but in the end, behavior is the same.
Unfortunately, many functions had to be changed to accomodate but in majority
of cases, to become simpler.
Functions are also removed specifically those that were there to convert an
IPv4 as a host format to a tor_addr_t. Those are not needed anymore.
The IPv4 address field has been standardized to "ipv4_addr", the ORPort to
"ipv4_orport" (currently IPv6 uses ipv6_orport) and DirPort to "ipv4_dirport".
This is related to Sponsor 55 work that adds IPv6 support for relays and this
work is needed in order to have a common interface between IPv4 and IPv6.
Closes #40043.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
This is not actually a bug! It can happen for a bunch of reasons,
which all boil down to "trying to add an extrainfo for which we no
longer have the corresponding routerinfo".
Fixes #16016; bugfix on 0.2.6.3-alpha.
|
|
When counting and choosing nodes on a client that uses bridges, only
choose bridges for direct connections.
Part of 34200.
|
|
Split the node choosing checks into their own function, so we can call
it independently of iterating through the nodelist.
Part of 34200.
|
|
Make some interfaces and implementations consistent by replacing int
with bool.
Part of 34200.
|
|
Move node flag checks to router_add_running_nodes_to_smartlist(), where
they are actually used.
Part of 34200.
|
|
And delete a loop that is now empty. This change should improve tor's
performance, because we no longer iterate through the nodelist twice for
every node in every circuit path.
Part of 34200.
|
|
Check for single-hop exits in router_add_running_nodes_to_smartlist(),
rather than router_choose_random_node().
Part of 34200.
|
|
Part of 33226.
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
client_or_conn_should_skip_reachable_address_check router_or_conn_should_skip_reachable_address_check \
client_dir_conn_should_skip_reachable_address_check router_dir_conn_should_skip_reachable_address_check
|
|
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
router_skip_orport_reachability_check router_should_skip_orport_reachability_check \
router_skip_dirport_reachability_check router_should_skip_dirport_reachability_check \
router_connect_assume_or_reachable client_or_conn_should_skip_reachable_address_check \
router_connect_assume_dir_reachable client_dir_conn_should_skip_reachable_address_check
It was generated with --no-verify, so it probably breaks some commit hooks.
The commiter should be sure to fix them up in a subsequent commit.
|
|
Part of 33222.
|
|
Change some function names to distinguish between:
* client first hop reachability (ReachableAddresses)
* relay port reachability self-tests
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
router_skip_or_reachability router_connect_assume_or_reachable \
router_skip_dir_reachability router_connect_assume_dir_reachable
It was generated with --no-verify, so it probably breaks some commit hooks.
The commiter should be sure to fix them up in a subsequent commit.
Part of 33222.
|
|
Descriptor differences are cosmetic if 2 hours has passed,
not 12 hours (see ticket 33573).
|
|
Doing this makes our macro usage a little clear IMO, and also avoids
having to use an unadorned "new" within a macro. (Clang-format
seems to think that "new" means we're doing C++, and so it generates
some output that checkSpace.pl doesn't care for.)
|
|
Resolved conflicts in src/core/include.am
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
directory_must_use_begindir dirclient_must_use_begindir \
directory_fetches_from_authorities dirclient_fetches_from_authorities \
directory_fetches_dir_info_early dirclient_fetches_dir_info_early \
directory_fetches_dir_info_later dirclient_fetches_dir_info_later \
directory_too_idle_to_fetch_descriptors dirclient_too_idle_to_fetch_descriptors
|
|
I had incorrectly identified these functions as dircache-only, when
in fact they apply to everyone who acts a directory client.
|
|
|
|
|
|
|
|
There are now no HAVE_MODULE_{DIRAUTH,RELAY} inside functions.
Closes ticket 32163.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is other code that uses this value, and some of it is
apparently reachable from inside router_dir_info_changed(), which
routerlist_free() apparently calls. (ouch!) This is a minimal fix
to try to resolve the issue without causing other problems.
Fixes bug 31003. I'm calling this a bugfix on 0.1.2.2-alpha, where
the call to router_dir_info_changed() was added to routerlist_free().
|
