Without this change, if we have a working bridge, and we add a new bridge,
we will schedule the fetch attempt for that new bridge descriptor for
three hours(!) in the future.
This change is especially needed because of bug #40396, where if you have
one working bridge and one bridge whose descriptor you haven't fetched
yet, your Tor will stall until you have successfully fetched that new
descriptor -- in this case for hours.
In the old design, we would put off all further bridge descriptor fetches
once we had any working bridge descriptor. In this new design, we make the
decision per bridge based on whether we successfully got *its* descriptor.
To make this work, we need to also call learned_bridge_descriptor() every
time we get a bridge descriptor, not just when it's a novel descriptor.
Fixes bug 40396.
Also happens to fix bug 40495 (redundant descriptor fetches for every
bridge) since now we delay fetches once we succeed.
A side effect of this change is that if we have any configured bridges
that *aren't* working, we will keep trying to fetch their descriptors
on the modern directory retry schedule -- every couple of seconds for
the first half minute, then backing off after that -- which is a lot
faster than before.
Remove all unnecessary ";" characters at the end of several lines.
Align all indentations to 4 spaces.
Update console messages related to XML_CATALOG_FILES and
.bashrc file.
Signed-off-by: skaluzka <skaluzka@protonmail.com>
This option changes the time for which a bandwidth measurement period
must have been in progress before we include it when reporting our
observed bandwidth in our descriptors. Without this option, we only
consider a time period towards our maximum if it has been running
for a full day. Obviously, that's unacceptable for testing
networks, where we'd like to get results as soon as possible.
For non-testing networks, I've put a (somewhat arbitrary) 2-hour
minimum on the option, since there are traffic analysis concerns
with immediate reporting here.
Closes#40337.
This is a new detection type which is that a relay can now control the rate of
client connections from a single address.
The mechanism is pretty simple, if the rate/burst is reached, the address is
marked for a period of time and any connection from that address is denied.
Closes#40253
Signed-off-by: David Goulet <dgoulet@torproject.org>
Typos found with codespell.
Please keep in mind that this should have impact on actual code
and must be carefully evaluated:
src/core/or/lttng_circuit.inc
- ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+ ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)
Make it possible to specify multiple ConsensusParams torrc
lines.
Now directory authority operators can for example put the
main ConsensusParams config in one torrc file and then add to it
from a different torrc file.
Closes ticket 40164.
This patch adds a new option to torrc: `OutboundBindAddressPT`. This
option works in the same way as `OutboundBindAddressOR` and
`OutboundBindAddressExit` in that it allows the user to specify which
outbound IP address the user wants the PT to make its connections from.
There is one difference though in that OutboundBindAddressPT will only
be a suggestion for the PT to use since Tor cannot enforce whether or
not the PT actually uses this option for anything.
See: https://bugs.torproject.org/5304
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>
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>
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>
Remove all the escape character "\" which is not needed for Markdown files.
This also fixes the tracing event include to the correct path.
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>
