| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.
|
|
|
|
|
|
The right way to set "MaxOnionsPending" was to adjust it until the
processing delay was appropriate. So instead, let's measure how long
it takes to process onionskins (sampling them once we have a big
number), and then limit the queue based on its expected time to
finish.
This change is extra-necessary for ntor, since there is no longer a
reasonable way to set MaxOnionsPending without knowing what mix of
onionskins you'll get.
This patch also reserves 1/3 of the onionskin spots for ntor
handshakes, on the theory that TAP handshakes shouldn't be allowed to
starve their speedier cousins. We can change this later if need be.
Resolves 7291.
|
|
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
|
|
|
|
|
|
|
|
|
Closes bug #7730.
|
|
|
|
With an IPv6 virtual address map, we can basically hand out a new
IPv6 address for _every_ address we connect to. That'll be cool, and
will let us maybe get around prop205 issues.
This uses some fancy logic to try to make the code paths in the ipv4
and the ipv6 case as close as possible, and moves to randomly
generated addresses so we don't need to maintain those stupid counters
that will collide if Tor restarts but apps don't.
Also has some XXXX items to fix to make this useful. More design
needed.
|
|
|
|
|
|
|
|
|
|
|
|
This clears up the remaining issue stopping me from closing bug 6297.
|
|
|
|
|
|
|
|
This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/or/geoip.c
|
|
It seems as if our new build system broke gcov for me. I've tried to
fix doc/HACKING to describe what I needed to do in order to make it
work again.
|
|
|
|
|
|
Implements ticket 6786.
|
|
|
|
|
|
Also remove some trailing whitespace.
Patch from maker; fixes bug 6024.
|
|
Fixes bug 6843; bugfix on 0.2.4.1-alpha.
|
|
|
|
|
|
addresses bug 6605.
|
|
|
|
|
|
The current cutoff is 30KB, but in reality a useful cutoff is probably
more like 50KB or 100KB.
|
|
Conflicts:
doc/tor.1.txt
src/or/config.c
|
|
* Add changes/ files.
* Edit the tor-fw-helper manpage.
* Fix check-spaces.
* Add prototype for get_list_of_ports_to_forward().
* Fix tor_parse_long() TCP port range.
* Improve doc. of tor_check_port_forwarding().
* Check for overflows in tor_check_port_forwarding().
* Demote successful port forwarding to LOG_INFO.
Conflicts:
src/common/address.c
src/or/circuitbuild.c
|
|
See #4771 for rationale.
Note that this patch does not take suggested changes in #4470 into
account and keeps treating AuthDirHasIPv6Connectivity as an
AUTOBOOL. Thus, bug fixes for that are included here as well.
This is a fix on master, unreleased as of now.
|
|
This is a fix of unreleased tor. It solves ticket #6770.
|
|
|
|
Add ClientUseIPv6 and ClientPreferIPv6ORPort configuration options.
Use "preferred OR port" for all entry nodes, not only for bridges.
Mark bridges with "prefer IPv6 OR port" if an IPv6 address is
configured in Bridge line and ClientPreferIPv6ORPort is set.
Mark relays with "prefer IPv6 OR port" if an IPv6 address is found in
descriptor and ClientPreferIPv6ORPort is set.
Filter "preferred OR port" through the ClientUseIPv6 config option. We
might want to move this test to where actual connection is being set
up once we have a fall back mechanism in place.
Have only non-servers pick an IPv6 address for the first hop: We
don't want relays to connect over IPv6 yet. (IPv6 has never been used
for second or third hops.)
Implements ticket 5535.
|
|
This is the preferred filename to use with Autoconf 2.50 and later.
|
