Age | Commit message (Collapse) | Author |
|
|
|
|
|
Fixes bug21799.
|
|
|
|
These commments were complaints about how I didn't like some aspects
of prop271. They have been superseded by ticket 20832.
|
|
|
|
|
|
|
|
Part of 20830.
|
|
This is the same as we fixed in 39f455468731d4746adb729a67.
|
|
|
|
I broke this with 20292ec4974b777d430e7962cc38349c5f82b220 when I
changed the primary guard retry schedule.
|
|
Now that we support NumEntryGuards, NumDirectoryGuards is pretty
easy to put back in.
|
|
This will make it easier to see what we remove down the line.
|
|
|
|
|
|
|
|
|
|
|
|
The test assumed that the old rules about handling small max_sample
were in effect, and didn't actually handle that case very well
anyway.
|
|
This is an important thing I hadn't considered when writing prop271:
sometimes you have to restrict what guard you use for a particular
circuit. Most frequently, that would be because you plan to use a
certain node as your exit, and so you can't choose that for your
guard.
This change means that the upgrade-waiting-circuits algorithm needs
a slight tweak too: circuit A cannot block circuit B from upgrading
if circuit B needs to follow a restriction that circuit A does not
follow.
|
|
|
|
George pointed out that (-1,0,1) for (never usable, maybe usable
later, usable right now) was a pretty rotten convention that made
the code harder to read.
|
|
This includes:
* making bridge_info_t exposed but opaque
* allowing guards where we don't know an identity
* making it possible to learn the identity of a guard
* creating a guard that lacks a node_t
* remembering a guard's address and port.
* Looking up a guard by address and port.
* Only enforcing the rule that we need a live consensus to update
the "listed" status for guards when we are not using bridges.
|
|
This prevents us from mixing up multiple guard_selections
|
|
Currently, this code doesn't actually have the contexts behave
differently, (except for the legacy context), but it does switch
back and forth between them nicely.
|
|
|
|
|
|
|
|
Some of these will get torrc options to override them too; this
is just the mechanical conversion.
Also, add documentation for a couple of undocumented (but now used)
parameters.
|
|
|
|
|
|
(Plus some magic to prevent and detect recursive invocation of
entry_guards_update_primary(), since that can cause some pretty
tricky misbehavior.)
|
|
To do this, it makes sense to treat legacy guards as a separate
guard_selection_t *, and handle them separately. This also means we
add support here for having multiple guard selections.
Note that we don't persist pathbias information yet; that will take
some refactoring.
|
|
I expect we'll be ripping this out somewhere in 0.3.0, but let's
keep it around for a little while in case it turns out to be the
only way to avert disaster?
|
|
This code handles:
* Maintaining the sampled set, the filtered set, and the
usable_filtered set.
* Maintaining the confirmed and primary guard lists.
* Picking guards for circuits, and updating guard state when
circuit state changes.
Additionally, I've done code structure movement: even more constants
and structures from entrynodes.c have become ENTRYNODES_PRIVATE
fields of entrynodes.h.
I've also included a bunch of documentation and a bunch of unit
tests. Coverage on the new code is pretty high.
I've noted important things to resolve before this branch is done
with the /XXXX.*prop271/ regex.
|
|
The encoding code is very straightforward. The decoding code is a
bit tricky, but clean-ish. The sampling code is untested and
probably needs more work.
|
|
This function helpfully removes all but one remaining use of
an entry_guard_t private field in pathbias.c
|
|
(Other than the field movement, the code changes here are just
search-and-replace)
|
|
guard_selection_t structure
|
|
|
|
When ClientPreferIPv6ORPort is auto, bridges prefer the configured
bridge ORPort address. Otherwise, they use the value of the option.
Other clients prefer IPv4 ORPorts if ClientPreferIPv6ORPort is auto.
When ClientPreferIPv6DirPort is auto, all clients prefer IPv4 DirPorts.
|
|
Consequential changes to log messages:
* it's no longer possible to disable both IPv4 and IPv6,
* refactor common string out of remaining log messages
|
|
Bridge clients ignore ClientUseIPv6, acting as if it is always 1.
This preserves existing behaviour.
Make ClientPreferIPv6OR/DirPort auto by default:
* Bridge clients prefer IPv6 by default.
* Other clients prefer IPv4 by default.
This preserves existing behaviour.
|
|
Update unit tests.
|
|
ClientUseIPv4 0 tells tor to avoid IPv4 client connections.
ClientPreferIPv6DirPort 1 tells tor to prefer IPv6 directory connections.
Refactor policy for IPv4/IPv6 preferences.
Fix a bug where node->ipv6_preferred could become stale if
ClientPreferIPv6ORPort was changed after the consensus was loaded.
Update documentation, existing code, add unit tests.
|
|
We no longer base our opinion on whether someone is a directory solely
on the routerstatus we might have for that relay, but also on a
routerinfo. Remove logic in test checking that. This broke unit tests in
05f7336624d6a47b3cf0f.
Reported by toralf on #tor-dev, thanks!
|
|
|
|
Conflicts:
src/or/dirvote.h
src/test/include.am
src/test/test_entrynodes.c
|
|
We want to use this function in our guardfraction unittests, so make a
test_helpers module and move it there.
|