Age | Commit message (Collapse) | Author |
|
Closes #40101.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
They are about to be shutdown in September.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Related to #33247
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Enum allows us to easily compare what is being returned but also better
semantic to the code.
Related #33247
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
Closes #40061
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Related #40058
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Closes #33239
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
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>
|
|
Also, remove get_primary_or_port() -- nothing used it.
|
|
|
|
Rationale: these don't actually give the first advertised
address/port, but instead give us the first such port that we are
_configured_ to advertise. Putting them in a portconf_ namespace
therefore makes sense.
Similarly, there are no other functions that get the first
configured advertised addr/port, so the "by_type_af()" part is needless.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
get_first_advertised_addr_by_type_af portconf_get_first_advertised_addr \
get_first_advertised_port_by_type_af portconf_get_first_advertised_port
|
|
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>
|
|
|
|
|
|
Dirauth code use the warn log severity when calling find_my_address() which
made it that every time we would find an address, it would log a warning.
These are not needed below info level and thus set them to info level. An IP
change is set to notice by default.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Commit b14b1f2b1d9 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>
|
|
Also adds the compiled and running glibc version when using the
--library-versions flag.
|
|
|
|
|
|
|
|
Closes #40033
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Closes #40044
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Fix on unreleased code.
Logical || in the BUG() made it that it would always trigger the BUG().
Fixes #40034
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
These values are stored, persisted, and published. They are not yet
actually filled with anything.
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
rep_hist_note_bytes_read bwhist_note_bytes_read \
rep_hist_note_bytes_written bwhist_note_bytes_written \
rep_hist_note_dir_bytes_read bwhist_note_dir_bytes_read \
rep_hist_note_dir_bytes_written bwhist_note_dir_bytes_written \
rep_hist_get_bandwidth_lines bwhist_get_bandwidth_lines \
rep_hist_update_state bwhist_update_state \
rep_hist_load_state bwhist_load_state \
rep_hist_bandwidth_assess bwhist_bandwidth_assess
|
|
These are logically independent from the rest of rephist, and make
more sense in isolation. The next patch will rename them too.
|
|
|
|
This will make sure that we always properly initialize the cache by the exact
size all the time.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This reverts commit bf2a399fc0d90df76e091fa3259f7c1b8fb87781.
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>
|
|
If no Address statement are found in the configuration file, attempt to learn
our address by looking at the ORPort address if any. Specifying an address is
optional so if we can't find one, it is fine, we move on to the next discovery
mechanism.
Note that specifying a hostname on the ORPort is not yet supported at this
commit.
Closes #33236
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This behaves like router_new_address_suggestion() but differs in couple of
ways:
1. It takes a tor_addr_t instead of an address string and supports both
AF_INET and AF_INET6.
2. It does _not_ use the last_guessed_ip local cache and instead only relies
on the last resolved address cache in resolve_addr.c
It is not used at this commit. This function is made to process a suggested
address found in a NETINFO cell exactly like router_new_address_suggestion()
does with the address a directory suggests us.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Rename the static function update_resolved_cache() to resolved_addr_set_last()
and make it public.
We are about to use it in order to record any suggested address from a NETINFO
cell.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Unit tests also suffered from a memleak.
Closes #40024
Signed-off-by: David Goulet <dgoulet@torproject.org>
|