| Commit message (Collapse) | Author | Age |
| ... | |
| | | | | | | | | |
|
| | |_|_|_|/ / /
|/| | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
configure.in
contrib/tor-mingw.nsi.in
src/win32/orconfig.h
|
| | | | | | | | |
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | | |
also put in release blurbs
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
So far we just had the asciidoc manpage, but didn't build it.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- For now we are only talking about moving clients to be bridges
- Some questions on how we should inform users
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
via email
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
their state manually.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- Initial draft of overview and motivation
- Start of design
|
| |\ \ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
all rpm-based distributions
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
needs higher permissions.
|
| |\ \ \ \ \ \ \
| |/ / / / / /
| | / / / / /
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
configure.in
contrib/tor-mingw.nsi.in
src/win32/orconfig.h
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
src/common/util.c
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* MINIUPNPC rather than the generic UPNP
* Nick suggested a better abstraction model for tor-fw-helper
* Fix autoconf to build with either natpmp or miniupnpc
* Add AM_PROG_CC_C_O to fix automake complaint
* update spec to address nickm's concern
* refactor nat-pmp to match upnp state
* we prefer tor_snprintf to snprintf
* link properlty for tor_snprintf
* rename test_commandline_options to log_commandline_options
* cast this uint as an int
* detect possible FD_SETSIZE errors
* make note about future enhancements for natpmp
* add upnp enhancement note
* ChangeLog entry
* doxygen and check-spaces cleanup
* create tor-fw-helper.1.txt
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-fw-helper is a command-line tool to wrap and abstract various
firewall port-forwarding tools.
This commit matches the state of Jacob's tor-fw-helper branch as of
23 September 2010.
(commit msg by Nick)
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| / / / / /
| |/ / / / / |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When picking bridges (or other nodes without a consensus entry (and
thus no bandwidth weights)) we shouldn't just trust the node's
descriptor. So far we believed anything between 0 and 10MB/s, where 0
would mean that a node doesn't get any use from use unless it is our
only one, and 10MB/s would be a quite siginficant weight. To make this
situation better, we now believe weights in the range from 20kB/s to
100kB/s. This should allow new bridges to get use more quickly, and
means that it will be harder for bridges to see almost all our traffic.
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |/ / / / / |
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This won't change any behavior, since it will still be rounded back
up to 2seconds, but should reduce the chances of some extra warns.
|
| | |\ \ \ \ \ \ |
|
| | | |/ / / / / |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In the first 100 circuits, our timeout_ms and close_ms
are the same. So we shouldn't transition circuits to purpose
CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT, since they will just timeout again
next time we check.
|