| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ERR is if something fatal just happened
WARNING is something bad happened, but we're still running. The bad thing
is either a bug in the code, an attack or buggy protocol/implementation
of the remote peer, etc. The operator should examine the bad thing and
try to correct it.
(No error or warning messages should be expected. I expect most people
to run on -l warning eventually.)
NOTICE is never ever used.
INFO means something happened (maybe bad, maybe ok), but there's nothing
you need to (or can) do about it.
DEBUG is for everything louder than INFO.
svn:r486
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'buf_t' is now an opaque type defined in buffers.c .
Router descriptors now include all keys; routers generate keys as
needed on startup (in a newly defined "data directory"), and generate
their own descriptors. Descriptors are now self-signed.
Implementation is not complete: descriptors are never published; and
upon receiving a descriptor, the directory doesn't do anything with
it.
At least "routers.or" and orkeygen are now obsolete, BTW.
svn:r483
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed up the assert_*_ok funcs some (more work remains)
Changed config so it reads either /etc/torrc or the -f arg, never both
Finally tracked down a nasty bug with our use of tls:
It turns out that if you ask SSL_read() for no more than n bytes, it
will read the entire record from the network (and maybe part of the next
record, I'm not sure), give you n bytes of it, and keep the remaining
bytes internally. This is fine, except our poll-for-read looks at the
network, and there are no bytes pending on the network, so we never know
to ask SSL_read() for more bytes. Currently I've hacked it so if we ask
for n bytes and it returns n bytes, then it reads again right then. This
will interact poorly with our rate limiting; we need a cleaner solution.
svn:r481
|
| |
|
|
|
|
|
|
|
|
|
| |
this paves the way for supporting socks5 and other handshakes
it also removes those pesky AP-only variables from connection_t
also hacked a fix for a bug where some streams weren't ending properly --
maybe because marked connections weren't flushing properly?
svn:r472
|
| |
|
|
| |
svn:r468
|
| |
|
|
| |
svn:r466
|
| |
|
|
| |
svn:r464
|
| |
|
|
| |
svn:r462
|
| |
|
|
| |
svn:r461
|
| |
|
|
|
|
|
| |
and fixed recent memory leak
svn:r456
|
| |
|
|
| |
svn:r415
|
| |
|
|
| |
svn:r375
|
| |
|
|
| |
svn:r374
|
| |
|
|
| |
svn:r371
|
| |
|
|
| |
svn:r363
|
| |
|
|
| |
svn:r349
|
| |
|
|
| |
svn:r340
|
| |
|
|
| |
svn:r333
|
| |
|
|
|
|
|
|
|
|
|
| |
they used to be used for
* queueing relay cells at the edge of the network, when windows are empty
* queueing relay cells that arrive after an onion but before the onion
has been processed.
both of these uses are gone. so out they go.
svn:r315
|
| |
|
|
|
|
|
| |
clean up circuit_deliver_relay_cell convention
svn:r312
|
| |
|
|
| |
svn:r303
|
| |
|
|
| |
svn:r298
|
| |
|
|
| |
svn:r297
|
| |
|
|
|
|
|
| |
point to the streams for this circ.
svn:r296
|
| |
|
|
|
|
|
|
|
|
| |
circuits no longer queue more cells when the windows are empty --
they simply don't package it from the buffer if they're not going to want it.
we can restore this code later if we need to resume queueing.
svn:r294
|
| |
|
|
|
|
|
|
|
|
| |
remove sendme cells
replace malloc with tor_malloc
patch (but not track down) bug in onion pending list
streamline connection_ap handshake
svn:r293
|
| |
|
|
| |
svn:r265
|
| |
|
|
|
|
|
| |
still need to change circuit-level sendmes
svn:r264
|
| |
|
|
|
|
|
|
| |
the OP only crypts the appropriate number of times depending on which
layer (hop on the path) it's for/from.
svn:r262
|
| |
|
|
| |
svn:r260
|
| |
|
|
| |
svn:r258
|
| |
|
|
| |
svn:r255
|
| |
|
|
|
|
|
| |
this way we can always check if a new circ needs to be launched
svn:r254
|
| |
|
|
| |
svn:r251
|
| |
|
|
| |
svn:r249
|
| |
|
|
| |
svn:r241
|
| |
|
|
|
|
| |
an onion on the network
svn:r239
|
| |
|
|
| |
svn:r237
|
| |
|
|
| |
svn:r236
|
| |
|
|
|
|
|
|
| |
now we rebuild the circuit periodically (but only if it's been used),
and we can further abstract it to do incremental circuit building, etc.
svn:r233
|
| |
|
|
| |
svn:r230
|
| |
|
|
|
|
| |
separate file.
svn:r224
|
| |
|
|
| |
svn:r176
|
| |
|
|
| |
svn:r172
|
| |
|
|
| |
svn:r166
|
| |
|
|
| |
svn:r161
|
| |
|
|
|
|
|
|
|
| |
(they wouldn't have before)
alternate code which bypasses the dns farm, so we can compare speed
svn:r154
|
| |
|
|
|
|
|
| |
performance is better, but not by much. not sure why yet.
svn:r153
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on startup, it forks off a master dns handler, which forks off dns
slaves (like the apache model). slaves as spawned as load increases,
and then reused. excess slaves are not ever killed, currently.
implemented topics. each topic has a receive window in each direction
at each edge of the circuit, and sends sendme's at the data level, as
per before. each circuit also has receive windows in each direction at
each hop; an edge sends a circuit-level sendme as soon as enough data
cells have arrived (regardless of whether the data cells were flushed
to the exit conns). removed the 'connected' cell type, since it's now
a topic command within data cells.
at the edge of the circuit, there can be multiple connections associated
with a single circuit. you find them via the linked list conn->next_topic.
currently each new ap connection starts its own circuit, so we ought
to see comparable performance to what we had before. but that's only
because i haven't written the code to reattach to old circuits. please
try to break it as-is, and then i'll make it reuse the same circuit and
we'll try to break that.
svn:r152
|
| |
|
|
| |
svn:r149
|