| Commit message (Collapse) | Author | Age |
... | |
|\| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/or/dirserv.c
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
|\| | | | | | |
|
| |\ \ \ \ \ \
| | |/ / / / /
| |/| | | / /
| | | |_|/ /
| | |/| | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix for bug 5650. Also, if we get a WANTREAD while reading while
writing, make sure we're reading.
|
|\| | | | | |
|
| |\ \ \ \ \
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
doc/tor.1.txt
src/or/config.c
src/or/connection.c
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This might be necessary if the bug8117 fix confuses any applications.
Also add a changes file.
|
| | | | | |
|
|\| | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds a new option to fix bug 8508 which broke chutney
networks. The bug was introduced by 317d16de.
|
|\| | | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
doc/tor.1.txt
src/or/circuitbuild.c
src/or/config.c
src/or/or.h
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes 8240.
(Don't actually increase the default guard lifetime. It seems likely to
break too many things if done precipitiously.)
|
|\| | | | |
|
| |\ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also, don't call the exit node 'reject *' unless our decision to pick
that node was based on a non-summarized version of that node's exit
policy.
rransom and arma came up with the ideas for this fix.
Fix for 7582; the summary-related part is a bugfix on 0.2.3.2-alpha.
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/common/util.c
src/or/entrynodes.h
|
| | |_|_|/
| |/| | | |
|
|\ \ \ \ \ |
|
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In a number of places, we decrement timestamp_dirty by
MaxCircuitDirtiness in order to mark a stream as "unusable for any
new connections.
This pattern sucks for a few reasons:
* It is nonobvious.
* It is error-prone: decrementing 0 can be a bad choice indeed.
* It really wants to have a function.
It can also introduce bugs if the system time jumps backwards, or if
MaxCircuitDirtiness is increased.
So in this patch, I add an unusable_for_new_conns flag to
origin_circuit_t, make it get checked everywhere it should (I looked
for things that tested timestamp_dirty), and add a new function to
frob it.
For now, the new function does still frob timestamp_dirty (after
checking for underflow and whatnot), in case I missed any cases that
should be checking unusable_for_new_conns.
Fixes bug 6174. We first used this pattern in 516ef41ac1fd26f338c,
which I think was in 0.0.2pre26 (but it could have been 0.0.2pre27).
|
|\ \ \ \ \ |
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This should have been 2 bytes all along, since version numbers can
be 16 bits long. This isn't a live bug, since the call to
is_or_protocol_version_known in channel_tls_process_versions_cell
will reject any version number not in the range 1..4. Still, let's
fix this before we accidentally start supporting version 256.
Reported pseudonymously. Fixes bug 8062; bugfix on 0.2.0.10-alpha --
specifically, on commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
type of link_proto.
|
|\ \ \ \ \ |
|
| | |/ / /
| |/| | | |
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In addition to rejecting them post-hoc, avoid picking them in the
first place. This makes us less likely to decide that we can't add
guards at all.
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently something in the directory guard code made it possible
for the same node to get added as a guard over and over when there
were no actual running guard nodes.
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
|
| | |/ /
| |/| | |
|
| | | |
| | | |
| | | |
| | | | |
resolves ticket 8443.
|
| | | |
| | | |
| | | |
| | | | |
no actual changes in behavior yet
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
I have no idea whether b0rken clients will DoS the network if the v2
authorities all turn this on or not. It's experimental. See #6783 for
a description of how to test it more or less safely, and please be
careful!
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch moves the measured_bw field and the has_measured_bw field
into vote_routerstatus_t, since only votes have 'Measured=XX' set on
their weight line.
I also added a new bw_is_unmeasured flag to routerstatus_t to
represent the Unmeasured=1 flag on a w line. Previously, I was using
has_measured_bw for this, which was quite incorrect: has_measured_bw
means that the measured_bw field is set, and it's probably a mistake
to have it serve double duty as meaning that 'baandwidth' represents a
measured value.
While making this change,I also found a harmless but stupid bug in
dirserv_read_measured_bandwidths: It assumes that it's getting a
smartlist of routerstatus_t, when really it's getting a smartlist of
vote_routerstatus_t. C's struct layout rules mean that we could never
actually get an error because of that, but it's still quite incorrect.
I fixed that, and in the process needed to add two more sorting and
searching helpers.
Finally, I made the Unmeasured=1 flag get parsed. We don't use it for
anything yet, but someday we might.
This isn't complete yet -- the new 2286 unit test doesn't build.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of capping whenever a router has fewer than 3 measurements,
we cap whenever a router has fewer than 3 measurements *AND* there
are at least 3 authorities publishing measured bandwidths.
We also generate bandwidth lines with a new "Unmeasured=1" flag,
meaning that we didn't have enough observations for a node to use
measured bandwidth values in the authority's input, whether we capped
it or not.
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/or/channel.h
src/or/connection_or.c
src/or/cpuworker.c
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implements proposal 214.
Needs testing.
|
| |/ /
|/| |
| | |
| | |
| | |
| | | |
To avoid surprises, good coding practice suggests parenthesizing every
macro definition -- or at the very least, all those involving an
expression.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is ticket 7706, reported by "bugcatcher." The rationale here
is that if somebody says 'ExcludeNodes {tv}', then they probably
don't just want to block definitely Tuvaluan nodes: they also want
to block nodes that have unknown country, since for all they know
such nodes are also in Tuvalu.
This behavior is controlled by a new GeoIPExcludeUnknown autobool
option. With the default (auto) setting, we exclude ?? and A1 if
any country is excluded. If the option is 1, we add ?? and A1
unconditionally; if the option is 0, we never add them.
(Right now our geoip file doesn't actually seem to include A1: I'm
including it here in case it comes back.)
This feature only takes effect if you have a GeoIP file. Otherwise
you'd be excluding every node.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also document it better.
Mention this refactoring in the comments for the path state machine.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.
|
| | | | |
|
| | | | |
|
|\ \ \ \ |
|