| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Also fix test case to expect 1 on successfully spawning a subprocess
|
| |
| |
| |
| |
| |
| | |
- 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
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This is a tweak for the tor-fw-helper port to windows.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Update configure script to test for libminiupnpc along with the
libws2_32 and libiphlpapi libraries required by libminiupnpc
- When building tor-fw-helper, link in libiphlpapi
- Link in libminiupnpc statically becasue I could not get the DLL
to link properly
- Call WSAStartup before doing network operations
- Fix up a compiler warning about uninitialized backend_state
N.B. The changes to configure.in and Makefile.am will break on non-
Windows platforms.
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
lround() is missing in MS Visual-C's <math.h>. Not available anywhere.
Here is an easy patch.
|
| |_|_|/
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| |_|/
|/| | |
|
| | | |
|
| | | |
|