This function tried to modify an array in place, but did it in a
pretty confusing and complicated way. I've revised it to follow a
much more straightforward approach.
Fixes bug #40065.
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>
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.
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
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
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.
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>
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>
Tell the relay find address interface to only use the cache so we don't
trigger an address resolve everytime the "GETINFO address" is called.
Related #40025
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>
