Jérôme Charaoui authored 3 years ago and David Goulet committed 3 years ago

This removes the '/blog/' URL component which relies on a 
redirection since the blog has been migrated to Lektor

Thanks to the StaleDesc flag, this is not something we need to look
at any longer.

This patch makes Tor announce the relay specific bridge status page URL
when Tor is starting up before bootstrap occours.

See: tor#30477

Part of the ever-growing 40337 fix.

Alexander Hansen Færøy authored 3 years ago and David Goulet committed 3 years ago

Fixes #40364

Signed-off-by: David Goulet <dgoulet@torproject.org>

- Implement overload statistics structure.
- Implement function that keeps track of overload statistics.
- Implement function that writes overload statistics to descriptor.
- Unittest for the whole logic.

Relay will always publish 0 as DirPort value in their descriptor from now on
except authorities.

Related to #40282

Signed-off-by: David Goulet <dgoulet@torproject.org>

That comes from 685c4866 which added that
check correctly except for when we build a descriptor.

We already omit the IPv6 address, if we need to, when we encode the descriptor
but we need to keep the actual discovered address in the descriptor so we can
notice future IP changes and be able to assess that we are not publishable as
long as we don't specifically set the omit flag.

This lead to also having tor noticing that our IP changed from <nothing> (no
IPv6 in the descriptor) to a discovered one which would trigger every minute.

Fixes #40279, #40288

Signed-off-by: David Goulet <dgoulet@torproject.org>

In two instances we must look at this flag:

1. When we build the descriptor so the IPv6 is NOT added to the descriptor in
   case we judge that we need to omit the address but still publish.

2. When we are deciding if the descriptor is publishable. This flags tells us
   that the IPv6 was not found reachable but we should still publish.

Fixes #40279

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

We would before do an address discovery and then a lookup in the cache if not
found which is now simplified by calling relay_find_addr_to_publish() directly
which does all those combined.

Furthermore, by doing so, we won't trigger an address discovery every minute
if we have no ORPort configured for the family.

Fixes #40254

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

Now that relay_find_addr_to_publish() checks if we actually have an ORPort, we
can simplify the descriptor building phase for IPv6.

This also avoid triggering an IPv6 discovery if the IPv4 can't be found in the
first place.

Related to #40254

Signed-off-by: David Goulet <dgoulet@torproject.org>

In case building the descriptor would fail, we could still flag that we did in
fact publish the descriptors leading to no more attempt at publishing it which
in turn makes the relay silent for some hours and not try to rebuild the
descriptor later.

This has been spotted with #40231 because the operator used a localhost
address for the ORPort and "AssumeReachable 1" leading to this code path where
the descriptor failed to build but all conditions to "can I publish" were met.

Related to #40231

Signed-off-by: David Goulet <dgoulet@torproject.org>

Karsten Loesing authored 4 years ago and Nick Mathewson committed 4 years ago

The previous parser only considered stats files _starting_ with the
timestamp tag, not stats files having the timestamp tag in a later
position. While this applies to all current stats files, a future
stats file might look differently. Better to fix the function now than
be surprised in another 9 years from now.

This commit also adds a test case for such future stats, and it fixes
stats file paths in newly added unit tests.

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

It turns out that 9 years ago, we stopped appending data into stats file and
rather overwrite everytime we have new stats (see commit
a6a127c8)

The load_stats_file() function was still thinking that we could have the same
line many times in the file which turns out to be false since 9 years ago.
However, that did not cause problem until IPv6 connection stats came along
which introduced a new line in conn-stats: "ipv6-conn-bi-direct ...".

Before, that file contained a single line starting with the tag
"conn-bi-direct".  That very tag appears also in the IPv6 tag (see above) so
the load_stats_file() function would consider that the IPv6 line as the last
tag to be appeneded to the file and fail to report the line above (for IPv4).
It would actually truncate the IPv6 line and report it (removing the "ipv6-"
part).

In other words, "conn-bi-direct" was not reported and instead
"ipv6-conn-bi-direct" was used without the "ipv6-" part.

This commit refactors the entire function so that now it looks for a
"timestamp tag" to validate and then if everything is fine, returns the entire
content of the file. The refactor simplifies the function, adds logging in
case of failures and modernize it in terms of coding standard.

Unit tests are also added that makes sure the loaded content matches the
entire file if timestamp validation passes.

Fixes #40226

Signed-off-by: David Goulet <dgoulet@torproject.org>

Alexander Hansen Færøy authored 4 years ago and Nick Mathewson committed 4 years ago

This patch makes Tor announce the relay specific bridge status page URL
when Tor is starting up before bootstrap occours.

See: tor#30477

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

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>

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

Regularly, tor looks if its IP has changed. It does the entire auto discovery
process again. However, it is possible that it does not find anything.

Instead of thinking the IP changed to an unknown address, look at our cache
and see if that value has changed.

The reason for this is because if tor gets its address as a suggestion from a
directory authority, it is because the auto discovery failed and thus that
address should be consider for the IP change check.

Related to #40071

Signed-off-by: David Goulet <dgoulet@torproject.org>

no actual changes

The option `--enable-all-bugs-are-fatal` when used with
`--disable-module-relay` caused GCC to warn about functions that
it thought should be labeled noreturn.

I've tried a couple of approaches, but disabling the warning on
these functions seems to be the best approach.

Fixed #40129; bugfix on 0.4.4.1-alpha.

Previously, we would treat *any* incoming circuit on a non-local
channel as meaning that our ORPort was reachable.  With this patch,
we make sure that the address that the peer _says_ we have is the
same as the one we're trying to advertise right now.

Closes 20165. Bugfix on 4f5192b2 in 0.1.0.1-rc, when
reachability self-tests were first introduced.

Closes #40101.

On an IPv6 reachability failure test, if the address was configured, don't
publish the descriptor and log warn. If the address was auto discovered, still
publish the descriptor.

Closes #33247.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Enum allows us to easily compare what is being returned but also better
semantic to the code.

Related #33247

Signed-off-by: David Goulet <dgoulet@torproject.org>

Now support IPv4 _and_ IPv6.

This also cleans up nicely the function that was moving IPv4 addresses from
uint32_t to tor_addr_t.

Fixes #40058

Signed-off-by: David Goulet <dgoulet@torproject.org>

In routerconf_find_ipv6_or_ap(), we check if the returned ORPort is internal
but not for listening. This means that IPv6 [::] is considered internal.

Thus, we can't use it, we have to look directly at the configured address and
port and if they are valid, we do consider that we have a valid IPv6 ORPort
and that we can thus extend in IPv6.

Related #33246

Signed-off-by: David Goulet <dgoulet@torproject.org>

These now (or_port and dir_port) now have "find" names, since they
look at the portcfg first, then at the actual ports from the
listeners.

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        router_get_advertised_or_port routerconf_find_or_port \
        router_get_advertised_ipv6_or_ap routerconf_find_ipv6_or_ap \
        router_has_advertised_ipv6_orport routerconf_has_ipv6_orport \
        router_get_advertised_dir_port routerconf_find_dir_port

Also, remove get_primary_or_port() -- nothing used it.

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

The ORPort can be IPv4Only which means that even if we can auto discover an
IPv6 address, we should not publish it because it would have an ORPort of 0.

Fixes #40054

Signed-off-by: David Goulet <dgoulet@torproject.org>

Instead of a boolean saying "cache_only" add the concept of flags so we add
semantic through out the code and allow ourselves to have more options in the
future.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Previous development introduced the error of using 0/1 for a boolean
parameter. Fix that everywhere

Related #40025

Signed-off-by: David Goulet <dgoulet@torproject.org>