If you have more than one bridge but don't know their keys,
you would only learn a request for the descriptor of the first one
on your list. (Tor considered launching requests for the others, but
found that it already had a connection on the way for $0000...0000
so it didn't open another.)
If you have more than one bridge but don't know their keys, and the
connection to one of the bridges failed, you would cancel all
pending bridge connections. (After all, they all have the same
digest.)
svn:r15366
Only dump all guard node status to the log when the guard node status actually changes. Downgrade the 4 most common remaining INFO log messages to DEBUG.
svn:r14069
Add a bunch more code documentation; change the interface of fetch_var_cell_from_buf() so it takes the current link protocol into account and can't get confused by weird command bytes on v1 connections.
svn:r13430
Initial attempts to track down bug 600, and refactor possibly offending code. 1) complain early if circuit state is set to OPEN when an onionskin is pending. 2) refactor onionskin field into one only used when n_conn is pending, and a separate onionskin field waiting for attention by a cpuworker. This might even fix the bug. More likely, it will make it fail with a more useful core.
svn:r13394
When we load a bridge descriptor from the cache,
and it was previously unreachable, mark it as retriable so we won't
just ignore it. Also, try fetching a new copy immediately.
svn:r12950
Refactor circuit_launch* functions to take a bitfield of flags rather than 4 separate nonconsecutive flags arguments. Also, note a possible but in circuit_find_to_cannibalize, which seems to be ignoring its purpose argument.
svn:r12948
unexpected (it used to be in our networkstatus when we started
fetching it, but it isn't in our current networkstatus), and we
aren't using bridges. Bugfix on 0.2.0.x.
svn:r12911
using bridges or we have StrictEntryNodes set), don't mark relays
down when they fail a directory request. Otherwise we're too quick
to mark all our entry points down.
svn:r12755
enough directory information. This was causing us to always pick
two new guards on startup (bugfix on 0.2.0.9-alpha), and it was
causing us to discard all our guards on startup if we hadn't been
running for a few weeks (bugfix on 0.1.2.x). Fixes bug 448.
svn:r12570
the bridge authority could help us (for example, we don't know
a digest, or there is no bridge authority), don't be so eager to
fall back to asking the bridge authority.
svn:r12512
Add a bunch of function documentation; clean up a little code; fix some XXXXs; tag the nonsensical EXTRAINFO_PURPOSE_GENERAL as nonsesnse; note another bit of "do not cache special routers" code to nuke.
svn:r11761
users configure that and specify a bridge with an identity
fingerprint, now they will lookup the bridge descriptor at the
default bridge authority via a one-hop tunnel, but once circuits
are established they will switch to a three-hop tunnel for later
connections to the bridge authority.
svn:r11550
Add a line to the state file for each guard to let us know which version added the guard. If the line is absent, assume the guard was added by whatever version of Tor last wrote the state file. Remove guards if the version that added them was using a bad guard selection algorithm. (Previously, we removed guards if the version that wrote the file was using a bad guard selection algorithm, even if the guards themselves were chosen by a good version.)
svn:r11298
When we are loading state info from disk, never believe any date in the future. Doing so can keep us from retrying guards, rotating onion keys, storing bandwidth info, etc. Fixes bug 434, and others. Backport candidate, once it has been tested.
svn:r11166
