| Age | Commit message (Collapse) | Author |
|---|
|
After a stream reached eof, we fclose it, but then
test_util_spawn_background_partial_read() reads from it again, which causes
an error and thus another fclose(). Some platforms are fine with this, others
(e.g. debian-sid-i386) trigger a double-free() error. The actual code used by
Tor (log_from_pipe() and tor_check_port_forwarding()) handle this case
correctly.
|
|
|
|
Mainly used for testing reading from subprocesses. To be more generic
we now pass in a pointer to a process_handle_t rather than a Windows-
specific HANDLE.
|
|
|
|
|
|
|
|
|
|
Now handles non-printable characters and will not output a spurious
new-line if given a partial line.
|
|
Now correctly handles whitespace, quotes and backslashes. Passes all unit tests.
|
|
|
|
- process_handle_t.status
- return value of tor_get_exit_code()
|
|
Conventionally in Tor, structs are returned as pointers, so change
tor_spawn_background() to return the process handle in a pointer rather
than as return value.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
lround() is missing in MS Visual-C's <math.h>. Not available anywhere.
Here is an easy patch.
|
|
|
|
- Better error handling
- Write description of functions
- Don't assume non-negative process return values
|
|
|
|
Conflicts:
configure.in
src/tools/tor-fw-helper/Makefile.am
src/tools/tor-fw-helper/tor-fw-helper-upnp.c
src/tools/tor-fw-helper/tor-fw-helper.c
|
|
|
|
|
|
|
|
|
|
ddc65e2b3303559ab7b842a176ee6c2eda9e4027 had broken this
|
|
Also remove a few other related warnings that could occur during the ssl
handshake. We do this because the relay operator can't do anything about
them, and they aren't their fault.
|
|
|
|
I should have added this before implementing #2411.
|
|
|
|
this gets rid of a warning about signed/unsigned comparison
|
|
We'll still need to tweak it so that it looks for includes and
libraries somewhere more sensible than "where we happened to find
them on Erinn's system"; so that tests and tools get built too;
so that it's a bit documented; and so that we actually try running
the output.
Work done with Erinn Clark.
|
|
|
|
|
|
|
|
|
|
See http://stackoverflow.com/questions/3722409/windows-child-process-with-redirected-input-and-output
for a potential solution
|
|
|
|
- pid, stdout/stderr_pipe now encapsulated in process_handle
- read_all replaced by tor_read_all_from_process_stdin/stderr
- waitpid replaced by tor_get_exit_code
Untested on *nix
|
|
|
|
Previously, if tor_addr_to_str() returned NULL, we would reuse the
last value returned by fmt_addr(). (This could happen if we were
erroneously asked to format an AF_UNSPEC address.) Now instead we
return "???".
|
|
|
|
This is the meat of proposal 171: we change circuit_is_acceptable()
to require that the connection is compatible with every connection
that has been linked to the circuit; we update circuit_is_better to
prefer attaching streams to circuits in the way that decreases the
circuits' usefulness the least; and we update link_apconn_to_circ()
to do the appropriate bookkeeping.
|
|
Requested by Gisle Vanem on tor-dev. I'm not quite sure this is the
right solution, but it's probably harmless.
|
|
- We were reporting the _bottom_ N failing states, not the top N.
- With bufferevents enabled, we logged all TLS states as being "in
bufferevent", which isn't actually informative.
- When we had nothing to report, we reported nothing too loudly.
- Also, we needed documentation.
|
|
This code lets us record the state of any outgoing OR connection
that fails before it becomes open, so we can notice if they're all
dying in the same SSL state or the same OR handshake state.
More work is still needed:
- We need documentation
- We need to actually call the code that reports the failure when
we realize that we're having a hard time connecting out or
making circuits.
- We need to periodically clear out all this data -- perhaps,
whenever we build a circuit successfully?
- We'll eventually want to expose it to controllers, perhaps.
Partial implementation of feature 3116.
|
|
|
|
|
