Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:45:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31766INTERNAL_ERROR in map_anon.c2020-06-13T15:45:42ZTracINTERNAL_ERROR in map_anon.cThe following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information...The following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information, or do any testing, to resolve this.
Please see attached file "tor-0.4.1.5-fault-output.txt" for full fault output.
----------------------------------
INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:213: nodump_result == 0/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x2af1bc71bda3]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x91)[0x2af1bc71c6a1]
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/22761TBB enhancement request: DuckDuckGoOnion2020-06-15T23:45:20ZTracTBB enhancement request: DuckDuckGoOnionI would like to suggest an enhancement: use DuckDuckGoOnion as the default TBB search engine.
The reason, of course, is that the searches stay within the Tor network, making them harder to snoop upon.
**Trac**:
**Username**: tmpname...I would like to suggest an enhancement: use DuckDuckGoOnion as the default TBB search engine.
The reason, of course, is that the searches stay within the Tor network, making them harder to snoop upon.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/22747Pls document relay with restricted socket count2020-06-13T15:10:50ZTracPls document relay with restricted socket countThere is documentation in the Tor manual about how to alleviate the problem of constrained socket memory (ConstrainedSockets, ConstrainedSockSize), but not about a restricted number of sockets.
The problem of a restricted number of TCP ...There is documentation in the Tor manual about how to alleviate the problem of constrained socket memory (ConstrainedSockets, ConstrainedSockSize), but not about a restricted number of sockets.
The problem of a restricted number of TCP sockets is particularly acute in OpenVZ VPSs. A vendor may offer a great deal of bandwidth, but then restrict the practical use of it by imposing a low limit on the number of sockets in use.
So... how do I tell my relay to use no more than n TCP sockets?
-------------------------------------
```
# cat /proc/user_beancounters | grep sock
numtcpsock 3 4 3000 3000
othersockbuf 46240 108960 20571088 28942177
numothersock 42 56 3000 3000
```
**Trac**:
**Username**: tmpname0901Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22246ASSERT failure on v0.3.0.62020-06-13T15:08:52ZTracASSERT failure on v0.3.0.6```
May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug: src/common/container.c:1430: digest256map_get: Assertion map failed; aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256...```
May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug: src/common/container.c:1430: digest256map_get: Assertion map failed; aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256map_get at src/common/container.c:1430. Stack trace: (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x7f2bfbdefc12] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7f2bfbe07b53] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(digest256map_get+0x11b) [0x7f2bfbdf8d8b] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(hs_cache_lookup_as_dir+0x74) [0x7f2bfbde3714] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0x192323) [0x7f2bfbdb3323] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(connection_dir_process_inbuf+0x6a2) [0x7f2bfbdb7e42] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x794) [0x7f2bfbd92af4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xbc8a1) [0x7f2bfbcdd8a1] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(event_base_loop+0x804) [0x7f2bfbe692b4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3f3) [0x7f2bfbcd91e3] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_main+0xe75) [0x7f2bfbcda305] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(main+0x19) [0x7f2bfbcd6319] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f2bfadf4d1d] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xb5229) [0x7f2bfbcd6229] (on Tor 0.3.0.6 47d2e4f06ec26a79)
```
**Trac**:
**Username**: tmpname0901Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21035Assertion in 0.2.9.8: monotime_coarse_get2020-06-13T15:04:44ZTracAssertion in 0.2.9.8: monotime_coarse_getDec 20 02:44:06.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 20 02:44:06.630 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 20 02:44:0...Dec 20 02:44:06.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 20 02:44:06.630 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 20 02:44:06.630 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 20 02:44:06.630 [notice] Read configuration file "/etc/tor/torrc".
Dec 20 02:44:06.633 [notice] Based on detected system memory, MaxMemInQueues is set to 6144 MB. You can override this by setting MaxMemInQueues by hand.
Dec 20 02:44:06.634 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 20 02:44:06.634 [notice] Opening OR listener on 46.29.248.238:443
Dec 20 02:44:06.634 [notice] Opening Directory listener on 46.29.248.238:80
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 20 02:44:06.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 20 02:44:06.000 [err] tor_assertion_failed_(): Bug: src/common/compat_time.c:359: monotime_coarse_get: Assertion r == 0 failed; aborting. (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: Assertion r == 0 failed in monotime_coarse_get at src/common/compat_time.c:359. Stack trace: (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x2b9dce1a5222] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x2b9dce1bd6d3] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(monotime_coarse_get+0x59) [0x2b9dce1a9e59] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_main+0x86) [0x2b9dce099d46] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(main+0x19) [0x2b9dce096b19] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x2b9dcf1e6d1d] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(+0xada29) [0x2b9dce096a29] (on Tor 0.2.9.8 01ab67e38b358ae9)
---------------------------
Environment: CentOS v6.8, OpenVZ virtualization, confirmed system time is accurate. No problem seen in same environment with Tor v0.2.8.11.
**Trac**:
**Username**: tmpname0901Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20391Invalid Nick Mathewson key in Tor Wiki2020-06-13T17:24:08ZTracInvalid Nick Mathewson key in Tor WikiPage https://www.torproject.org/docs/signing-keys.html.en shows Nick Mathewson's old PGP key, not the current one. It is the current key that is used to sign the Tor source tarballs.
See here: http://www.wangafu.net/~nickm/key-transiti...Page https://www.torproject.org/docs/signing-keys.html.en shows Nick Mathewson's old PGP key, not the current one. It is the current key that is used to sign the Tor source tarballs.
See here: http://www.wangafu.net/~nickm/key-transition-statement-2.txt.asc
Also, since the Wiki page will be edited, it would be nice if instruction on using the Tor public key were on the page. When verifying the tarball I get this:
$ gpg --verify tor-0.2.8.9.tar.gz.asc
gpg: Signature made Mon 17 Oct 2016 08:16:09 PM UTC using RSA key ID 8D29319A
gpg: Can't check signature: public key not found
gpg: Signature made Mon 17 Oct 2016 08:16:09 PM UTC using RSA key ID 9E92B601
gpg: Good signature from "Nick Mathewson <nickm@alum.mit.edu>"
gpg: aka "Nick Mathewson <nickm@wangafu.net>"
gpg: aka "Nick Mathewson <nickm@torproject.org>"
gpg: aka "Nick Mathewson <nickm@freehaven.net>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2133 BC60 0AB1 33E1 D826 D173 FE43 009C 4607 B1FB
Subkey fingerprint: 7A02 B352 1DC7 5C54 2BA0 1545 6AFE E6D4 9E92 B601
Note the "Can't check signature: public key not found" above.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/20203tor_assertion_failed on low memory2020-06-13T15:01:38ZTractor_assertion_failed on low memoryTor crashed with the output below. This was seen on a VMware VPS, running on a fully-updated 64-bit CentOS v6.8 system with 1GB of RAM. No indication of low memory was seen in the system logs, and no swap space was apparently used by t...Tor crashed with the output below. This was seen on a VMware VPS, running on a fully-updated 64-bit CentOS v6.8 system with 1GB of RAM. No indication of low memory was seen in the system logs, and no swap space was apparently used by the system.
--------------------------
Sep 03 16:27:12.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Sep 03 16:27:12.000 [notice] Removed 782124800 bytes by killing 3 circuits; 1120 circuits remain alive. Also killed 0 non-linked directory connections.
Sep 03 16:27:12.000 [err] tor_assertion_failed_(): Bug: src/or/relay.c:2618: channel_flush_from_first_active_circuit: Assertion queue->n > 0 failed; aborting. (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: Assertion queue->n > 0 failed in channel_flush_from_first_active_circuit at src/or/relay.c:2618. Stack trace: (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x7fbe9d5e89f2] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7fbe9d5f9663] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(channel_flush_from_first_active_circuit+0x40b) [0x7fbe9d50c25b] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(channel_flush_some_cells+0x103) [0x7fbe9d55a773] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(scheduler_run+0x115) [0x7fbe9d54beb5] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(+0x10d1c7) [0x7fbe9d54c1c7] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(event_base_loop+0x53c) [0x7fbe9d655aec] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3d9) [0x7fbe9d4ecf59] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(tor_main+0xde5) [0x7fbe9d4edfc5] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(main+0x19) [0x7fbe9d4ea019] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fbe9c613d1d] (on Tor 0.2.8.7 )
Sep 03 16:27:12.000 [err] Bug: /usr/bin/tor(+0xaaf29) [0x7fbe9d4e9f29] (on Tor 0.2.8.7 )
**Trac**:
**Username**: tmpname0901Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17762Complaint of malformed IP/policy2020-06-13T14:51:53ZTracComplaint of malformed IP/policyWhile using the ReducedExitPolicy and
ExitRelay 1
IPv6Exit 1
I occasional get these warnings in my log file:
Dec 06 07:27:56.000 [warn] Malformed IP "???" in address pattern; rejecting.
Dec 06 07:27:56.000 [warn] Couldn't pars...While using the ReducedExitPolicy and
ExitRelay 1
IPv6Exit 1
I occasional get these warnings in my log file:
Dec 06 07:27:56.000 [warn] Malformed IP "???" in address pattern; rejecting.
Dec 06 07:27:56.000 [warn] Couldn't parse line "[???]:*". Dropping
Dec 06 07:27:56.000 [warn] Malformed policy 'reject [???]:*'. Discarding entire policy list.
Dec 06 07:27:56.000 [warn] append_exit_policy_string(): Bug: Unable to parse internally generated policy reject [???]:* (on Tor 0.2.7.5 )
No problems seen with v0.2.6.10 while using the same config file.
I'm setting the Priority and Severity here to moderate settings, because I don't know if the warnings are anything more than clutter. If the complaints are indicating a problem that hinders the relay as an exit node, then the urgency should be bumped up.
**Trac**:
**Username**: tmpname0901Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16929Advised to read missing documentation2020-06-13T14:48:34ZTracAdvised to read missing documentationIn the Tor log file I see this:
Failing because we have 4063 connections already. Please read doc/TUNING for guidance.
However there is no file named TUNING in the v0.2.6.10 source tarball, nor is that word matched on the Documenta...In the Tor log file I see this:
Failing because we have 4063 connections already. Please read doc/TUNING for guidance.
However there is no file named TUNING in the v0.2.6.10 source tarball, nor is that word matched on the Documentation page of the Tor website.
**Trac**:
**Username**: tmpname0901Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16832"Circuit on detached list which I had no reason to mark"2020-06-13T14:48:18ZTrac"Circuit on detached list which I had no reason to mark"Tor v0.2.6.10 running on CentOS6/x86_64. Relay is a middle node, and has this entry in its log file:
Aug 16 11:19:38.000 [warn] circuit_unlink_all_from_channel(): Bug: Circuit on detached list which I had no reason to mark
**Trac**: ...Tor v0.2.6.10 running on CentOS6/x86_64. Relay is a middle node, and has this entry in its log file:
Aug 16 11:19:38.000 [warn] circuit_unlink_all_from_channel(): Bug: Circuit on detached list which I had no reason to mark
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/16223Torsocks v2.1.0 fails to build on RHEL/CentOS 5.x2020-06-13T16:09:32ZTracTorsocks v2.1.0 fails to build on RHEL/CentOS 5.xThe newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
...The newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
from log.c:27:
compat.h:133:25: error: sys/eventfd.h: No such file or directory
make[2]: *** [log.lo] Error 1
This is due to the fact that eventfd.h really does not exist on this system. If I change the include from sys/eventfd.h to sys/syscall.h the compile finishes without error, but then the link fails:
../../src/lib/.libs/libtorsocks.so: undefined reference to `eventfd'
../../src/lib/.libs/libtorsocks.so: undefined reference to `inotify_init1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_create1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_pwait'
collect2: ld returned 1 exit status
No problems seen when building on a CentOS6 system, just on CentOS5.
The prior v2.0.0 does build on CentOS5 with the help of some function attribute trickery (prepending ATTR_HIDDEN to several function and data definitions).
**Trac**:
**Username**: tmpname0901David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15891Wrong address tested for reachability2020-06-13T14:45:45ZTracWrong address tested for reachabilityAfter displaying the correct IP address, as read from the relay config file, Tor attempts to verify the reachability of a different address. See below.
I have no idea where this bogus 198.105.254.68 address is coming from. The last li...After displaying the correct IP address, as read from the relay config file, Tor attempts to verify the reachability of a different address. See below.
I have no idea where this bogus 198.105.254.68 address is coming from. The last line below is followed by a stream of warnings that 198.105.254.68:9001 and 198.105.254.68:9030 cannot be reached. No surprise there, as it is not the address I specified.
-----------------
May 01 11:38:09.000 [notice] Tor 0.2.6.7 (git-9ccf019b168909ef) opening log file.
May 01 11:38:09.933 [notice] Tor v0.2.6.7 (git-9ccf019b168909ef) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1m and Zlib 1.2.8.
May 01 11:38:09.933 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 01 11:38:09.933 [notice] Read configuration file "/etc/tor/torrc".
May 01 11:38:09.937 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
May 01 11:38:09.937 [notice] Based on detected system memory, MaxMemInQueues is set to 747 MB. You can override this by setting MaxMemInQueues by hand.
May 01 11:38:09.938 [notice] Opening Socks listener on 127.0.0.1:9050
May 01 11:38:09.938 [notice] Opening OR listener on 216.218.216.197:9001
May 01 11:38:09.938 [notice] Opening OR listener on [2001:470:1:2f9:0:1:fbc:16ed]:9001
May 01 11:38:09.938 [notice] Opening Directory listener on 216.218.216.197:9030
May 01 11:38:09.000 [warn] Failed to unlink /var/lib/tor/bw_accounting: No such file or directory
May 01 11:38:10.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 2C34FB27A21F0C9EAA2ADA0C2D72EB49F72C975A'
May 01 11:38:10.000 [notice] Configured hibernation. This interval begins at 2015-04-30 00:00:00 and ends at 2015-06-01 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
May 01 11:38:10.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
May 01 11:38:10.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
May 01 11:38:10.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
May 01 11:38:10.000 [notice] Bootstrapped 0%: Starting
May 01 11:38:11.000 [notice] Bootstrapped 80%: Connecting to the Tor network
May 01 11:38:13.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
May 01 11:38:13.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
May 01 11:38:14.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 01 11:38:14.000 [notice] Bootstrapped 100%: Done
May 01 11:38:14.000 [notice] Now checking whether ORPort 198.105.254.68:9001 and DirPort 198.105.254.68:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
**Trac**:
**Username**: tmpname0901Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13591Need update to bridge deploy doc2020-06-13T17:22:27ZTracNeed update to bridge deploy docThis is a follow-up to #11160.
Now the v0.2.5 is stable it is time to add ExtORPort, scramblesuit and obfs4 to the bridge deployment instructions.
**Trac**:
**Username**: tmpname0901This is a follow-up to #11160.
Now the v0.2.5 is stable it is time to add ExtORPort, scramblesuit and obfs4 to the bridge deployment instructions.
**Trac**:
**Username**: tmpname0901cypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/13108Should I give up my relay with FDC address2014-09-13T23:48:42ZTracShould I give up my relay with FDC addressMy relay, in use for 18 months, was recently rendered useless by the decision to block the FDC address space. This is seen by this line in the logs:
[warn] http status 400 ("Authdir is rejecting routers in this range.") response from d...My relay, in use for 18 months, was recently rendered useless by the decision to block the FDC address space. This is seen by this line in the logs:
[warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '194.109.206.212:80'. Please correct.
Now I'm being invoiced to continue this server. Should I just discontinue the server, or will the Authdir policy soon restore the usefulness of having an IP address in the FDC address space?
**Trac**:
**Username**: tmpname0901Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12661Some directory authorities reject IP ranges long after we ask them to stop2020-06-13T16:03:28ZTracSome directory authorities reject IP ranges long after we ask them to stopWhat's going on here?
-------------------
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '193.23.244.244:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 40...What's going on here?
-------------------
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '193.23.244.244:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '171.25.193.9:443'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '194.109.206.212:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '128.31.0.34:9131'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '154.35.32.5:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '76.73.17.194:9030'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '208.83.223.34:443'. Please correct.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/12230Seeking guidance on useful bandwith floor2020-06-13T17:34:55ZTracSeeking guidance on useful bandwith floorIt is not clear to me, and, it seems to a lot of other people, what minimum bandwidth a relay can run and still be useful.
I don't want to spend my time and money on a relay that is so slow that in practical terms it does not contribute...It is not clear to me, and, it seems to a lot of other people, what minimum bandwidth a relay can run and still be useful.
I don't want to spend my time and money on a relay that is so slow that in practical terms it does not contribute to the Tor network. I have no interest at all in running a feel-good relay so I can feel virtuous by "helping". I understand that consensus weight is the determining factor for how traffic is directed, but one has to actually be running a relay to get the consensus value. Better to know in advance if the relay being considered would be beneficial.
If I run a 5Mbps relay does that improve the Tor network or just bloat the relay list for no practical purpose? How about a 1Mbps relay? How about the same 5Mbps relay when running as an exit node?
Please, please, please publish some sort of guidance as to which levels of bandwidth actually are useful.
Thanks.
**Trac**:
**Username**: tmpname0901LunarLunarhttps://gitlab.torproject.org/legacy/trac/-/issues/10558TBB 3.5 build failure2014-02-24T12:49:56ZTracTBB 3.5 build failure[I posted this on the tor-dev mailing list and was advised to open a ticket to pursue it.]
Attempting to build tbb-3.5.1-build1, and failing. See attached log file (from "make all" for failure.
I am building on a fully-updated Ubuntu ...[I posted this on the tor-dev mailing list and was advised to open a ticket to pursue it.]
Attempting to build tbb-3.5.1-build1, and failing. See attached log file (from "make all" for failure.
I am building on a fully-updated Ubuntu v12.04LTS/x86_64 system. I am using the USE_LXC method because KVM won't work in this VMware VM.
tor-browser-bundle.git and gitian-builder.git were both pulled early on 05 Jan 2014.
On my first attempt I did a "make all". That didn't work, so I tried
"./mkbundle-linux.sh" (all I really care about is a Linux/x86_64 build)
and got the same error at what seems the same point in the build process.
This problem isn't listed in the "Known Issues and Quirks" section of the doc.
The build attempts end in the following failure:
Extracting partition for lxc
lxc-start: No such file or directory - failed to get real path for '/home/steve/buildtbb/gitian-builder/target--'
lxc-start: failed to pin the container's rootfs
lxc-start: failed to spawn 'gitian'
lxc-start: No such file or directory - failed to remove cgroup '/sys/fs/cgroup/cpuset//lxc/gitian'
i386 lucid VM creation failed
So... any advice on how to proceed from here?
**Trac**:
**Username**: tmpname0901Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/9987Bug in mp_pool_get()2020-06-13T14:34:41ZTracBug in mp_pool_get()Oct 16 15:54:05.000 [err] mp_pool_get(): Bug: src/common/mempool.c:243: mp_pool_get: Assertion allocated->in_chunk == chunk failed; aborting.
**Trac**:
**Username**: tmpname0901Oct 16 15:54:05.000 [err] mp_pool_get(): Bug: src/common/mempool.c:243: mp_pool_get: Assertion allocated->in_chunk == chunk failed; aborting.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/legacy/trac/-/issues/9758AccountingMax == writes in 0.2.4.x?2020-06-13T14:32:02ZTracAccountingMax == writes in 0.2.4.x?My understanding is that what the AccountingMax setting matches against is traffic written. This seems reasonable for v0.2.3.x given that it writes slightly more than it reads.
My experience with v0.2.4.17 on multiple relays, though, i...My understanding is that what the AccountingMax setting matches against is traffic written. This seems reasonable for v0.2.3.x given that it writes slightly more than it reads.
My experience with v0.2.4.17 on multiple relays, though, is that more bytes are read than written, e.g.:
AccountingBytesReadInInterval 4523345070080
AccountingBytesWrittenInInterval 4398491181056
If AccountingMax is still compared to bytes written then we risk exceeding the user-specified maximum traffic per accounting period.
(Possibly these stats are influenced by the recent botnet activity.)
Note: I am setting the version number for this ticket as 0.2.4.16-rc because 0.2.4.17-rc is not available in the Version drop-down menu.
**Trac**:
**Username**: tmpname0901Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9484Allow setting of window dimensions in TBB2020-06-15T23:16:19ZTracAllow setting of window dimensions in TBBWhen looking at https://panopticlick.eff.org I see that my browser dimensions make me fairly unique. It seems that only 1 in 3264810 users have my browser window size.
I'd like to set the Firefox window width to a less specific size, b...When looking at https://panopticlick.eff.org I see that my browser dimensions make me fairly unique. It seems that only 1 in 3264810 users have my browser window size.
I'd like to set the Firefox window width to a less specific size, but see no way to pass the "-width nnnn" to Firefox on start-up.
I suggest that the start-tor-browser script and/or Vidalia allow passing of parameters to the Firefox command line.
**Trac**:
**Username**: tmpname0901