At the moment, this command only returns the IPv4. Do so by using the new
relay_find_addr_to_publish().
New commands to return IPv4 and IPv6 will be done with the work in tor#40039.
Related to #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
Use the new relay_has_address_set() interface when deciding if we need to
fetch directory information from an authority as a relay.
If no IPv4 address is found, we'll proceed with a fetch so we can learn our
address in the HTTP header or NETINFO cell that a trusted authority will send
us back.
Related to #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
Tor periodic events have moved to a role base model where relays have specific
events. One of those is to rebuild the descriptor and that is ran every
minute.
This removes the call to router_rebuild_descriptor() from
router_get_my_routerinfo_with_err() because that is the only code path that
can call for a rebuild every second.
Instead, when we mark the descriptor as dirty, immediately reschedule the
descriptor check periodic event so it can be rebuilt that way instead of
randomly when router_get_my_routerinfo_with_err() is called.
Related to #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
When a relay builds a new descriptor, use the new relay_find_addr_to_publish()
interface to find the address to publish per family.
This commit also make the check for address consistency to also work for a
configured IPv6 for which before it was IPv4 only.
Related to #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
In case the transport has no usable address configured (likely 0.0.0.0 or
[::]), attempt to find the IPv4 and on failure, fallback to the IPv6. If none
are found, a log error is emitted and the transport is skiped.
Related to #40025
Signed-off-by: David Goulet <dgoulet@torproject.org>
In order for a relay to find which address to publish in its descriptor,
router_pick_published_address() is used. However, that function only supports
AF_INET and uses the directory server suggested address discovery mechanism.
This new function uses a new interface so that the caller can request an
address family and get the tor_addr_t object. Furthermore, it drops the use of
directory servers address discovery (tor#33244) and instead uses the new
suggested cache that is populated at the moment from data in the NETINFO cell
coming from the directory authorities.
At this commit, function is unused.
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
Our old https://bugs.torproject.org/nnnn URLs only work for bugs
numbered before 40000. Newer gitlab bugs need to have specific
projects mentioned.
This patch assumes that bugs are in tpo/core/tor by default, but
allows us to refer to several other projects by saying
e.g. "chutney#40002" if we want.
(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.
Tracing.md moved to doc/tracing/ so fix the distcheck path in include.am. Also
add the new EventsCircuit.md file.
Signed-off-by: David Goulet <dgoulet@torproject.org>
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.
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.
Create a doc/tracing/ directory to contain a top level README.md which is the
previously named Tracing.md and add the EventsCircuit.md which describes the
circuit subsystem tracing events in depth.
Closes#40036
Signed-off-by: David Goulet <dgoulet@torproject.org>
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.
