| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
svn:r5459
|
|
|
|
| |
svn:r5458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
separately. It's important to keep them separate because internal
circuits have their last hops picked like middle hops, rather than like
exit hops. So exiting on them will break the user's expectations.
- Stop cannibalizing internal circuits for general exits, and stop
cannibalizing exit circuits for rendezvous stuff.
- Don't let new exit streams attach to internal circuits.
- When deciding if we have enough circuits for internal and for exit,
don't count the wrong ones.
- Treat predicted resolves as predicted port 80 exits.
svn:r5457
|
|
|
|
|
|
|
| |
for non-OR conns. this should save a bit of time.
svn:r5456
|
|
|
|
|
|
|
|
| |
This is not a real fix. I didn't look at the rest of the code.
Nick?
svn:r5455
|
|
|
|
| |
svn:r5454
|
|
|
|
|
|
|
|
|
| |
(intended to be cannibalized later for rendezvous and introduction
circuits), we were picking them so that they had useful exit nodes. There
was no need for this, and it actually aids some statistical attacks.
svn:r5453
|
|
|
|
| |
svn:r5452
|
|
|
|
| |
svn:r5451
|
|
|
|
| |
svn:r5448
|
|
|
|
| |
svn:r5447
|
|
|
|
| |
svn:r5446
|
|
|
|
|
|
| |
Track bytes dropped that are still in our store or journal, and rebuild when it gets very high.
svn:r5445
|
|
|
|
| |
svn:r5444
|
|
|
|
| |
svn:r5443
|
|
|
|
|
|
| |
tracking this right. Somebody should valgrind a dirserver on an example net. There should be code to dump this value.
svn:r5442
|
|
|
|
|
|
| |
significantly faster.
svn:r5441
|
|
|
|
| |
svn:r5439
|
|
|
|
| |
svn:r5438
|
|
|
|
|
|
| |
block
svn:r5437
|
|
|
|
|
|
|
|
| |
server descriptors that were uploaded to a router in its role as authoritative
dirserver.
svn:r5436
|
|
|
|
| |
svn:r5434
|
|
|
|
| |
svn:r5433
|
|
|
|
| |
svn:r5432
|
|
|
|
|
|
|
|
|
|
|
|
| |
- If we can't get to a dirserver directly, try going via Tor.
- Don't ever try to connect (as a client) to a place our firewall
options forbid.
- If we specify a proxy and also firewall options, obey the firewall
options even when we're using the proxy: some proxies can only proxy
to certain destinations.
svn:r5431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
don't tell you (it happens!); and rotate TLS connections once a week.
1) If an OR conn becomes more than a week old, make it obsolete.
2) If it's obsolete and empty, kill it.
3) When an OR makes a second connection to you, allow it.
4) If we want to send a new create cell, but the best conn we've
got is obsolete, and the router is 0.1.1.9-alpha-cvs or later, ask
for a new conn instead.
5) When we time out on circuit building on the first hop, make that
connection obsolete.
svn:r5429
|
|
|
|
| |
svn:r5428
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first few moments of their existence in CIRCUIT_STATE_OPEN, then
when Alice sent an extend request for a Tor that they're not connected
to, they switched to CIRCUIT_STATE_OR_WAIT and spent the rest of
their sorry little lives in that state, even when the connection
was established and they were shuttling relay cells back and forth.
And I'm not going to backport this (yet), because somehow it worked!
svn:r5427
|
|
|
|
| |
svn:r5426
|
|
|
|
| |
svn:r5425
|
|
|
|
| |
svn:r5424
|
|
|
|
|
|
| |
do not think it works quite right.
svn:r5423
|
|
|
|
| |
svn:r5422
|
|
|
|
| |
svn:r5421
|
|
|
|
|
|
|
|
|
|
| |
just add the default ones directly to the trusted dirserver list.
This fixes a bug where people running controllers would setconf or
the equivalent, and Tor would start yelling at them about setting
their own DirServer lines.
svn:r5418
|
|
|
|
| |
svn:r5417
|
|
|
|
| |
svn:r5416
|
|
|
|
| |
svn:r5415
|
|
|
|
| |
svn:r5414
|
|
|
|
|
|
|
|
|
|
|
|
| |
any answer at all. this is clearly a bug.
the more interesting bug is whether things like setconf, getconf,
and so on should return 250 OK if you give them no arguments. should
we have a new "you didn't ask me anything" response code, or just
leave it as is?
svn:r5412
|
|
|
|
|
|
|
|
|
| |
don't recognize. now we just drop it. perhaps this will make us
more forward-compatible? or perhaps it will bite us? one day we
will find out.
svn:r5405
|
|
|
|
| |
svn:r5403
|
|
|
|
| |
svn:r5400
|
|
|
|
|
|
|
|
|
| |
applications are using socks4, socks4a, socks5-with-ip, or
socks5-with-hostname. This way they don't have to keep mucking
with tcpdump and wondering if something got cached somewhere.
svn:r5399
|
|
|
|
| |
svn:r5398
|
|
|
|
|
|
| |
but others might.)
svn:r5389
|
|
|
|
|
|
|
| |
hear about lexi's bugs.
svn:r5388
|
|
|
|
| |
svn:r5387
|
|
|
|
| |
svn:r5378
|
|
|
|
| |
svn:r5377
|