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>
AssumeReachable should only be about whether a relay thinks that it
is reachable itself. But previously, we've had it also turn off
reachability checking of _other_ relays on authorities.
(Technically, reachability tests were still run, but we would ignore
the results.)
With this patch, there is a new AuthDirTestReachability option
(default 1) that controls whether authorities run reachability
tests.
Making this change allows us to have test networks where authorities
set AssumeReachable without disabling their reachability testing
entirely.
Closes ticket #34445.
Make clear that Tor's C code targets C99 standards. This makes it more
explicit what to expect for new code, because guessing from existing
code is not always reliable, especially for code that predates the
change in standard.
This change broke torsocks that by default is expecting an IPv4 for hostname
resolution because it can't ask tor for a specific IP version with the SOCKS5
extension.
PreferIPv6 made it that sometimes the IPv6 could be returned to torsocks that
was expecting an IPv4.
Torsocks is probably a very unique case because the runtime flow is that it
hijacks DNS resolution (ex: getaddrinfo()), gets an IP and then sends it back
for the connect() to happen.
The libc has DNS resolution functions that allows the caller to request a
specific INET family but torsocks can't tell tor to resolve the hostname only
to an IPv4 or IPv6 and thus by default fallsback to IPv4.
Reverting this change into 0.4.3.x series but we'll keep it in the 0.4.4.x
series in the hope that we add this SOCKS5 extension to tor for DNS resolution
and then change torsocks to use that.
Fixes#33804
Signed-off-by: David Goulet <dgoulet@torproject.org>
- external links use markdown's []() format,
- local files are formated with backquotes,
- duplicated new lines were removed,
- unnecesary single spaces were removed,
- broken links and local paths were updated.
Conflicts:
doc/tor.1.txt
src/app/config/config.c
src/app/config/or_options_st.h
src/core/mainloop/connection.h
Between 042 and 043, the dirauth options were modularized so this merge commit
address this by moving the AuthDirRejectUncompressedRequests to the module
along with a series of accessors.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This controls the previous feature added that makes dirauth send back a 503
error code on non relay connections if under bandwidth pressure.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Explain that:
* most flags default to off
* flags that default to on are specified
Document PreferIPv6Automap in its "No" form, because it's on by
default.
Cleanup after 32637.
Make Tor clients tell dual-stack exits that they prefer IPv6
connections.
This change is equivalent to setting the PreferIPv6 flag on
SOCKSPorts (and most other listener ports). Tor Browser has
been setting this flag for some time, and we want to remove a
client distinguisher at exits.
Also update the man page, putting all the IP flags in their
non-default forms.
Closes ticket 32637.
For now, this module is enabled whenever the relay module is
enabled, and disabled whenever the relay module is disabled. Though
they are logically separate, the use cases for running one without
the other are rare enough that we don't really want to support
compiling them independently.
We stopped looking at this option in 85cf6dcba3, back when we
implemented the minimal pieces of prop275. Since then, we've had
code to validate and adjust this option, and to give it a different
value in testing networks, but the option hasn't actually done
anything.
We can safely mark it as OBSOLETE, since doing so does not make any
old configuration get rejected.
Closes ticket 32807.
