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>

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

Closes #40061

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

Related #40058

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>

Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.

Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we don't warn at all when we have
fewer than 25 connections total.

Fixes bug 33880, which seems to have been provoked by our #17592
change in 0.3.5.

Closes #33239

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

Fixes #40059

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

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        check_server_ports check_and_prune_server_ports

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>

Now that tor automatically binds to IPv4 _and_ IPv6, in order to avoid
breaking configurations, we sanitize the parsed lists for duplicate ORPorts.
It is possible to happen because we still allow this configuration;

  ORPort 9888
  ORPort [4242::1]:9888

Meaning that the first ORPort value will bind to 0.0.0.0:9888 _and_ [::]:9888
which would lead to an error when attempting to bind on [4242::1]:9888.
However, that configuration is accepted today and thus we must not break it.

To remedy, we now sanitize the parsed list and prioritize an ORPort that has
an explicit address over the global one.

A warning is emitted if such configuration pattern is found. This is only for
the ORPort.

Related to #33246

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

This commit makes it that if the ORPort is set with a single port, it will
bind to both global listen IPv4 and IPv6 addresses.

To pin an "ORPort <PORT>" to be IPv4 or IPv6, the IPv4Only/IPv6Only flags are
honored thus this will _only_ bind on IPv6 for that port value:

  ORPort 9050 IPv6Only
    Results in: [::]:9050

  ORPort 9051 IPv4Only
    Results in: [0.0.0.0]:9051

Attempting to configure an explicit IPv4 address with IPv6Only flag is an
error and vice versa.

Closes #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

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>

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>

The need for casting negative syscall arguments depends on the
glibc version. This affects the rules for the openat syscall which
uses the constant AT_FDCWD that is defined as a negative number.
This commit adds logic to only apply the cast when necessary, on
glibc versions from 2.27 onwards.

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