This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes#40081.
Added tests for
1. commit_max
2. advance_obs
3. add_obs
4. rep_hist_fill_bandwidth_history
5. rep_hist_get_bandwidth_lines
(Lightly edited by nickm to use new names from bwhist refactoring.)
Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com>
We found this in #40076, after we started using buf_move_all() in
more places. Fixes bug #40076; bugfix on 0.3.3.1-alpha. As far as
I know, the crash only affects master, but I think this warrants a
backport, "just in case".
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>
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>
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>
Remove use of router_pick_published_address() and use
relay_find_addr_to_publish instead.
Related to #40025
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>
Instead of replacing connection_t.{addr,port} with a canonical
orport, and tracking the truth in real_addr, we now leave
connection_t.addr alone, and put the canonical address in
canonical_orport.
Closes#40042Closes#33898
This fixes CID 1465291, which was a complaint that we never actually
checked the return value of this function. It turns out that this
function was failing, and it didn't matter, because it wasn't
necessary for this test.
Now that we've clarified that these functions only need to describe
the peer in a human-readable way, we can have them delegate to
connection_describe_peer().
* We no longer call this an optional method
* We document that it returns the real address, not a canonical one.
* We have it try harder if the real address hasn't been set yet.
Tests %include with files and folders, modifying and reloading
the config file with sandbox enabled and reponse of SAVECONF and
getinfo config-can-saveconf control commmands.
This patch ensures that we strip "\r" characters on both Windows as well
as Unix when we read text files. This should prevent the issue where
some Tor state files have been moved from a Windows machine, and thus
contains CRLF line ending, to a Unix machine where only \n is needed.
We add a test-case to ensure that we handle this properly on all our
platforms.
See: https://bugs.torproject.org/tpo/core/tor/33781
Pass the IPv4 before the IPv6 like all our other interfaces.
Changes unreleased code related to #40043.
Closes#40045
Signed-off-by: David Goulet <dgoulet@torproject.org>
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>
Unclear but that somehow failed on Windows once (?) according to ticket #33768
but we are not seeing that failure.
Nevertheless, add a simple unit test.
Closes#33768
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit modifies the behavior of `parse_extended_address` in such a way
that if it fails, it will always return a `BAD_HOSTNAME` value, which is then
used to return the 0xF6 extended error code. This way, in any case that is
not a valid v2 address, we return the 0xF6 error code, which is the expected
behavior.
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 patch lifts the `tor_tls_cert_matches_key()` tests out of the
OpenSSL specific TLS test suite and moves it into the generic TLS test
suite that is executed for both OpenSSL and NSS.
This patch is largely a code movement, but we had to rewrite parts of
the test to avoid using OpenSSL specific data-types (such as `X509 *`)
and replace it with the generic Tor abstraction type
(`tor_x509_cert_impl_t *`).
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
In practice, there will be at most one ipv4 address and ipv6 address
for now, but this code is designed to not care which address is
which until forced to do so.
This patch does not yet actually create extend_info_t objects with
multiple addresses.
Closes#34069.
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>
These tests don't actually exercise the authority IPv6 ORPort
self-add feature in 32822, but they do improve coverage of the
related config code.
Part of 32822.
The exposed interface is "stats/" thus make the unit tests clear that it is
testing that specific GETINFO command.
Signed-off-by: David Goulet <dgoulet@torproject.org>
New name reflects that the function is only used to compare router addresses
in order to learn if they are in the same network.
The network check is /16 and /32 respectively for IPv4 and IPv6.
Related to #40009
Signed-off-by: David Goulet <dgoulet@torproject.org>
This unit tests validates the use of IPv4 _and_ IPv6 together as in multiple
option Address lines both addresses and hostnames.
Closes#33235
Signed-off-by: David Goulet <dgoulet@torproject.org>
