| Age | Commit message (Collapse) | Author |
|---|
|
Allow MapAddress to handle directives such as:
MapAddress .torproject.org .torserver.exit
MapAddress .org 1.1.1.1
Add tests for addressmap_rewrite.
|
|
|
|
Fixes bug 3421
|
|
|
|
Suggested by arma; based on 3327.
|
|
Use a list of headers rather than trying to printf every header that
might exist.
|
|
Right now we only force a new descriptor upload every 18 hours.
This can make servers become unlisted if they upload a descriptor at
time T which the authorities reject as being "too similar" to one
they uploaded before. Nothing will actually make the server upload a
new descriptor later on, until another 18 hours have passed.
This patch changes the upload behavior so that the 18 hour interval
applies only when we're listed in a live consensus with a descriptor
published within the last 18 hours. Otherwise--if we're not listed
in the live consensus, or if we're listed with a publication time
over 18 hours in the past--we upload a new descriptor every 90
minutes.
This is an attempted bugfix for #3327. If we merge it, it should
obsolete #535.
|
|
Conflicts:
src/or/dirserv.c
src/or/networkstatus.c
Conflicts were related to routerinfo->node shift.
|
|
|
|
|
|
Conflicts:
src/or/connection.c
src/or/connection_edge.c
src/or/connection_edge.h
src/or/dnsserv.c
Some of these were a little tricky, since they touched code that
changed because of the prop171 fixes.
|
|
tor_asprintf already asserts if it fails.
|
|
|
|
Conflicts:
src/or/connection_edge.c
Conflicted on a router->node transition; fix was easy.
|
|
Fixes bug 3923; bugfix on 0.2.2.25-alpha; bugfix from 'laruldan' on trac.
|
|
This should fix bug 3888.
|
|
This should help us easily spot if a tor was built with
--enable-bufferevent or not
|
|
|
|
For bufferevents, we had all of connection_buckets_decrement() stubbed
out. But that's not actually right! The rephist_* parts were
essential for, inter alia, recording our own bandwidth. This patch
splits out the rephist parts of connection_buckets_decrement() into their
own function, and makes the bufferevent code call that new function.
Fixes bug 3803, and probably 3824 and 3826 too. Bugfix on 0.2.3.1-alpha.
|
|
Previously, if you were set up to use microdescriptors, and you
weren't a cache, you'd never fetch router descriptors (except for
bridges). Now FetchUselessDescriptors causes descriptors and
mirodescs to get cached. Also, FetchUselessDescriptors changes the
behavior of "UseMicrodescriptors auto" to be off, since there's no
point in saying "UseMicrodescriptors 1" when you have full descriptors
too.
Fix for bug 3851; bugfix on 0.2.3.1-alpha.
|
|
|
|
Because tunneled connections are implemented with buffervent_pair,
writing to them can cause an immediate flush. This means that
added to them and then checking to see whether their outbuf is
empty is _not_ an adequate way to see whether you added anything.
This caused a problem in directory server connections, since they
would try spooling a little more data out, and then close the
connection if there was no queued data to send.
This fix should improve matters; it only closes the connection if
there is no more data to spool, and all of the spooling callbacks
are supposed to put the dirconn into dir_spool_none on completion.
This is bug 3814; Sebastian found it; bugfix on 0.2.3.1-alpha.
|
|
If we don't do this, then we never invoke the bufferevent write
callbacks until all the bufferevent's data is flushed.
|
|
When we're doing filtering ssl bufferevents, we want the rate-limits
to apply to the lowest level of the bufferevent stack, so that we're
actually limiting bytes sent on the network. Otherwise, we'll read
from the network aggressively, and only limit stuff as we process it.
|
|
|
|
This behavior is normal when we want more data than the evbuffer
actually has for us. We'll ask for (say) 7 bytes, get only 5
(because that's all there is), try to parse the 5 bytes, and get
told "no, I want 7". One option would be to bail out early whenever
want_length is > buflen, but sometimes we use an over-large
want_length. So instead, let's just remove the warning here: it's
not a bug after all.
|
|
|
|
|
|
Conflicts:
src/or/config.c
|
|
Fix for bug 3747; bugfix on 0.2.2.26-beta.
|
|
|
|
|
|
ddc65e2b3303559ab7b842a176ee6c2eda9e4027 had broken this
|
|
|
|
|
|
|
|
|
|
It turns out that it wasn't enough to set the configuration to
"auto", since the correct behavior for "auto" had been disabled in
microdesc.c. :p
(Hasn't been in a release yet, so doesn't need a changes entry.)
|
|
|
|
visibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since the prop171 stuff, it had instead made Tor bind port 0, and
re-bind it differently all the time.
Resolves bug3704; not in any released version.
|
|
|
|
|
