| Age | Commit message (Collapse) | Author |
|---|
|
When calling `circpad_send_padding_cell_for_callback()`, the flag
`is_padding_timer_scheduled` was not resetted to 0 which caused an issue
in the circpad simulator.
This commit fixes this problem.
Fixes #32671.
|
|
|
|
Also, explain why it's relevant for bootstrapping.
This is a comments-only patch.
|
|
We've been using it for years, and it seems to work just fine. This
patch removes the option and its network parameter.
Part of #40139
|
|
Part of #40139, where I'm removing network parameters that we
shouldn't be looking at any longer.
|
|
We set this flag if we've launched the connection in order to
satisfy an origin circuit, or when we decide the connection _would_
satisfy an origin circuit. These are the only or_connections we
want to consider for bootstrapping: other or_connections are opened
because of client EXTEND requests, and they may succeed or fail
because of the clients' confusion or misconfiguration.
Closes #25061.
|
|
|
|
Previously, we would treat *any* incoming circuit on a non-local
channel as meaning that our ORPort was reachable. With this patch,
we make sure that the address that the peer _says_ we have is the
same as the one we're trying to advertise right now.
Closes 20165. Bugfix on 4f5192b2803c706 in 0.1.0.1-rc, when
reachability self-tests were first introduced.
|
|
|
|
|
|
|
|
Turns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.
This means that a service operator can still enable the defenses but as soon
as the intro point relay would get a new consensus, they would be overwritten.
And at this commit, the network is entirely disabling DoS defenses.
Fix this by introducing an "explicit" flag that indicate if the
ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
using the consenus at once.
We are not bumping the protover HSIntro value for this because 0.4.2.x series
is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
are confident that a backport and then upgrade path to the latest 0.4.4.x
stable coming up soon is enough to mitigate this problem in the coming months.
It avoids the upgrade path on the service side by keeping the requirement for
protover HSIntro=5.
Fixes #40109
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Closes #40101.
|
|
|
|
Closes #29113
|
|
We used to have a single boolean, "FascistFirewall". Ages ago, in
tickets #17840 and #9067, we added an improved "ReachableAddresses"
mechanism. It's time to rename related identifiers in the code for
consistency. This closes #18106.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
fascist_firewall_allows_address reachable_addr_allows \
fascist_firewall_use_ipv6 reachable_addr_use_ipv6 \
fascist_firewall_prefer_ipv6_impl reachable_addr_prefer_ipv6_impl \
fascist_firewall_prefer_ipv6_orport reachable_addr_prefer_ipv6_orport \
fascist_firewall_prefer_ipv6_dirport reachable_addr_prefer_ipv6_dirport \
fascist_firewall_allows_address_addr reachable_addr_allows_addr \
fascist_firewall_allows_address_ap reachable_addr_allows_ap \
fascist_firewall_allows_base reachable_addr_allows_base \
fascist_firewall_allows_ri_impl reachable_addr_allows_ri_impl \
fascist_firewall_allows_rs_impl reachable_addr_allows_rs_impl \
fascist_firewall_allows_rs reachable_addr_allows_rs \
fascist_firewall_allows_md_impl reachable_addr_allows_md_impl \
fascist_firewall_allows_node reachable_addr_allows_node \
fascist_firewall_allows_dir_server reachable_addr_allows_dir_server \
fascist_firewall_choose_address_impl reachable_addr_choose_impl \
fascist_firewall_choose_address reachable_addr_choose \
fascist_firewall_choose_address_base reachable_addr_choose_base \
fascist_firewall_choose_address_rs reachable_addr_choose_from_rs \
fascist_firewall_choose_address_ls reachable_addr_choose_from_ls \
fascist_firewall_choose_address_node reachable_addr_choose_from_node \
fascist_firewall_choose_address_dir_server reachable_addr_choose_from_dir_server
|
|
Resolves conflicts:
src/core/or/channel.c
src/test/test_channel.c
|
|
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.
|
|
|
|
|
|
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
protover_contains_long_protocol_names protover_list_is_invalid
|
|
|
|
|
|
|
|
|
|
This was once used for rate-limiting, but now it's only for
accounting. It hasn't served a useful purpose in a long time.
Closes ticket 33097.
|
|
Specifically: do not close IPv4 bandwidth-testing circuits just
because our IPv6 orport is unreachable.
Attempted fix for #40068.
|
|
|
|
|
|
Without this fix, if an PT forgets to send a USERADDR command, that
results in a connection getting treated as local for the purposes of
rate-limiting.
If the PT _does_ use USERADDR, we still believe it.
Closes ticket 33747.
|
|
Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.
Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we don't warn at all when we have
fewer than 25 connections total.
Fixes bug 33880, which seems to have been provoked by our #17592
change in 0.3.5.
|
|
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>
|
|
|
|
|
|
|
|
|
|
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 #40042
Closes #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.
|
|
|
|
These names are analogous to the CONST_TO_*_CIRC() functions we have
for circuits.
Part of #40046.
|
|
Preliminary work for #40046.
|
|
Since we can list the real address and the canonical one in a
human-readable format we don't need to pick.
|
|
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.
|
|
|
|
|
