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 is not fully general yet: we only pick randomly among
_supported_ addresses, and each extendinfo contains at most one IPv4
address and at most one IPv6 address, no matter what the extend cell
had.)
This change will help dual-stack relays do IPv6 reachability tests,
in theory, by having them sometimes do IPv4 connections and
sometimes do ipv6 connections.
Closes ticket 33220.
This is an automated commit made with a python script.
After running the automated script, I had to hand-revert the cases where it
made the conversion functions call themselves.
Additionally, I had to edit a variable declaration in control_bootstrap.c so
that the result of a const cast could be put in a const field.
Only log the 'real_addr' when it is set to something.
Only log the ID when it is set.
When scrubbing the address, don't include a canonical address.
(There should never be a canonical address for a connection with no
ID set.)
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().
This mode was only used in one place, and it caused a dangerous
mingling of functionality. The method is supposed to _describe_ the
peer's address, not give its actual address. We already had a
function to get the actual address.
* 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.
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>
These fields have a complicated history, some slightly complicated
behavior, and some definitely inadequate documentation. Before we
go fixing them up, let's document how they work now.
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>
In order to disambiguate the subsystem and event_name identifiers in the
tor_trace() macro, add TR_SUBSYS() and TR_EV() which help to identify the
parameters of tor_trace() explicitly.
Signed-off-by: David Goulet <dgoulet@torproject.org>
LTTng tracepoint probe declaration is not really following a C standard that
coccinelle and checkSpace.pl likes.
Move everything to a .inc file and standardize the trace_probes_circuit.h
header to include that LTTng specific file if the instrumentation was enabled
at configure time.
Part of #32910
Signed-off-by: David Goulet <dgoulet@torproject.org>
For now, trace_probes_circuit.c only contains LTTng probes so build it only if
enabled within in the build system _and_ the code.
Also, ignore trace_probes_circuit.h for coccinelle parsing.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This is the very first tracepoint in tor. It is in the circuit subsystem for
when a new circuit opens.
LTTng instrumentation requires lot more around a tracepoint than USDT thus
this commit only adds one tracepoint in order to outline a base to add more
tracepoints later.
The idea is that we separate subsystem into what LTTng defines as "providers"
so the circuit provider contains the tracepoint definitions for the circuit
subsystem.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
We do look at the address but with this we also look if the identity digest of
the relay suggesting us an address is a trusted source.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
