Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:06:16Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1899We should launch a reachability test immediately if a router changes IP or port2020-06-13T14:06:16ZNick MathewsonWe should launch a reachability test immediately if a router changes IP or portWhen reviewing my patch for bug #911, Sebastian noted:
> in dirserv_should_launch_reachability_test() shouldn't we test for difference in port or ip, and do the test immediately?
This is indeed so. We should do this once #911 is merge...When reviewing my patch for bug #911, Sebastian noted:
> in dirserv_should_launch_reachability_test() shouldn't we test for difference in port or ip, and do the test immediately?
This is indeed so. We should do this once #911 is merged.
Marking for 0.2.2.x-final, since it's trivial.Tor: 0.2.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/1882"Failed to find node for hop 0 of our path. Discarding this circuit." log spa...2020-06-13T14:06:09ZSebastian Hahn"Failed to find node for hop 0 of our path. Discarding this circuit." log spam after guard went downI noticed this issue with my torperf setup. A tor client that is started with a single node allowed as entry node will freak out if that entry guard goes offline, however briefly.
It keeps logging "Failed to find node for hop 0 of our p...I noticed this issue with my torperf setup. A tor client that is started with a single node allowed as entry node will freak out if that entry guard goes offline, however briefly.
It keeps logging "Failed to find node for hop 0 of our path. Discarding this circuit." repeatedly, and doesn't seem to recover well at all. I wonder if that means that we are also willing to give up on guards in a regular setup as soon as they go down once, and stop using them.
This might be related to issue #675Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1868Assertion n_to_skip + n_to_free == freelists[i].cur_length failed2020-06-13T14:06:08ZTracAssertion n_to_skip + n_to_free == freelists[i].cur_length failedAug 26 03:26:49.050 [Info] directory_send_command(): Downloading consensus from XXX.XXX.XXX.XXX:443 using /tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z
Aug 26 03:26:49.050 [Info] run_connect...Aug 26 03:26:49.050 [Info] directory_send_command(): Downloading consensus from XXX.XXX.XXX.XXX:443 using /tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z
Aug 26 03:26:49.050 [Info] run_connection_housekeeping(): Expiring non-used OR connection to fd 1048 (XXX.XXX.XXX.XXX:4160) [idle 622].
Aug 26 03:26:49.050 [Info] buf_shrink_freelists(): Cleaning freelist for 4096-byte chunks: length 9, keeping 8, dropping 1.
Aug 26 03:26:49.050 [Error] buf_shrink_freelists(): Bug: buffers.c:281: buf_shrink_freelists: Assertion n_to_skip + n_to_free == freelists[i].cur_length failed; aborting.
Win7x64 Limited Account, vidalia x15 alpha (tor error)
If someone can remind me where the dumps in Windows are thrown I can fetch that also.
**Trac**:
**Username**: funkstarTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1863Relays should store observed bandwidth in state file2020-06-13T14:10:02ZMike PerryRelays should store observed bandwidth in state filearma suggested I write a proposal for this, but I believe it is a flat out bug. When a relay goes down, it looses its 24 hour observed bandwidth window. For fast relays, this can be catastropic, as it takes weeks for them to regain their...arma suggested I write a proposal for this, but I believe it is a flat out bug. When a relay goes down, it looses its 24 hour observed bandwidth window. For fast relays, this can be catastropic, as it takes weeks for them to regain their bandwidth due to our slow descriptor refresh interval. The slow descriptor refresh interval can be shortened, but that requires careful study to make sure we do not increase the descriptor load on clients.
If we just instead stored this info in the state file to survive crashes, high bandwidth relays would still spend a *loooong* time gathering bandwidth (and maybe this is a really good thing?), but will at least not have to restart when they die.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1848many "warning: 'struct in_addr' declared inside parameter list" when compiled...2020-06-13T14:05:59ZTracmany "warning: 'struct in_addr' declared inside parameter list" when compiled on OpenBSD 4.8I see many "warning: 'struct in_addr' declared inside parameter list" when I compile Tor-0.2.2.15-alpha on OpenBSD 4.8 (that's -current at the moment). The binary that I get seems to work fine though. For comparision, I don't see these w...I see many "warning: 'struct in_addr' declared inside parameter list" when I compile Tor-0.2.2.15-alpha on OpenBSD 4.8 (that's -current at the moment). The binary that I get seems to work fine though. For comparision, I don't see these warnings on FreeBSD 8.1.
all output: http://pastebin.org/646438
and a part of the output:
[...]
Making all in or
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT buffers.o -MD -MP -MF .deps/buffers.Tpo -c -o buffers.o buffers.c
In file included from or.h:63,
from buffers.c:14:
/usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list
/usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list
mv -f .deps/buffers.Tpo .deps/buffers.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT circuitbuild.o -MD -MP -MF .deps/circuitbuild.Tpo -c -o circuitbuild.o circuitbuild.c
In file included from or.h:63,
from circuitbuild.c:14:
/usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list
/usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list
mv -f .deps/circuitbuild.Tpo .deps/circuitbuild.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT circuitlist.o -MD -MP -MF .deps/circuitlist.Tpo -c -o circuitlist.o circuitlist.c
In file included from or.h:63,
from circuitlist.c:12:
/usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list
/usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list
mv -f .deps/circuitlist.Tpo .deps/circuitlist.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT circuituse.o -MD -MP -MF .deps/circuituse.Tpo -c -o circuituse.o circuituse.c
In file included from or.h:63,
from circuituse.c:12:
/usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list
/usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list
mv -f .deps/circuituse.Tpo .deps/circuituse.Po
[...]
**Trac**:
**Username**: TasTor: 0.2.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/1840run_connection_housekeeping() closes circuits early2020-06-13T14:05:58ZRoger Dingledinerun_connection_housekeeping() closes circuits earlyDue perhaps to bug #1772, my circuitbuildtimeout is growing very big:
Aug 17 14:59:00.189 [notice] Based on 1000 circuit times, it looks like we need to wait longer for circuits to finish. We will now assume a circuit is too slow to use...Due perhaps to bug #1772, my circuitbuildtimeout is growing very big:
Aug 17 14:59:00.189 [notice] Based on 1000 circuit times, it looks like we need to wait longer for circuits to finish. We will now assume a circuit is too slow to use after waiting 255 seconds.
And once it's this big, run_connection_housekeeping() starts killing OR connections that haven't finished handshaking yet:
Aug 17 15:06:03.012 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 18 (38.229.70.33:9001) [idle 180].
Aug 17 15:06:03.012 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 11 (85.25.130.135:443) [idle 180].
Aug 17 15:06:03.012 [debug] conn_close_if_marked(): Cleaning up connection (fd 18).
Aug 17 15:06:03.012 [debug] circuit_n_conn_done(): or_conn to FordModelA/38.229.70.33, status=0
Aug 17 15:06:03.012 [info] circuit_n_conn_done(): or_conn failed. Closing circ.
Aug 17 15:06:03.012 [info] circuit_build_failed(): Our circuit died before the first hop with no connection
Aug 17 15:06:03.013 [debug] circuit_increment_failure_count(): n_circuit_failures now 1.
Aug 17 15:06:03.013 [debug] connection_remove(): removing socket 18 (type OR), n_conns now 20
Aug 17 15:06:03.013 [debug] _connection_free(): closing fd 18.
Aug 17 15:06:03.013 [debug] conn_close_if_marked(): Cleaning up connection (fd 11).
Aug 17 15:06:03.013 [debug] connection_remove(): removing socket 11 (type OR), n_conns now 19
Aug 17 15:06:03.013 [debug] _connection_free(): closing fd 11.
So the first issue is: why the heck is my network taking >180 seconds to TLS handshake with this relay? Probably something about my network stability, plus the results of bug #1772.
The second question is: why are we culling the OR connection when there's a circuit that isn't connected yet but wants to be? That sounds like a check we forgot to add (that didn't matter when the timeout was 15 minutes, but now matters when the timeout is 3 minutes).Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1832Fix compiling Tor with --with-dmalloc2020-06-13T14:05:57ZKarsten LoesingFix compiling Tor with --with-dmallocTor doesn't compile with ./configure --with-dmalloc set. It does compile with the following patch, but I'm not sure if that's the fix we want:
```
diff --git a/src/or/microdesc.c b/src/or/microdesc.c
index f56ccd9..e8f3e7c 100644
--- a/...Tor doesn't compile with ./configure --with-dmalloc set. It does compile with the following patch, but I'm not sure if that's the fix we want:
```
diff --git a/src/or/microdesc.c b/src/or/microdesc.c
index f56ccd9..e8f3e7c 100644
--- a/src/or/microdesc.c
+++ b/src/or/microdesc.c
@@ -53,7 +53,7 @@ HT_PROTOTYPE(microdesc_map, microdesc_t, node,
_microdesc_hash, _microdesc_eq);
HT_GENERATE(microdesc_map, microdesc_t, node,
_microdesc_hash, _microdesc_eq, 0.6,
- _tor_malloc, _tor_realloc, _tor_free);
+ malloc, realloc, free);
/** Write the body of <b>md</b> into <b>f</b>, with appropriate annotations.
* On success, return the total number of bytes written, and set
diff --git a/src/test/test.c b/src/test/test.c
index ff166ce..0cad8fc 100644
--- a/src/test/test.c
+++ b/src/test/test.c
@@ -61,6 +61,7 @@ double fabs(double x);
#ifdef USE_DMALLOC
#include <dmalloc.h>
#include <openssl/crypto.h>
+#include "main.h"
#endif
/** Set to true if any unit test has failed. Mostly, this is set by the macros
```Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1831Fix memory leaks introduced between 0.2.2.13 and 0.2.2.142020-06-13T14:05:56ZSebastian HahnFix memory leaks introduced between 0.2.2.13 and 0.2.2.14Weasel noticed that tor26 appears to be very quickly leaking excessive amounts of memory. Listing the problems we found here in this report.Weasel noticed that tor26 appears to be very quickly leaking excessive amounts of memory. Listing the problems we found here in this report.Tor: 0.2.2.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/1810published new server descriptor but authorities dropped because cosmetic2020-06-13T14:10:49ZTracpublished new server descriptor but authorities dropped because cosmeticyesterday my exit node was running but not relaying. no data in and out but huge jump in incoming connections.
i restarted Tor as suggested in irc chat and that normalize everything but today repeated the problem but with a difference.
y...yesterday my exit node was running but not relaying. no data in and out but huge jump in incoming connections.
i restarted Tor as suggested in irc chat and that normalize everything but today repeated the problem but with a difference.
yesterday - connections established but not relaying
today - connections established and relaying.
but both occurrences drop from the consensus.
lot49
**Trac**:
**Username**: TrysteroTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1805Frequently repeated [Warning] Weighted bandwidth is 0.000000 ... when using b...2020-06-13T14:05:48ZAndrew LewmanFrequently repeated [Warning] Weighted bandwidth is 0.000000 ... when using bridgesWhen using bridges, the following log message repeats every few seconds:
`[Warning] Weighted bandwidth is 0.000000 in node selection for rule weight as guard`
I have two bridges configured, both are online and available. Other than th...When using bridges, the following log message repeats every few seconds:
`[Warning] Weighted bandwidth is 0.000000 in node selection for rule weight as guard`
I have two bridges configured, both are online and available. Other than the bridges, this is a default install of the vidalia bundle for ubuntu 10.04 running tor 0.2.2.14-alpha.Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1797Restore support for building Tor in non-Unicode Windows installations2020-06-13T14:05:46ZNick MathewsonRestore support for building Tor in non-Unicode Windows installationsWhen we merged WinCE support in 8d31141ccbdbeee9589d04ea99819af7aa35193b, we reportedly broke Win98 (!?) by requiring the Unicode versions of functions that previously had used the ascii variants.
The real fix here is to use the [generi...When we merged WinCE support in 8d31141ccbdbeee9589d04ea99819af7aa35193b, we reportedly broke Win98 (!?) by requiring the Unicode versions of functions that previously had used the ascii variants.
The real fix here is to use the [generic version](http://msdn.microsoft.com/en-us/library/dd317766(v=VS.85).aspx) of each WinAPI function, plus appropriate macros to make it build either with the UNICODE preprocessor macro defined or undefined.
In other words, where previously we said in our Windows code
```
void func(const char *filename) {
HANDLE library = LoadLibrary("filename.dll");
CreateFile(filename, ...)
}
```
and now since 8d31141 we say
```
void func(const char *filename) {
HANDLE library = LoadLibraryW(L"filename.dll");
WCHAR wfilename[MAX_PATH]= {0};
mbstowcs(wfilename,filename,MAX_PATH);
CreateFileW(wfilename, ...)
}
```
we should instead say
```
void func(const char *filename) {
HANDLE library = LoadLibrary(TEXT("filename.dll"));
#ifdef UNICODE
WCHAR tfilename[MAX_PATH]= {0};
mbstowcs(tfilename,filename,MAX_PATH);
#else
const char *tfilename = filename;
#endif
CreateFile(tfilename, ...)
}
```
Thanks to mingw-san for pointing this out on bug #1715.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1789Wake-up from Hibernation Occurs Day 1 Each Month2020-06-13T14:05:41ZTracWake-up from Hibernation Occurs Day 1 Each MonthThis is happening on several relays, on both 64-bit and 32-bit CentOS Linux.
Apr 18 12:48:15.014 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate f...This is happening on several relays, on both 64-bit and 32-bit CentOS Linux.
Apr 18 12:48:15.014 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Apr 18 13:04:04.244 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Apr 19 00:00:00.995 [notice] Configured hibernation. This interval began at 2010-04-19 00:00:00; the scheduled wake-up time was 2010-04-19 00:00:00; we expect to exhaust our quota for this interval around 2010-04-20 00:00:00; the next interval begins at 2010-04-20 00:00:00 (all times local)
Apr 19 10:55:19.797 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 21 01:39:36.221 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 22 21:11:26.494 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 24 22:00:39.128 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 25 01:37:16.835 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-03 20:22:28; we expect to exhaust our quota for this interval around 2010-04-27 11:45:28; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 27 09:33:10.377 [notice] Bandwidth soft limit reached; commencing hibernation.
May 01 00:00:00.636 [notice] Configured hibernation. This interval began at 2010-05-01 00:00:00; the scheduled wake-up time is 2010-05-06 15:25:09; we expect to exhaust our quota for this interval around 2010-05-18 16:29:09; the next interval begins at 2010-06-01 00:00:00 (all times local)
May 01 00:00:00.667 [notice] Accounting period ended. Commencing hibernation until 2010-05-06 15:25:09 GMT
May 02 19:38:30.791 [notice] Configured hibernation. This interval began at 2010-05-01 00:00:00; the scheduled wake-up time is 2010-05-06 15:25:09; we expect to exhaust our quota for this interval around 2010-05-18 16:29:09; the next interval begins at 2010-06-01 00:00:00 (all times local)
May 02 19:38:31.263 [notice] Commencing hibernation. We will wake up at 2010-05-06 15:25:09 local time.
May 06 15:25:09.423 [notice] Hibernation period ended. Resuming normal activity.
May 08 22:06:49.155 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 01 00:00:00.981 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 01 00:00:01.052 [notice] Hibernation period ended. Resuming normal activity.
Jun 02 10:59:45.826 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 05 07:24:03.517 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 07 00:39:45.337 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 07 00:39:46.019 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 20 17:38:44.317 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 20 17:38:47.640 [notice] Bandwidth soft limit reached; commencing hibernation.
Jul 01 00:00:00.388 [notice] Configured hibernation. This interval began at 2010-07-01 00:00:00; the scheduled wake-up time is 2010-07-01 04:07:55; we expect to exhaust our quota for this interval around 2010-07-31 22:47:55; the next interval begins at 2010-08-01 00:00:00 (all times local)
Jul 01 00:00:00.528 [notice] Accounting period ended. Commencing hibernation until 2010-07-01 04:07:55 GMT
Jul 01 04:07:55.607 [notice] Hibernation period ended. Resuming normal activity.
Jul 08 07:12:20.943 [notice] Bandwidth soft limit reached; commencing hibernation.
Jul 15 00:12:31.450 [notice] Configured hibernation. This interval began at 2010-07-01 00:00:00; the scheduled wake-up time was 2010-07-01 04:07:55; we expect to exhaust our quota for this interval around 2010-07-31 22:47:55; the next interval begins at 2010-08-01 00:00:00 (all times local)
Jul 15 00:12:32.688 [notice] Bandwidth soft limit reached; commencing hibernation.
Aug 01 00:00:00.152 [notice] Configured hibernation. This interval began at 2010-08-01 00:00:00; the scheduled wake-up time was 2010-08-01 00:00:00; we expect to exhaust our quota for this interval around 2010-09-01 00:00:00; the next interval begins at 2010-09-01 00:00:00 (all times local)
Aug 01 00:00:00.184 [notice] Hibernation period ended. Resuming normal activity.
**Trac**:
**Username**: BarkerJrTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1772Counting circuit timeouts when we can't establish any TLS connection2020-06-13T14:05:31ZRoger DingledineCounting circuit timeouts when we can't establish any TLS connectionRunning 856a36c43439da as a client
When my laptop loses its internet connection, I get this in my log:
Jul 28 22:43:09.572 [info] connection_ap_make_link(): Making internal direct tunnel to 85.17.59.169:19090 ...
Jul 28 22:43:09.572 [...Running 856a36c43439da as a client
When my laptop loses its internet connection, I get this in my log:
Jul 28 22:43:09.572 [info] connection_ap_make_link(): Making internal direct tunnel to 85.17.59.169:19090 ...
Jul 28 22:43:09.572 [debug] onion_pick_cpath_exit(): Launching a one-hop circuit for dir tunnel.
Jul 28 22:43:09.572 [info] onion_pick_cpath_exit(): Using requested exit node 'privacyvpndotnet01'
Jul 28 22:43:09.572 [debug] onion_extend_cpath(): Path is 0 long; we want 1
Jul 28 22:43:09.572 [debug] onion_extend_cpath(): Chose router privacyvpndotnet01 for hop 1 (exit is privacyvpndotnet01)
Jul 28 22:43:09.572 [debug] onion_extend_cpath(): Path is complete: 1 steps long
Jul 28 22:43:09.572 [debug] circuit_handle_first_hop(): Looking for firsthop '85.17.59.169:19090'
Jul 28 22:43:09.572 [info] circuit_handle_first_hop(): Next router is privacyvpndotnet01: Not connected. Connecting.
Jul 28 22:43:09.572 [debug] connection_connect(): Connecting to "85.17.59.169":19090.
Jul 28 22:43:09.572 [debug] connection_connect(): Connection to "85.17.59.169":19090 in progress (sock 13).
Jul 28 22:43:09.572 [debug] connection_add(): new conn type OR, socket 13, address 85.17.59.169, n_conns 16.
Jul 28 22:43:20.316 [debug] connection_or_finished_connecting(): OR connect() to router at 85.17.59.169:19090 finished.
Jul 28 22:43:20.316 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 13
Jul 28 22:43:41.629 [debug] onion_pick_cpath_exit(): Launching a one-hop circuit for dir tunnel.
Jul 28 22:43:41.629 [info] onion_pick_cpath_exit(): Using requested exit node 'privacyvpndotnet01'
Jul 28 22:43:41.630 [debug] onion_extend_cpath(): Path is 0 long; we want 1
Jul 28 22:43:41.630 [debug] onion_extend_cpath(): Chose router privacyvpndotnet01 for hop 1 (exit is privacyvpndotnet01)
Jul 28 22:43:41.630 [debug] onion_extend_cpath(): Path is complete: 1 steps long
Jul 28 22:43:41.630 [debug] circuit_handle_first_hop(): Looking for firsthop '85.17.59.169:19090'
Jul 28 22:43:41.630 [info] circuit_handle_first_hop(): Next router is privacyvpndotnet01: Connection in progress; waiting.
Jul 28 22:43:41.630 [debug] circuit_handle_first_hop(): connecting in progress (or finished). Good.
Jul 28 22:43:41.630 [debug] conn_write_callback(): socket 17 wants to write.
Jul 28 22:43:42.633 [debug] circuit_build_times_add_time(): Adding circuit build time 2147483646
Jul 28 22:43:42.635 [info] circuit_build_times_get_xm(): Xm mode #0: 925 23
Jul 28 22:43:42.635 [info] circuit_build_times_get_xm(): Xm mode #1: 1425 15
Jul 28 22:43:42.635 [info] circuit_build_times_get_xm(): Xm mode #2: 1025 13
Jul 28 22:43:42.635 [notice] Based on 1000 circuit times, it looks like we need to wait longer for circuits to finish. We will now assume a circuit is too slow to use after waiting 64 seconds.
Jul 28 22:43:42.635 [info] circuit_build_times_set_timeout(): Circuit timeout data: 64381.435070ms, 2148375.414446ms, Xm: 1097, a: 0.395221, r: 0.164000
Jul 28 22:43:42.636 [info] circuit_expire_building(): Abandoning circ 0 (state 2:connecting to server, purpose 13)
Jul 28 22:43:42.636 [info] exit circ (length 1, exit privacyvpndotnet01): $58F9C92572EA8BF85F38C87467CA1542AD8D6F65(closed)
Jul 28 22:43:42.636 [info] circuit_build_failed(): Our circuit died before the first hop with no connection
Jul 28 22:43:42.636 [info] connection_ap_fail_onehop(): Closing one-hop stream to '$58F9C92572EA8BF85F38C87467CA1542AD8D6F65/85.17.59.169' because the OR conn just failed.
Jul 28 22:43:42.641 [info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
Jul 28 22:43:42.642 [debug] conn_close_if_marked(): Cleaning up connection (fd -1).
Jul 28 22:43:42.642 [info] connection_dir_request_failed(): Giving up on directory server at '85.17.59.169'; retrying
Jul 28 22:43:56.474 [debug] connection_tls_finish_handshake(): tls handshake with 85.17.59.169 done. verifying.
Jul 28 22:43:56.475 [debug] connection_or_check_valid_tls_handshake(): The certificate seems to be valid on outgoing connection with 85.17.59.169:19090
Jul 28 22:44:14.749 [debug] circuit_build_times_add_time(): Adding circuit build time 2147483646
Jul 28 22:44:14.751 [info] circuit_build_times_get_xm(): Xm mode #0: 925 23
Jul 28 22:44:14.751 [info] circuit_build_times_get_xm(): Xm mode #1: 1425 15
Jul 28 22:44:14.751 [info] circuit_build_times_get_xm(): Xm mode #2: 1025 13
Jul 28 22:44:14.751 [notice] Based on 1000 circuit times, it looks like we need to wait longer for circuits to finish. We will now assume a circuit is too slow to use after waiting 66 seconds.
Jul 28 22:44:14.751 [info] circuit_build_times_set_timeout(): Circuit timeout data: 65576.560832ms, 2223200.500411ms, Xm: 1097, a: 0.393444, r: 0.165000
Jul 28 22:44:14.751 [info] circuit_expire_building(): Abandoning circ 85.17.59.169:19090:46080 (state 0:doing handshakes, purpose 13)
Jul 28 22:44:14.752 [info] exit circ (length 1, exit privacyvpndotnet01): $58F9C92572EA8BF85F38C87467CA1542AD8D6F65(waiting for keys)
Jul 28 22:44:14.752 [info] circuit_build_failed(): Our circuit failed to get a response from the first hop (85.17.59.169:19090). I'm going to try to rotate to a better connection.
Jul 28 22:44:14.752 [debug] connection_or_send_destroy(): Sending destroy (circID 46080).
A) Why are we counting cbt timeouts for one-hop circs? I guess in circuit_expire_building() we do in fact compute begindir_cutoff as a function of circ_times.timeout_ms. Ok.
B) If the first hop fails to establish, we shouldn't necessarily be blaming our circuit build timeout. It could be that we don't have a network. But it could also be that our cbt is too small. Hm.
C) What's up with this "expire it twice" business? Are we marking the circuit to state MEASURE the first time, then when the TLS finally finishes, we're killing it again and calling circuit_build_times_count_close()?
I get lots of these TLS conn failures in quick succession when my network goes away, and CBT is punishing me for it.Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1741Hidden Service Servers complain about ancient circs2020-06-13T14:05:17ZMike PerryHidden Service Servers complain about ancient circsChanges to circuit_expire_old_circuits_clientside() in 0.2.2.14-alpha introduced the spurious log message "Ancient non-dirty circuit" about potentially stale hidden service server side circuits (purpose 17). These circuits are held open ...Changes to circuit_expire_old_circuits_clientside() in 0.2.2.14-alpha introduced the spurious log message "Ancient non-dirty circuit" about potentially stale hidden service server side circuits (purpose 17). These circuits are held open longer deliberately by the client for performance reasons, and should not generate notice messages.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1740Circuit build timeout code is recording cannibalized circ times2020-06-13T14:05:17ZMike PerryCircuit build timeout code is recording cannibalized circ timesThe circuit build timeout learning code is recording circ build times for 4 hop hidden service and other cannibalized circuits. This can lead to incorrect timeout data and log messages like: "Strange value for circuit build time" and "Ex...The circuit build timeout learning code is recording circ build times for 4 hop hidden service and other cannibalized circuits. This can lead to incorrect timeout data and log messages like: "Strange value for circuit build time" and "Extremely large value for circuit build timeout".Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1739Control port no longer sends CIRC TIMEOUT events2020-06-13T14:05:16ZMike PerryControl port no longer sends CIRC TIMEOUT eventsThe shift to a right-censored pareto distribution for circuit build times in 0.2.2.14-alpha caused us to fail to emit the CIRC FAILED REASON=TIMEOUT event to the control port, due to the purpose change not immediately generating a circ c...The shift to a right-censored pareto distribution for circuit build times in 0.2.2.14-alpha caused us to fail to emit the CIRC FAILED REASON=TIMEOUT event to the control port, due to the purpose change not immediately generating a circ close.Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1735Decide what to do with the debian/ directory in Tor2020-06-13T14:05:15ZSebastian HahnDecide what to do with the debian/ directory in TorDuring the dev mtg, it was suggested to keep the debian/ directory more up to date by merging weasel's changes more often. The alternative idea was to remove it entirely to make sure people don't find a debian directory and expect it to ...During the dev mtg, it was suggested to keep the debian/ directory more up to date by merging weasel's changes more often. The alternative idea was to remove it entirely to make sure people don't find a debian directory and expect it to work.Tor: 0.2.2.x-finalweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/1731tor misparses libevent 1.4.14b-stable on bsd2020-06-13T14:05:14ZRoger Dingledinetor misparses libevent 1.4.14b-stable on bsd<Tas> hm, Tor v0.2.2.14-alpha has a wrong message on startup: "Jul 26 03:43:56.451 [warn] Libevent version 1.4.14b-stable often crashes when running a Tor server with BSD variants. Please use the latest version of libevent (1.3b or later...<Tas> hm, Tor v0.2.2.14-alpha has a wrong message on startup: "Jul 26 03:43:56.451 [warn] Libevent version 1.4.14b-stable often crashes when running a Tor server with BSD variants. Please use the latest version of libevent (1.3b or later)"
<Tas> 1.4.x is newer than 1.3.x
<Tas> and it doesn't crash either :-)
In tor_decode_libevent_version() it says:
/* Try the new preferred "1.4.11-stable" format. */
fields = sscanf(v, "%u.%u.%u%c", &major, &minor, &patchlevel, &c);
if (fields == 3 ||
(fields == 4 && (c == '-' || c == '_'))) {
return V(major,minor,patchlevel);
}
Perhaps the problem is that Tor doesn't know how to handle both a letter and a dash?
I don't know what strings are valid libevent versions, so this is best as Nick's bug.Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1709Fix compilation with mingw and OpenSSL 0.9.8m+2020-06-13T14:05:12ZTracFix compilation with mingw and OpenSSL 0.9.8m+--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+...--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+ #define _WIN32_WINNT 0x400
+ #define WIN32_LEAN_AND_MEAN
+ #if defined(_MSC_VER) && (_MSC_VER < 1300)
+ #include <winsock.h>
+ #else
+ #include <winsock2.h>
+ #include <ws2tcpip.h>
+ #endif
+#endif
#include <openssl/ssl.h>
#include <openssl/ssl3.h>
#include <openssl/err.h>
**Trac**:
**Username**: mingw-sanTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1653exit relays don't consider local cell queue when hearing sendme2020-06-13T14:05:01ZRoger Dingledineexit relays don't consider local cell queue when hearing sendmeWhen the exit relay gets a circuit-level sendme cell, it starts reading on the exit streams, even if we have 500 cells queued in our circuit queue already. So our circuit queue just grows and grows in some cases.
Reported by Mashael, Ia...When the exit relay gets a circuit-level sendme cell, it starts reading on the exit streams, even if we have 500 cells queued in our circuit queue already. So our circuit queue just grows and grows in some cases.
Reported by Mashael, Ian's grad student. She might even have a patch, but I haven't seen it yet so opening a ticket.Tor: 0.2.2.x-final