There is a bug causing busy loops in Libevent and infinite loops in
the Shadow simulator. A connection that is marked for close, wants
to flush, is held open to flush, but is rate limited (the token
bucket is empty) triggers the bug.
This commit fixes the bug. Details are below.
This currently happens on read and write callbacks when the active
socket is marked for close. In this case, Tor doesn't actually try
to complete the read or write (it returns from those methods when
marked), but instead tries to clear the connection with
conn_close_if_marked(). Tor will not close a marked connection that
contains data: it must be flushed first. The bug occurs when this
flush operation on the marked connection can not occur because the
connection is rate-limited (its write token bucket is empty).
The fix is to detect when rate limiting is preventing a marked
connection from properly flushing. In this case, it should be
flagged as read/write_blocked_on_bandwidth and the read/write events
de-registered from Libevent. When the token bucket gets refilled, it
will check the associated read/write_blocked_on_bandwidth flag, and
add the read/write event back to Libevent, which will cause it to
fire. This time, it will be properly flushed and closed.
The reason that both read and write events are both de-registered
when the marked connection can not flush is because both result in
the same behavior. Both read/write events on marked connections will
never again do any actual reads/writes, and are only useful to
trigger the flush and close the connection. By setting the
associated read/write_blocked_on_bandwidth flag, we ensure that the
event will get added back to Libevent, properly flushed, and closed.
Why is this important? Every Shadow event occurs at a discrete time
instant. If Tor does not properly deregister Libevent events that
fire but result in Tor essentially doing nothing, Libevent will
repeatedly fire the event. In Shadow this means infinite loop,
outside of Shadow this means wasted CPU cycles.
From what I can tell, this configuration is usually a mistake, and
leads people to think that all their traffic is getting proxied when
in fact practically none of it is. Resolves the issue behind "bug"
4663.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
This feature can make Tor relays less identifiable by their use of the
mod_ssl DH group, but at the cost of some usability (#4721) and bridge
tracing (#6087) regressions.
We should try to turn this on by default again if we find that the
mod_ssl group is uncommon and/or we move to a different DH group size
(see #6088). Before we can do so, we need a fix for bugs #6087 and
Resolves ticket #5598 for now.
These stats are currently discarded, but we might as well
hard-disable them on bridges, to be clean.
Fix for bug 5824; bugfix on 0.2.1.17-rc.
Patch originally by Karsten Loesing.
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
This code shouldn't have any effect in 0.2.3, since we already accept
(and handle) data received while we are expecting a renegotiation.
(That's because the 0.2.3.x handshake _does_ have data there instead of
the renegotiation.)
I'm leaving it in anyway, since if it breaks anything, we'll want it
broken in master too so we can find out about it. I added an XXX023
comment so that we can come back later and fix that.
This fixes a DoS issue where a client could send so much data in 5
minutes that they exhausted the server's RAM. Fix for bug 5934 and
6007. Bugfix on 0.2.0.20-rc, which enabled the v2 handshake.
This solves bug 5283, where client traffic could get sent over the
same circuit as an anonymized connection to a directory, even if
that circuit used an exit node unsuitable for clients. By marking
the directory connection as needs_internal, we ensure that the
(non-internal!) client-traffic connection won't be sent over the
same circuit.
On Windows, getsockname() on a nonblocking apparently won't work
until the connection is done connecting. On XP, it seems to fail by
reporting success and declaring that your address is INADDR_ANY. On the
Win8 preview, though, it fails more loudly and says WSAEINVAL.
Fix for bug 5374; bugfix on 0.1.1.14-alpha.
Roger explains at
http://archives.seul.org/tor/talk/Nov-2011/msg00209.html :
"If you list your bridge as part of your family in the relay
descriptor, then everybody can learn your bridge fingerprint, and
they can look up your bridge's descriptor (and thus location) at
the bridge directory authority."
Now, we can't stop relays from listing bridges, but we can warn when
we notice a bridge listing anybody, which might help some.
This fixes bug 4657; it's a fix on 0.2.0.3-alpha, where bridges were
first introduced.
To hit this leak, you need to be a relay that gets a RESOLVE request
or an exit node getting a BEGIN or RESOLVE request. You must either
have unconfigured (and unconfigurable) nameservers, or you must have
somehow set DisableNetwork after a network request arrived but
before you managed to process it.
So, I doubt this is reached often. Still, a leak's a leak. Fix for
bug 5916; bugfix on 0.2.3.9-alpha and 0.1.2.1-alpha.
%f is correct; %lf is only needed with scanf. Apparently, on some
old BSDs, %lf is deprecated.
Didn't we do this before? Yes, we did. But we only got the
instances of %lf, not more complicated things like %.5lf . This
patch tries to get everything.
Based on a patch for 3894 by grarpamp.
These errors usually mean address exhaustion; reporting them as such
lets clients adjust their load to try other exits.
Fix for bug 4710; bugfix on 0.1.0.1-rc, which started using
END_STREAM_REASON_RESOURCELIMIT.
Silences the log message:
[warn] {BUG} _connection_mark_unattached_ap(): Bug: stream (marked at connection_edge.c:2224) sending two socks replies?
after the client triggered the "Tor is not an HTTP Proxy" response.
No additional socks reply was sent, though.
Previously, we only did this check at startup, which could lead to
us holding a guard indefinitely, and give weird results. Fixes bug
5380; bugfix on 0.2.1.14-rc.
(Patch by Roger; changes file and commit message by Nick)
Previously, we skipped everything that got invoked from
options_init_from_torrc. But some of the stuff in
options_act_reversible and options_act is actually important, like
reopening the logs.
Now, a SIGHUP always makes the effects of an options_set() happen,
even though the options haven't changed.
Fix for bug 5095; bugfix on 0.2.1.9-alpha, which introduced
__ReloadTorrcOnSIGHUP.
This would happen if the deliver window could become negative
because of an nonexistent connection. (Fortunately, _that_ can't
occur, thanks to circuit_consider_sending_sendme. Still, if we
change our windowing logic at all, we won't want this to become
triggerable.) Fix for bug 5541. Bugfix on 4a66865d, back from
0.0.2pre14. asn found this. Nice catch, asn!
This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.
See bug #5861. We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.
MSVC warns if you declare a function as having a "int foo" argument
and then implement it with a "const int foo" argument, even though
the latter "const" is not a part of the function's interface.
Instead, allow packagers to put a 'TOR_BUILD_TAG' field in the
server descriptor to indicate a platform-specific value, if they
need to. (According to weasel, this was his use for the git- tag
previously.)
This is part of 2988
