Add router_have_consensus_path() which reports whether
the consensus has exit paths, internal paths, or whether it
just doesn't know.
Used by #13718 and #13814.
count_usable_descriptors now uses named exit_only values:
USABLE_DESCRIPTOR_ALL
USABLE_DESCRIPTOR_EXIT_ONLY
Add debug logging code for descriptor counts.
This (hopefully) resolves nickm's request in bug 13718 to improve
argument readability in nodelist.c.
choose_good_entry_server() now excludes current entry
guards and their families, unless we're in a test network,
and excluding guards would exclude all nodes.
This typically occurs in incredibly small tor networks,
and those using TestingAuthVoteGuard *
This is an incomplete fix, but is no worse than the previous
behaviour, and only applies to minimal, testing tor networks
(so it's no less secure).
Discovered as part of #13718.
Make hidden service port scanning harder by sending back REASON_DONE which
does not disclose that it was in fact an exit policy issue. After that, kill
the circuit immediately to avoid more bad requests on it.
This means that everytime an hidden service exit policy does match, the user
(malicious or not) needs to build a new circuit.
Fixes#13667.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When V3AuthVotingInterval is low, decrease the delay on the
If-Modified-Since header passed to directory servers.
This allows us to obtain consensuses promptly when the consensus
interval is very short.
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13963.
Decrease minimum consensus interval to 10 seconds
when TestingTorNetwork is set. (Or 5 seconds for
the first consensus.)
Fix code that assumes larger interval values.
This assists in quickly bootstrapping a testing
Tor network.
Fixes bugs 13718 & 13823.
Stop requiring exits to have non-zero bandwithcapacity in a
TestingTorNetwork. Instead, when TestingMinExitFlagThreshold is 0,
ignore exit bandwidthcapacity.
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13839.
Makes bug 13161's TestingDirAuthVoteExit non-essential.
Matthew's autoaddr code returned an undecorated address when trying to check
that the code didn't insert an undecorated one into the map.
This patch fixes this by actually storing the undecorated address in tmp
instead of buf as it was originally intended.
This patch is released under the same license as the original file as
long as the author iscredited.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
Document why we divide it by two.
Check for > 0 instead of nonzero for success, since that's what the
manpage says.
Allow watchdog timers greater than 1 second.
It work by notifying systemd on a regular basis. If
there is no notification, the daemon is restarted.
This requires a version newer than the 209 version
of systemd, as it is not supported before.
The original call to getsockopt to know the original address on transparently
proxyed sockets using REDIRECT in iptables failed with IPv6 addresses because
it assumed all sockets used IPv4.
This patch fixes this by using the appropriate options and adding the headers
containing the needed definitions for these.
This patch is released under the same license as the original file as
long as the author iscredited.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
The address of an array in the middle of a structure will
always be non-NULL. clang recognises this and complains.
Disable the tautologous and redundant check to silence
this warning.
Fixes bug 14001.
The address of an array in the middle of a structure will
always be non-NULL. clang recognises this and complains.
Disable the tautologous and redundant check to silence
this warning.
A comment about an IPv6 address string incorrectly refers
to an IPv4 address format.
A log buffer is sized 10024 rather than 10240.
Fixes bug 14001.
The two statistics are:
1. number of RELAY cells observed on successfully established
rendezvous circuits; and
2. number of .onion addresses observed as hidden-service
directory.
Both statistics are accumulated over 24 hours, obfuscated by rounding
up to the next multiple of a given number and adding random noise,
and written to local file stats/hidserv-stats.
Notably, no statistics will be gathered on clients or services, but
only on relays.
In circuit_get_open_circ_or_launch(), for a rendezvous circuit,
rend_client_rendcirc_has_opened() but circuit_has_opened() is preferred here
since it will call the right function for a specific circuit purpose.
Furthermore, a controller event is triggered where the former did not.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
1) Set them to the values that (according to Rob) avoided performance
regressions. This means that the scheduler won't get much exercise
until we implement KIST or something like it.
2) Rename the options to end with a __, since I think they might be
going away, and nobody should mess with them.
3) Use the correct types for the option variables. MEMUNIT needs to be a
uint64_t; UINT needs to be (I know, I know!) an int.
4) Validate the values in options_validate(); do the switch in
options_act(). This way, setting the option to an invalid value on
a running Tor will get backed out.
We add a compression level argument to tor_zlib_new, and use it to
determine how much memory to allocate for the zlib object. We use the
existing level by default, but shift to smaller levels for small
requests when we have been over 3/4 of our memory usage in the past
half-hour.
Closes ticket 11791.
When closing parallel introduction points, the given reason (timeout)
was actually changed to "no reason" thus when the circuit purpose was
CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT, we were reporting an introduction
point failure and flagging it "unreachable". After three times, that
intro point gets removed from the rend cache object.
In the case of CIRCUIT_PURPOSE_C_INTRODUCING, the intro point was
flagged has "timed out" and thus not used until the connection to the HS
is closed where that flag gets reset.
This commit adds an internal circuit reason called
END_CIRC_REASON_IP_NOW_REDUNDANT which tells the closing circuit
mechanism to not report any intro point failure.
This has been observed while opening hundreds of connections to an HS on
different circuit for each connection. This fix makes this use case to
work like a charm.
Fixes#13698.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Instead, generate new keys, and overwrite the empty key files.
Adds FN_EMPTY to file_status_t and file_status.
Fixes bug 13111.
Related changes due to review of FN_FILE usage:
Stop generating a fresh .old RSA key file when the .old file is missing.
Avoid overwriting .old key files with empty key files.
Skip loading zero-length extra info store, router store, stats, state,
and key files.
We were only using it when smartlist_choose_node_by_bandwidth_weights
failed. But that function could only fail in the presence of
buggy/ancient authorities or in the absence of a consensus. Either
way, it's better to use sensible defaults and a nicer algorithm.
Now, if a router ever changes its microdescriptor, but the new
microdescriptor SHA256 hash has the same 160-bit prefix as the old
one, we treat it as a new microdescriptor when deciding whether to
copy status information.
(This function also is used to compare SHA1 digests of router
descriptors, but don't worry: the descriptor_digest field either holds
a SHA256 hash, or a SHA1 hash padded with 0 bytes.)
Silence clang warnings under --enable-expensive-hardening, including:
+ implicit truncation of 64 bit values to 32 bit;
+ const char assignment to self;
+ tautological compare; and
+ additional parentheses around equality tests. (gcc uses these to
silence assignment, so clang warns when they're present in an
equality test. But we need to use extra parentheses in macros to
isolate them from other code).
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
Ensure we securely wipe keys from memory after
crypto_digest_get_digest and init_curve25519_keypair_from_file
have finished using them.
Fixes bug 13477.
Also, refactor the way we handle failed handshakes so that this
warning doesn't propagate itself to "onion_skin_client_handshake
failed" and "circuit_finish_handshake failed" and
"connection_edge_process_relay_cell (at origin) failed."
Resolves warning from 9635.
1. The test that adds things to the cache needs to set the clock back so
that the descriptors it adds are valid.
2. We split ROUTER_NOT_NEW into ROUTER_TOO_OLD, so that we can
distinguish "already had it" from "rejected because of old published
date".
3. We make extrainfo_insert() return a was_router_added_t, and we
make its caller use it correctly. This is probably redundant with
the extrainfo_is_bogus flag.
One pain point in evolving the Tor design and implementing has been
adding code that makes clients reject directory documents that they
previously would have accepted, if those descriptors actually exist.
When this happened, the clients would get the document, reject it,
and then decide to try downloading it again, ad infinitum. This
problem becomes particularly obnoxious with authorities, since if
some authorities accept a descriptor that others don't, the ones
that don't accept it would go crazy trying to re-fetch it over and
over. (See for example ticket #9286.)
This patch tries to solve this problem by tracking, if a descriptor
isn't parseable, what its digest was, and whether it is invalid
because of some flaw that applies to the portion containing the
digest. (This excludes RSA signature problems: RSA signatures
aren't included in the digest. This means that a directory
authority can still put another directory authority into a loop by
mentioning a descriptor, and then serving that descriptor with an
invalid RSA signatures. But that would also make the misbehaving
directory authority get DoSed by the server it's attacking, so it's
not much of an issue.)
We already have a mechanism to mark something undownloadable with
downloadstatus_mark_impossible(); we use that here for
microdescriptors, extrainfos, and router descriptors.
Unit tests to follow in another patch.
Closes ticket #11243.
Bitwise check for the BRIDGE_DIRINFO flag, rather than checking for
equality.
Fixes a (potential) bug where directories offering BRIDGE_DIRINFO,
and some other flag (i.e. microdescriptors or extrainfo),
would be ignored when looking for bridge directories.
Final fix in series for bug 13163.
Document usage of the NO_DIRINFO and ALL_DIRINFO flags clearly in functions
which take them as arguments. Replace 0 with NO_DIRINFO in a function call
for clarity.
Seeks to prevent future issues like 13163.
Stop using the default authorities in networks which provide both
AlternateDirAuthority and AlternateBridgeAuthority.
This bug occurred due to an ambiguity around the use of NO_DIRINFO.
(Does it mean "any" or "none"?)
Partially fixes bug 13163.
Cases that now send errors:
* Malformed IP address (SOCKS5_GENERAL_ERROR)
* CONNECT/RESOLVE request with IP, when SafeSocks is set
(SOCKS5_NOT_ALLOWED)
* RESOLVE_PTR request with FQDN (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
* Malformed FQDN (SOCKS5_GENERAL_ERROR)
* Unknown address type (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
Fixes bug 13314.
Add the TestingDirAuthVoteExit option, a list of nodes to vote Exit for,
regardless of their uptime, bandwidth, or exit policy.
TestingTorNetwork must be set for this option to have any effect.
Works around an issue where authorities would take up to 35 minutes to
give nodes the Exit flag in a test network, despite short consensus
intervals. Partially implements ticket 13161.
Otherwise, when we authority try to do a self-test because of
init-keys, if that self-test can't be launched for whatever reason and
so we close the channel immediately, we crash.
Yes, this a silly way for initialization to work.
In circuit_build_times_calculate_timeout() in circuitstats.c, avoid dividing
by zero in the pareto calculations.
If either the alpha or p parameters are 0, we would divide by zero, yielding
an infinite result; which would be clamped to INT32_MAX anyway. So rather
than dividing by zero, we just skip the offending calculation(s), and
use INT32_MAX for the result.
Division by zero traps under clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error.
Avoid 4 null pointer errors under clang shallow analysis (the default when
building under Xcode) by using tor_assert() to prove that the pointers
aren't null. Resolves issue 13284 via minor code refactoring.
Bugfix on ed8f020e205267e6270494634346ab68d830e1d8; bug not in any
released version of Tor. Found by Coverity; this is CID 1239290.
[Yes, I used this commit message before, in 58e813d0fc.
Turns out, that fix wasn't right, since I didn't look up a
screen. :P ]
Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
When DisableNetwork is set, do not launch pluggable transport plugins,
and if any are running already, terminate the existing instances.
Resolves ticket 13213.
Allow clients to use optimistic data when connecting to a hidden service,
which should cut out the initial round-trip for client-side programs
including Tor Browser.
(Now that Tor 0.2.2.x is obsolete, all hidden services should support
server-side optimistic data.)
See proposal 181 for details. Implements ticket 13211.
Clients are now willing to send optimistic circuit data (before they
receive a 'connected' cell) to relays of any version. We used to
only do it for relays running 0.2.3.1-alpha or later, but now all
relays are new enough.
Resolves ticket 13153.
Return an error when the second or later arguments of the
"setevents" controller command are invalid events. Previously we
would return success while silently skipping invalid events.
Fixes bug 13205; bugfix on 0.2.3.2-alpha. Reported by "fpxnns".
Stop modifying the value of our DirReqStatistics torrc option just
because we're not a bridge or relay. This bug was causing Tor
Browser users to write "DirReqStatistics 0" in their torrc files
as if they had chosen to change the config.
Fixes bug 4244; bugfix on 0.2.3.1-alpha.
Clients now send the correct address for their chosen rendezvous point
when trying to access a hidden service. They used to send the wrong
address, which would still work some of the time because they also
sent the identity digest of the rendezvous point, and if the hidden
service happened to try connecting to the rendezvous point from a relay
that already had a connection open to it, the relay would reuse that
connection. Now connections to hidden services should be more robust
and faster. Also, this bug meant that clients were leaking to the hidden
service whether they were on a little-endian (common) or big-endian (rare)
system, which for some users might have reduced their anonymity.
Fixes bug 13151; bugfix on 0.2.1.5-alpha.
"At this point in the code, msg has been set to a string
constant. But the tor code checks that msg is not NULL, and the
redundant NULL check confuses the analyser[...] To avoid this
spurious warning, the patch initialises msg to NULL."
Patch from teor. another part of 13157.
Tor Browser includes several ClientTransportPlugin lines in its
torrc-defaults file, leading every Tor Browser user who looks at her
logs to see these notices and wonder if they're dangerous.
Resolves bug 13124; bugfix on 0.2.5.3-alpha.
Technically, we're not allowed to take the address of a member can't
exist relative to the null pointer. That makes me wonder how any sane
compliant system implements the offsetof macro, but let's let sleeping
balrogs lie.
Fixes 13096; patch on 0.1.1.9-alpha; patch from "teor", who was using
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
This implements the meat of #12899. This commit should simply remove the
parts of Tor dirauths used to check whether a relay was supposed to be
named or not, it doesn't yet convert to a new mechanism for
reject/invalid/baddir/badexiting relays.
Back in 078d6bcd, we added an event number 0x20, but we didn't make
the event_mask field big enough to compensate.
Patch by "teor". Fixes 13085; bugfix on 0.2.5.1-alpha.
This function never returns non-null, but its usage doesn't reflect
that. Let's make it explicit. This will be mostly overridden by later
commits, so no changes file here.
This is in preparation for a big patch series removing the entire Naming
system from Tor. In its wake, the approved-routers file is being
deprecated, and a replacement option to allow only pre-approved routers
is not being implemented.
This implements a feature from bug 13000. Instead of starting a bwauth
run with this wrong idea about their bw, relays should do the self-test
and then get measured.
When a tor relay starts up and has no historical information about its
bandwidth capability, it uploads a descriptor with a bw estimate of 0.
It then starts its bw selftest, but has to wait 20 minutes to upload the
next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change
should mean that on average, relays start seeing meaningful traffic a
little quicker, since they will have a higher chance to appear in the
consensus with a nonzero bw.
Patch by Roger, changes file and comment by Sebastian.
We're calling mallocfn() and reallocfn() in the HT_GENERATE macro
with the result of a product. But that makes any sane analyzer
worry about overflow.
This patch keeps HT_GENERATE having its old semantics, since we
aren't the only project using ht.h. Instead, define a HT_GENERATE2
that takes a reallocarrayfn.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
It's now a protocol-warn, since there's nothing relay operators can
do about a client that sends them a malformed create cell.
Resolves bug 12996; bugfix on 0.0.6rc1.
Previously, we had done this only in the connection_free() case, but
when we called connection_free_() directly from
connections_free_all(), we didn't free the connections.
The fix for bug 4647 accidentally removed our hack from bug 586 that
rewrote HashedControlPassword to __HashedControlSessionPassword when
it appears on the commandline (which allowed the user to set her own
HashedControlPassword in the torrc file while the controller generates
a fresh session password for each run).
Fixes bug 12948; bugfix on 0.2.5.1-alpha.
This modifies the format of the bridge networkstatus documents produced
by the BridgeAuth. The new format adds a `published` line to the header
of the file, before the `flag-thresholds` line. This is done once per
networkstatus file that is written. The timestamp in the `published`
line is the standard ISO 8601 format (with a space as the separator)
used throughout the rest of tor.
* FIXES#12951https://bugs.torproject.org/12951
Using the *_array() functions here confused coverity, and was actually
a bit longer than we needed. Now we just use macros for the repeated
bits, so that we can mention a file and a suffix-appended version in
one line.
We had some code to fix up the 'status' return value to -1 on error
if it wasn't set, but it was unreachable because our code was
correct. Tweak this by initializing status to -1, and then only
setting it to 0 on success. Also add a goto which was missing: its
absence was harmless.
[CID 718614, 718616]
(We allowed it previously, but produced an LD_BUG message when it
happened, which is not consistent
Also, remove inconsistent NULL checks before calling
rend_service_intro_free.
(Removing the check is for CID 718613)
Coverity doesn't like doing NULL checks on things that can't be
NULL; I like checking things where the logic for their not being
NULL is nontrivial. Let's compromise, and make it obvious that this
field can't be NULL.
[Coverity CID 202004]
Coverity thinks that when we do "double x = int1/int2;", we probably
meant "double x = ((double)int1) / int2;". In these cases, we
didn't.
[Coverity CID 1232089 and 1232090]
Two bugs here:
1) We didn't add EXTEND2/EXTENDED2 to relay_command_to_string().
2) relay_command_to_string() didn't log the value of unrecognized
commands.
Both fixed here.
This will fix the warning
"/src/or/config.c:6854:48: error: unused parameter 'group_readable'"
that I introduced while fixing 12864.
Bug not in any released version of Tor.
Implements proposal 215; closes ticket 10163.
Why? From proposal 215:
Consensus method 1 is no longer viable for the Tor network. It
doesn't result in a microdescriptor consensus, and omits other
fields that clients need in order to work well. Consensus methods
under 12 have security issues, since they let a single authority
set a consensus parameter.
...
For example, while Tor 0.2.4.x is under development, authorities
should really not be running anything before Tor 0.2.3.x. Tor
0.2.3.x has supported consensus method 13 since 0.2.3.21-rc, so
it's okay for 0.2.4.x to require 13 as the minimum method. We even
might go back to method 12, since the worst outcome of not using 13
would be some warnings in client logs. Consensus method 12 was a
security improvement, so we don't want to roll back before that.
When we merged the cookieauthfile creation logic in 33c3e60a37, we
accidentally took out this feature. Fixes bug 12864, bugfix on
0.2.5.1-alpha.
Also adds an ExtORPortCookieAuthFileGroupReadable, since there's no
reason not to.
I looked for other places where we set circ->n_chan early, and found
one in circuit_handle_first_hop() right before it calls
circuit_send_next_onion_skin(). If onion_skin_create() fails there,
then n_chan will still be set when circuit_send_next_onion_skin()
returns. We should probably fix that too.
When Tor starts with DisabledNetwork set, it would correctly
conclude that it shouldn't try making circuits, but it would
mistakenly cache this conclusion and continue believing it even
when DisableNetwork is set to 0. Fixes the bug introduced by the
fix for bug 11200; bugfix on 0.2.5.4-alpha.
Those used to be normal to receive on hidden service circuits due to bug
1038, but the buggy Tor versions are long gone from the network so we
can afford to resume watching for them. Resolves the rest of bug 1038;
bugfix on 0.2.1.19.
Roger spotted this on tor-dev in his comments on proposal 221.
(Actually, detect DESTROY vs everything else, since arma likes
network timeout indicating failure but not overload indicating failure.)
Authorities now assign the Guard flag to the fastest 25% of the
network (it used to be the fastest 50%). Also raise the consensus
weight that guarantees the Guard flag from 250 to 2000. For the
current network, this results in about 1100 guards, down from 2500.
This step paves the way for moving the number of entry guards
down to 1 (proposal 236) while still providing reasonable expected
performance for most users.
Implements ticket 12690.
Otherwise, it always seems as though our Exclude* options have
changed, since we're comparing modified to unmodified values.
Patch from qwerty1. Fixes bug 9801. Bugfix on 0.2.4.10-alpha, where
GeoIPExcludeUnknown was introduced.
Currently tor fails to build its test when enabled with bufferevents
because an #ifndef USE_BUFFEREVENTS hides bucket_millis_empty() and
friends. This is fine if we don't run tests, but if we do, we need
these functions in src/or/libtor-testing.a when linking src/test/test.
This patch moves the functions outside the #ifndef and exposes them.
See downstream bug:
https://bugs.gentoo.org/show_bug.cgi?id=510124
When we run into bug 8387 (if we run into it again), report when we
last called circuit_expire_old_circuits_clientside(). This will let
us know -- if my fix for 8387 doesn't work -- whether my diagnosis
was at least correct.
Suggested by Andrea.
We should only assign a relay the HSDir flag if it is currently
considered valid. We can accomplish this by only considering active
relays, and as a consequence of this we also exclude relays that are
currently hibernating. Fixes#12573
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
The variable was useless since it was only toggled off in disabled code.
If the 'exit_family' smartlist is empty, we don't consider exit family
anyway.
Check for consistency between the queued destroy cells and the marked
circuit IDs. Check for consistency in the count of queued destroy
cells in several ways. Check to see whether any of the marked circuit
IDs have somehow been marked longer than the channel has existed.
And add a comment about why conditions that would cause us to drop a
cell should get checked before actions that would cause us to send a
destroy cell.
Spotted by 'cypherpunks'.
And note that these issues have been present since 0.0.8pre1 (commit
0da256ef), where we added a "shutting down" state, and started
responding to all create cells with DESTROY when shutting down.
Conflicts:
src/or/channel.c
src/or/circuitlist.c
src/or/connection.c
Conflicts involved removal of next_circ_id and addition of
unusable-circid tracking.
The point of the "idle timeout" for connections is to kill the
connection a while after it has no more circuits. But using "last
added a non-padding cell" as a proxy for that is wrong, since if the
last circuit is closed from the other side of the connection, we
will not have sent anything on that connection since well before the
last circuit closed.
This is part of fixing 6799.
When applied to 0.2.5, it is also a fix for 12023.
Instead of killing an or_connection_t that has had no circuits for
the last 3 minutes, give every or_connection_t a randomized timeout,
so that an observer can't so easily infer from the connection close
time the time at which its last circuit closed.
Also, increase the base timeout for canonical connections from 3
minutes to 15 minutes.
Fix for ticket 6799.
When we find a stranded one-hop circuit, log whether it is dirty,
log information about any streams on it, and log information about
connections they might be linked to.
This code mis-handled the case where a circuit got the same circuit
ID in both directions. I found three instances of it in the
codebase, by grepping for [pn]_circ_id.
Because of the issue in command_process_relay_cell(), this would
have made roughly one circuit in a million completely nonfunctional.
Fixes bug 12195.
On some profiles of Andrea's from #11332, I found that a great deal
of time can still be attributed to functions called from
update_router_have_minimum_dir_info(). This is making our
digestmap, tor_memeq, and siphash functions take a much bigger
portion of runtime than they really should.
If we're calling update_router_have_minimum_dir_info() too often,
that's because we're calling router_dir_info_changed() too often.
And it looks like most of the callers of router_dir_info_changed()
are coming as tail-calls from router_set_status() as invoked by
channel_do_open_actions().
But we don't need to call router_dir_info_changed() so much! (I'm
not quite sure we need to call it from here at all, but...) Surely
we don't need to call it from router_set_status when the router's
status has not actually changed.
This patch makes us call router_dir_info_changed() from
router_set_status only when we are changing the router's status.
Fix for bug 12170. This is leftover from our fix back in 273ee3e81
in 0.1.2.1-alpha, where we started caching the value of
update_router_have_minimum_dir_info().
tor_memeq has started to show up on profiles, and this is one of the
most frequent callers of that function, appearing as it does on every
cell handled for entry or exit.
59f9097d5c introduced tor_memneq here;
it went into Tor 0.2.1.31. Fixes part of 12169.
Without this fix, when running with bridges, we would try fetching
directory info far too early, and have up to a 60 second delay if we
started with bridge descriptors available.
Fixes bug 11965. Fix on 0.2.3.6-alpha, arma thinks.
The old cache had problems:
* It needed to be manually preloaded. (It didn't remember any
address you didn't tell it to remember)
* It was AF_INET only.
* It looked at its cache even if the sandbox wasn't turned on.
* It couldn't remember errors.
* It had some memory management problems. (You can't use memcpy
to copy an addrinfo safely; it has pointers in.)
This patch fixes those issues, and moves to a hash table.
Fixes bug 11970; bugfix on 0.2.5.1-alpha.
The code was not disambiguating ClientTransportPlugin configured and
not used, and ClientTransportPlugin configured, but in a failed state.
The right thing to do is to undo moving the get_transport_by_addrport()
call back into get_proxy_addrport(), and remove and explicit check for
using a Bridge since by the time the check is made, if a Bridge is
being used, it is PT/proxy-less.
This change allows using Socks4Proxy, Socks5Proxy and HTTPSProxy with
ClientTransportPlugins via the TOR_PT_PROXY extension to the
pluggable transport specification.
This fixes bug #8402.
