Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:49:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17145<tor.exe --service install -options -f ...\torrc> returns Error 1064 on Windows2020-06-13T14:49:22ZTrac<tor.exe --service install -options -f ...\torrc> returns Error 1064 on Windows```
tor --service install -options -f C:\tor\torrc
```
from https://www.torproject.org/docs/faq#NTService failed to start the service (Error 1064: An exception occured in the service when handling the control request).
But other options...```
tor --service install -options -f C:\tor\torrc
```
from https://www.torproject.org/docs/faq#NTService failed to start the service (Error 1064: An exception occured in the service when handling the control request).
But other options works:
```
tor.exe --service install -options ControlPort 9051
```
start the Tor Win32 Service and creates the folder C:\Documents and Settings\LocalService\Application Data\tor - tor.exe works like a client only (no disk torrc file, no relay keys). This is useless because i can't use my torrc and run the relay.
The only way to create a running tor service for a relay is to use the "sc create..." in cmd command line as irc#tor<coderman_> suggested. So this is how it works:
```
sc create "Tor Win32 Service" binPath= "\"C:\tornou\Tor\tor.exe\" --nt-service -f \"C:/tornou/Data/Tor/torrc\""
```
returns ImagePath="C:\tornou\Tor\tor.exe" --nt-service -f "C:/tornou/Data/Tor/torrc" and the service is running.
From this point of view, if nobody will fix the related bug, the https://www.torproject.org/docs/faq#NTService may be updated with this "sc create... working option".
Regards,
torQUES
**Trac**:
**Username**: TORquesTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21394connection timeouts are affecting Tor Browser usability2020-12-21T14:22:51ZArthur Edelsteinconnection timeouts are affecting Tor Browser usabilityI have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the brow...I have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the browser console and get the tor password by entering
`m_tb_control_pass`
And then I paste the result like this:
`authenticate [value of m_tb_control_pass]`
Finally I enter
`setevents circ stream`.
What I have noticed is that a significant fraction of new site connections result in at least 1 timeout of 10 seconds. (Tor Browser's CircuitStreamTimeout is set to 0, which results in a timeout equal to MIN_CIRCUIT_STREAM_TIMEOUT, or 10 seconds.) Here's what a timeout looks like:
```
Feb 03 19:00:03 650 STREAM 868 NEW 0 people.torproject.org:443 SOURCE_ADDR=127.0.0.1:50318 PURPOSE=USER
Feb 03 19:00:03 650 CIRC 149 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597
Feb 03 19:00:03 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 BUILT [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 STREAM 868 SENTCONNECT 149 people.torproject.org:443
[...]
Feb 03 19:00:14 650 STREAM 868 DETACHED 149 people.torproject.org:443 REASON=TIMEOUT
Feb 03 19:00:14 650 CIRC 150 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:14.588714
```
After a timeout occurs, the tor client closes the circuit, builds a new circuit and attempts to connect to the same site again. This repeats at least 3 times.
I did an experiment where I connected to https://people.torproject.org/~arthuredelstein (a page with hardly any content) and then repeatedly selected "New Tor Circuit for this Site" 50 times.
Here are the results for 50 reloads. Each digit represents the number of 10-second stream timeouts observed before a given connection succeeded.
20020000000000000000002010000000000001000100000103
In other words 8 out of 50 connections showed a timeout. And interestingly, four of these connections exhibited a double or triple timeout (20 or 30 seconds delay).
I think this may be a big part of the perception of Tor Browser as "slow". Actual loading of pages doesn't seem drastically slow to me, and once I have successfully connected to a new site, following links to other pages on the same site (i.e., the same circuit) is usually acceptable.
(I also did another quick test on another site and 5/25 connections had at least 1 timeout.)
So here are some questions for further investigation:
* Why are there so many timeouts? Are any of these timeouts due to silent errors in a Tor node? (If such errors could be promptly reported back to the client, maybe we could avoid the waiting for the long timeout.)
* What's the reason for MIN_CIRCUIT_STREAM_TIMEOUT being 10 seconds? Would it do any harm to make this shorter, say 5 seconds or 2 seconds?
* So many double or triple timeouts are suspicious, because each timeout in a double or triple is reported for a different circuit. Could this mean the connection error is caused by the client or guard rather than a connection failure at the exit node?Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22212[warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padd...2020-06-13T15:49:38ZRoger Dingledine[warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?Normal Tor client, running `Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118`, got this log line:
```
May 10 02:50:11.217 [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did ...Normal Tor client, running `Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118`, got this log line:
```
May 10 02:50:11.217 [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump? (on Tor 0.3.1.0-alpha-dev 2e4f3b36bdfd5118)
```
My tor client had been idle for hours before this point, and the log message coincides with a new request that I made. I'm pretty sure there was no clock jump.
Alas, I have no more detailed logs. I'll try to reproduce with logs.Tor: 0.3.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/22660Guard against stack smashing attacks in tor with additional compiler options.2020-06-13T15:10:20ZteorGuard against stack smashing attacks in tor with additional compiler options.If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will protect against stack smashing attacks that jump the stack guard page(s):
```
Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" opt...If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will protect against stack smashing attacks that jump the stack guard page(s):
```
Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" option, which prevents the stack-pointer from moving
into another memory region without accessing the stack guard-page (it
writes one word to every 4KB page allocated on the stack).
```
III Solutions, https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
"
-fstack-check
Generate code to verify that you do not go beyond the boundary of the stack. You should specify this flag if you are running in an environment with multiple threads, but only rarely need to specify it in a single-threaded environment since stack overflow is automatically detected on nearly all systems if there is only one stack.
Note that this switch does not actually cause checking to be done; the operating system must do that. The switch causes generation of code to ensure that the operating system sees the stack being extended.
"
http://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Code-Gen-Options.html#Code-Gen-Options
This protects against:
```
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
CentOS;
```
There are remote attack possibilities mentioned in the paper as well.
We might also want to add:
```
-Wl,-z,noexecstack and -Wl,-z,noexecheap
```
https://www.owasp.org/index.php/C-Based_Toolchain_Hardening#GCC.2FBinutils
[0]: for clsng, we could use -fsanitize=safe-stack instead, but that's more intrusive: https://blog.quarkslab.com/clang-hardening-cheat-sheet.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22798Windows relay is several times slower than Linux relay2020-06-13T15:13:25ZTracWindows relay is several times slower than Linux relayI have launched two relays: first one in native mode on Windows, second one in virtual machine on Linux.
Then measured their bandwidth using three-hop circuit: refEntry, myRelay, refExit
refEntry is [[https://atlas.torproject.org/#detai...I have launched two relays: first one in native mode on Windows, second one in virtual machine on Linux.
Then measured their bandwidth using three-hop circuit: refEntry, myRelay, refExit
refEntry is [[https://atlas.torproject.org/#details/13B2354C74CCE29815B4E1F692F2F0E86C7F13DD|13B2354C74CCE29815B4E1F692F2F0E86C7F13DD]]
refExit is [[https://atlas.torproject.org/#details/07C05ED4825F51D5BE4CDBBAA80BFA484132A2F5|07C05ED4825F51D5BE4CDBBAA80BFA484132A2F5]]
Windows version of Tor was able to provide 51 KiB/s.
Linux version - 163 KiB/s, which is three times higher.
But this was my measurements.
BwAuth ratings for this relays are far more different:
Windows one have weight = 18 (19/13/22/18).
Linux one got weight = 1030 (293/1030/1460).
Which leads to actual traffic rising from 1 KiB/s to ~500 KiB/s.
I can keep relay in virtual machine for a while, but it would be much better if Windows version gets fixed.
Here are the versions of software used in tests:
OS: Windows 7 SP1 x64 (host)
OS: Ubuntu 16.04 x64 (guest)
VM: VirtualBox 5.1.22
Tor: 0.2.9.11 (Linux)
Tor: 0.2.9.11, 0.3.0.8 (Windows)
Also I have obtained TCP packets dump from relay's network interface:
(REDACTED)
Packets 1-1584 are slow transfer (Windows relay).
Packets 1585-8659 are fast transfer (Linux VM relay).
I can made additional tests and provide additional information if needed.
**Trac**:
**Username**: VortTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2020-06-13T15:16:34Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23250tor-0.3.0.10: test failure on NetBSD2020-06-13T15:12:44ZTractor-0.3.0.10: test failure on NetBSDWhen running the self tests on NetBSD, there is one problem:
```
===> Testing for tor-0.3.0.10
/usr/bin/make check-TESTS check-local
PASS: src/test/test
PASS: src/test/test-slow
PASS: src/test/test-memwipe
PASS: src/test/test_workqueue...When running the self tests on NetBSD, there is one problem:
```
===> Testing for tor-0.3.0.10
/usr/bin/make check-TESTS check-local
PASS: src/test/test
PASS: src/test/test-slow
PASS: src/test/test-memwipe
PASS: src/test/test_workqueue
PASS: src/test/test_keygen.sh
PASS: src/test/test-timers
SKIP: src/test/fuzz_static_testcases.sh
PASS: src/test/test_zero_length_keys.sh
PASS: src/test/test_workqueue_cancel.sh
SKIP: src/test/test_workqueue_efd.sh
SKIP: src/test/test_workqueue_efd2.sh
PASS: src/test/test_workqueue_pipe.sh
PASS: src/test/test_workqueue_pipe2.sh
PASS: src/test/test_workqueue_socketpair.sh
SKIP: src/test/test_switch_id.sh
PASS: src/test/test_ntor.sh
FAIL: src/test/test_bt.sh
============================================================================
Testsuite summary for tor 0.3.0.10
============================================================================
# TOTAL: 17
# PASS: 12
# SKIP: 4
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
============================================================================
```
The test log:
```
# less ./src/test/test_bt.sh.log
OK
[1] Abort trap (core dumped) "${builddir:-.}/... |
Done "${PYTHON:-pytho...
BAD
============================================================ T= 1502824395
Tor died: Caught signal 11
0x73c0a4bd <crash_handler+0x73c00041> at ./src/test/test-bt-cl
[1] Abort trap (core dumped) "${builddir:-.}/... |
Done(1) "${PYTHON:-pytho...
-158318
FAIL src/test/test_bt.sh (exit status: 1)
```
**Trac**:
**Username**: wizTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23323sample_laplace_distribution should produce a valid result on 0.02020-06-13T15:13:02Zteorsample_laplace_distribution should produce a valid result on 0.0Destroying the signal with probability 1 in 2^-53^ isn't a great idea.
Let's pick a sensible double value, and pass it through the function instead.
I suggest 2^-54^, but it really doesn't matter exactly what value we use, as long as it...Destroying the signal with probability 1 in 2^-53^ isn't a great idea.
Let's pick a sensible double value, and pass it through the function instead.
I suggest 2^-54^, but it really doesn't matter exactly what value we use, as long as it produces valid results, because the probability is so low.
Introduced in 45bc5a0Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23414rep_hist_format_hs_stats() should add noise, then round2020-06-13T15:13:19Zteorrep_hist_format_hs_stats() should add noise, then roundIn order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Sign...In order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Significant Bits For Differential Privacy" by Ilya Mironov
https://pdfs.semanticscholar.org/2f2b/7a0d5000a31f7f0713a3d20919f9703c9876.pdf
rep_hist_format_hs_stats() rounds once to the bin size, then adds noise which has been rounded to the nearest integer. This isn't ideal, because it makes the least significant bits of the noise meaningless.
Instead, we should:
* round the noise to integer precision
* add the signal to the noise
* round the noisy signal to the bin size
I think this was introduced in 14e83e6.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23415sample_laplace_distribution() should take multiple random inputs2020-06-13T15:13:20Zteorsample_laplace_distribution() should take multiple random inputsCurrently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://t...Currently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://trac.torproject.org/projects/tor/ticket/23061#comment:32
Instead, the function could take a random boolean sign and p, and the transform becomes:
```
result = mu - b * (sign ? 1.0 : -1.0)
* tor_mathlog(1.0 - p);
```
This would increase the precision by one bit, plus whatever precision is lost in `2.0 * fabs(p - 0.5)`.
This may have been introduced in dad5eb7.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23681prop224: Clients mark intro circs as timed-out within seconds2020-06-13T15:36:04ZGeorge Kadianakisprop224: Clients mark intro circs as timed-out within secondsI noticed that my prop224 client had some reconnects and I did some log digging. The original disconnect was caused by a truncate cell (probably natural causes) but then a whole dance of introduction/rendezvous started which ended up mar...I noticed that my prop224 client had some reconnects and I did some log digging. The original disconnect was caused by a truncate cell (probably natural causes) but then a whole dance of introduction/rendezvous started which ended up marking 3 intro circs as timed out within seconds:
```
<FIRST TIMED-OUT INTRO CIRC>
Sep 28 03:55:26.000 [notice] Introduction circuit 2276964442 has opened. Attaching streams.
Sep 28 03:55:26.000 [info] connection_ap_handshake_attach_circuit(): Intro (2276964442) and rend (2943321454) circs are not both ready. Stalling conn. (2 sec old)
Sep 28 03:55:29.000 [info] circuit_expire_building(): Marking circ 2276964442 (state 4:open, purpose 6) as timed-out HS circ
<SECOND TIMED-OUT INTRO CIRC>
Sep 28 03:55:29.000 [info] circuit_get_best(): There is an intro circuit being created right now, but it has already taken quite a while. Starting one in parallel.
Sep 28 03:55:29.000 [notice] Introduction circuit 4126528467 has opened. Attaching streams.
Sep 28 03:55:29.000 [info] connection_ap_handshake_attach_circuit(): Intro (4126528467) and rend (2943321454) circs are not both ready. Stalling conn. (5 sec old)
Sep 28 03:55:34.000 [info] circuit_expire_building(): Marking circ 4126528467 (state 4:open, purpose 6) as timed-out HS circ
<THIRD TIMED-OUT INTRO CIRC>
Sep 28 03:55:29.000 [info] circuit_get_best(): There is an intro circuit being created right now, but it has already taken quite a while. Starting one in parallel.
Sep 28 03:55:34.000 [notice] Introduction circuit 4282777781 has opened. Attaching streams.
Sep 28 03:55:34.000 [info] connection_ap_handshake_attach_circuit(): Intro (4282777781) and rend (2943321454) circs are not both ready. Stalling conn. (10 sec old)
Sep 28 03:55:39.000 [info] circuit_expire_building(): Marking circ 4282777781 (state 4:open, purpose 6) as timed-out HS circ
<CIRCUITS CLOSE>
Sep 28 03:57:26.000 [info] circuit_expire_building(): Abandoning circ 232 137.205.124.35:1720:2276964442 (state 1,4:open, purpose 6, len 4)
Sep 28 03:57:26.000 [info] circuit_mark_for_close_(): Circuit 2276964442 (id: 232) marked for close at src/or/circuituse.c:820 (orig reason: 10, new reason: 0)
Sep 28 03:57:30.000 [info] circuit_expire_building(): Abandoning circ 231 137.205.124.35:1720:4126528467 (state 1,4:open, purpose 6, len 4)
Sep 28 03:57:30.000 [info] circuit_mark_for_close_(): Circuit 4126528467 (id: 231) marked for close at src/or/circuituse.c:820 (orig reason: 10, new reason: 0)
Sep 28 03:57:35.000 [info] circuit_expire_building(): Abandoning circ 233 137.205.124.35:1720:4282777781 (state 1,4:open, purpose 6, len 4)
Sep 28 03:57:35.000 [info] circuit_mark_for_close_(): Circuit 4282777781 (id: 233) marked for close at src/or/circuituse.c:820 (orig reason: 10, new reason: 0)
```
You can see that we went ahead and marked intro circs as timed-out within 3 seconds of launching them which makes no sense, and caused a whole lot of mess in the prop224 state machine.
We should try to figure out if there is a bug here.Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23790rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying ...2020-06-13T15:15:24ZTracrend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying intro pointsIn `rend_service_prune_list_impl_(void)` (src/or/rendservice.c), the introduction points are copied over from the old to new `rend_service_t`:
```
smartlist_add_all(new->intro_nodes, old->intro_nodes);
```
but, the `desc_is_dirty` fiel...In `rend_service_prune_list_impl_(void)` (src/or/rendservice.c), the introduction points are copied over from the old to new `rend_service_t`:
```
smartlist_add_all(new->intro_nodes, old->intro_nodes);
```
but, the `desc_is_dirty` field is not copied over.
If a reload occurs between after a hidden service is added, but before its descriptor is published for the first time (triggered via `desc_is_dirty`), it will not publish its first descriptor until:
```
rendinitialpostdelay + crypto_rand_int(2*rendpostperiod)
```
It looks like it's simply missing `new->desc_is_dirty = old->desc_is_dirty;` prior to copying of introduction points.
**Trac**:
**Username**: jlTor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24043monotonic time test failure on 0.3.0.x2020-06-13T15:16:32Zweasel (Peter Palfrader)monotonic time test failure on 0.3.0.xhttps://jenkins.torproject.org/job/tor-debian-0.3.0-nightly-binaries/169/ARCHITECTURE=amd64,SUITE=jessie/consoleFull
on (I think) 4d73ed10c40938d1ef1cf5628fd1840ee64df8ff
```
01:45:40 util/pwdb: [forking] OK
01:45:40 util/calloc_check: ...https://jenkins.torproject.org/job/tor-debian-0.3.0-nightly-binaries/169/ARCHITECTURE=amd64,SUITE=jessie/consoleFull
on (I think) 4d73ed10c40938d1ef1cf5628fd1840ee64df8ff
```
01:45:40 util/pwdb: [forking] OK
01:45:40 util/calloc_check: OK
01:45:40 util/monotonic_time:
01:45:40 FAIL ../src/test/test_util.c:5552: assert(monotime_coarse_diff_msec(&mtc1, &mtc2) OP_GE 125): 0 vs 125
01:45:40 [monotonic_time FAILED]
01:45:40 util/monotonic_time_ratchet: [forking] OK
01:45:40 util/htonll: OK
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24250In a private network some relays advertise zero bandwidth-observed2020-06-13T15:17:19ZSebastian HahnIn a private network some relays advertise zero bandwidth-observedA lot of relays have these lines:
bandwidth 1073741824 1073741824 0
even though at least some of them have handled actual traffic. The network is a private non-testing Tor network that is deployed in 10.0.0.0/8 space.
I'm using the f...A lot of relays have these lines:
bandwidth 1073741824 1073741824 0
even though at least some of them have handled actual traffic. The network is a private non-testing Tor network that is deployed in 10.0.0.0/8 space.
I'm using the following options:
ExtendAllowPrivateAddresses 1
EnforceDistinctSubnets 0
ClientRejectInternalAddresses 0
ClientDNSRejectInternalAddresses 0
CountPrivateBandwidth 1
ExitPolicyRejectPrivate 0Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24367Changing pluggable transports (during start-up) in Tor Browser is broken2020-06-13T15:17:47ZGeorg KoppenChanging pluggable transports (during start-up) in Tor Browser is brokenThe fix for #23347 made bridges work again in tor but did not fully fix the problem/introduced a new issue: changing pluggable transports during start-up of Tor Browser is broken. Steps to reproduce are:
1) Start Tor Browser and select ...The fix for #23347 made bridges work again in tor but did not fully fix the problem/introduced a new issue: changing pluggable transports during start-up of Tor Browser is broken. Steps to reproduce are:
1) Start Tor Browser and select e.g. `obfs3` as a transport
2) Before finally connecting, click the `Cancel` button
3) Reconfigure the censorship bypass settings and choose, e.g. `obfs4`
4) Resume starting. This time you might get an error (indicating that it's still an obfs3 bridge your tor wants to connect to) and/or just a stalled bootstrap process.
Even worse, after quitting the browser and restarting the start-up process is still broken: it does not proceed and one only gets
```
Nov 21 11:55:59.000 [notice] Ignoring directory request, since no bridge nodes are available yet.
```
messages in the terminal.
The first bad commit is 93a8ed3b83b5f20768562ca2aff4eba7aca667d8.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24815Validate shared random state dates before each voting period2020-06-13T15:19:56ZteorValidate shared random state dates before each voting periodWhen tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round becau...When tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round because they are under heavy load. (I have seen clock jumps happen on Linux and BSD under the recent heavy load.)
I see this message when I restart my authority:
```
Jan 07 09:48:13.179 [info] or_state_load: Loaded state from "/Users/USER/tor/auth/auth-sr-3e/state"
Jan 07 09:48:14.977 [info] disk_state_validate: SR: Disk state valid after/until times are invalid.
Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).
Jan 07 09:48:16.026 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```
Even though this message was logged just before I killed it:
```
Jan 07 09:47:45.328 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/24853backport the new authority and fallback file formats2020-06-13T15:20:13Zteorbackport the new authority and fallback file formatsAfter doing #24851 and #24852.
* backport them to all supported tor releases:
* authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* fallbacks: 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0....After doing #24851 and #24852.
* backport them to all supported tor releases:
* authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* fallbacks: 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* make sure all supported tor releases parse the files correctly (unit tests)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24903Bug: Line unexpectedly reached at pathbias_should_count at src/or/circpathbia...2020-06-13T15:29:47ZstarlightBug: Line unexpectedly reached at pathbias_should_count at src/or/circpathbias.c:372Experienced bug-check while testing an explict exit with:
```
setconf __DisablePredictedCircuits=1
setconf ExcludeExitNodes={c1},{c2},{c3}
setconf SocksPort="x.x.x.x:x NoIsolateSOCKSAuth NoIsolateClientProtocol NoIsolateClientAddr NoIso...Experienced bug-check while testing an explict exit with:
```
setconf __DisablePredictedCircuits=1
setconf ExcludeExitNodes={c1},{c2},{c3}
setconf SocksPort="x.x.x.x:x NoIsolateSOCKSAuth NoIsolateClientProtocol NoIsolateClientAddr NoIsolateDestAddr NoIsolateDestPort"
setconf ExitNodes=X
```
```
Bug: Line unexpectedly reached at pathbias_should_count at src/or/circpathbias.c:372.
Stack trace: (on Tor 0.3.2.9 9e8b762fcecfece6)
log_backtrace src/common/backtrace.c:108
tor_bug_occurred_ src/common/util_bug.c:118
pathbias_should_count *src/or/circpathbias.c:372
pathbias_count_build_attempt src/or/circpathbias.c:418
circuit_finish_handshake src/or/circuitbuild.c:1479
src/or/command.c:424
command_process_cell src/or/command.c:209
channel_tls_handle_cell src/or/channeltls.c:1152
src/or/connection_or.c:2095
src/or/connection.c:3468
src/or/main.c:738
event_base_loop event.c:1373
do_main_loop src/or/main.c:2637
tor_main src/or/main.c:3780
main src/or/tor_main.c:35
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25113monotonic_time unit test fail, 0.3.3.1-alpha debian armel2020-06-13T15:21:27ZRoger Dingledinemonotonic_time unit test fail, 0.3.3.1-alpha debian armel```
<weasel> util/monotonic_time:
<weasel> FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 / 1000000 + 1): 41399 vs 41395
<weasel> [monotonic_time FAILED]
<weasel> https://buildd.debian.org/status/fetch.php?pkg=tor&arch...```
<weasel> util/monotonic_time:
<weasel> FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 / 1000000 + 1): 41399 vs 41395
<weasel> [monotonic_time FAILED]
<weasel> https://buildd.debian.org/status/fetch.php?pkg=tor&arch=armel&ver=0.3.3.1-alpha-1&stamp=1517099318&raw=0
```
Looks like the armel build failed:
https://buildd.debian.org/status/package.php?p=tor&suite=experimental
The comment in the unit tests right above that is
```
/* We need to be a little careful here since we don't know the system load.
```
which makes me suspicious. :)Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25116hs: circuit_log_ancient_one_hop_circuits() should probably not log single oni...2020-06-13T15:21:28ZDavid Gouletdgoulet@torproject.orghs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuitAssume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circ...Assume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circuit_log_ancient_one_hop_circuits()` to log single hop circuits.
I think we want to ignore to log anything service related in there. Some v3 services have started seeing that heartbeat more and more in the last days.
Related: #8387Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25141enabling CellStatistics results in gigabytes of incremental memory consumption2020-06-13T15:21:38Zstarlightenabling CellStatistics results in gigabytes of incremental memory consumptionThis was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or elim...This was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or eliminated.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25347Tor keeps on trying the same overloaded guard over and over2020-06-13T15:24:07ZteorTor keeps on trying the same overloaded guard over and overWhen Tor can't download microdescriptors (#21969), maybe it should try authorities or fallbacks (#23863), before it runs out of microdesc retries (#24113).
But even after Tor has the microdescs it needs, it sometimes doesn't start build...When Tor can't download microdescriptors (#21969), maybe it should try authorities or fallbacks (#23863), before it runs out of microdesc retries (#24113).
But even after Tor has the microdescs it needs, it sometimes doesn't start building circuits again. Instead, it is in state "waiting for circuit".
For the log messages, see:
https://trac.torproject.org/projects/tor/ticket/21969#comment:82Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/25416[warn] Received http status code 404 ("Consensus is too old") from server '19...2020-06-13T15:22:44Ztoralf[warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, strat...the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, stratum 2, offset -0.000601, delay 0.02594
server 2a01:238:439c:1900::3:1, stratum 2, offset 0.000477, delay 0.04520
server 2a02:16d0:0:4::4, stratum 2, offset -0.002245, delay 0.03976
server 90.187.7.5, stratum 2, offset -0.002271, delay 0.04788
server 129.70.132.36, stratum 2, offset 0.002152, delay 0.04262
server 145.239.3.131, stratum 2, offset 0.001487, delay 0.03177
server 85.236.36.4, stratum 2, offset -0.000501, delay 0.03650
3 Mar 17:18:09 ntpdate[18195]: adjust time server 2a01:4f8:221:3b02::101:1 offset -0.000601 sec
```
And I still get once a day or so _:
```
Mar 03 17:18:01.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
Mar 03 17:18:01.000 [notice] Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf) opening log file.
Mar 03 17:18:02.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
```
tor version is 0.3.4-alpha-devTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25733Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at ../src/...2020-06-13T15:29:07ZTracBug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at ../src/or/circuitstats.c:772.Server running couple of hundred HS domains. Tor crashed. One spammer is trying simple DDoS.
```
Apr 06 20:36:28.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Apr 06 20:36:28.000 [notice] Rea...Server running couple of hundred HS domains. Tor crashed. One spammer is trying simple DDoS.
```
Apr 06 20:36:28.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Apr 06 20:36:28.000 [notice] Read configuration file "-------------------".
Apr 06 20:36:28.000 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) opening log file.
Apr 06 20:36:42.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Apr 06 20:36:42.000 [warn] Error launching circuit to node $F0F5074A6DADD3DC22E1FAA18FD6D89C-------- at --------- for service ---------------.
Apr 06 20:36:56.000 [warn] Your Guard remedy ($3FEBFB6A491D30CACC2C2995EDB41717A6F94E95) is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could$
Apr 06 20:36:59.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Apr 06 20:37:26.000 [warn] Your Guard AlienZone ($80392DC1522E647C56457CEBA58DD84CC56AEC44) is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it co$
Apr 06 20:37:29.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Apr 06 20:37:29.000 [warn] Error launching circuit to node $9AEF164F5BE5618509C9E60----------- at ---------------- for service ---------------------------.
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 996 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 997 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 998 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
........
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] tor_assertion_failed_(): Bug: ../src/or/circuitstats.c:772: circuit_build_times_get_xm: Assertion bin_counts > 0 failed; aborting. (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at ../src/or/circuitstats.c:772. Stack trace: (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(log_backtrace+0x43) [0x55ff6c113313] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(tor_assertion_failed_+0x8d) [0x55ff6c12e54d] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(circuit_build_times_set_timeout+0x83e) [0x55ff6c0760be] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(circuit_expire_building+0x1012) [0x55ff6c07a5b2] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(+0x52bd7) [0x55ff6bfdfbd7] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1f6aa) [0x7faafc9836aa] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7faafc984227] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(do_main_loop+0x28d) [0x55ff6bfe085d] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(tor_main+0xe1d) [0x55ff6bfe367d] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(main+0x19) [0x55ff6bfdc0a9] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7faafb18b1c1] (on Tor 0.3.2.10 )
Apr 06 20:37:49.000 [err] Bug: /usr/sbin/tor(_start+0x2a) [0x55ff6bfdc0fa] (on Tor 0.3.2.10 )
```
**Trac**:
**Username**: cstestTor: 0.2.9.x-finalMike PerryMike Perry