Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:09Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/849Dir-spec requires "dir-address"2020-06-27T14:10:09ZTracDir-spec requires "dir-address"The current dir-spec.txt from trunk requires "dir-address" [Once or more], but the current implementation does
not display this. Probably the spec should be changed to "any number" or the keyword removed entirely.
[Automatically added...The current dir-spec.txt from trunk requires "dir-address" [Once or more], but the current implementation does
not display this. Probably the spec should be changed to "any number" or the keyword removed entirely.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Freedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/848Fix switch_id to properly drop euid/uid/egid/gid2020-06-27T14:10:09ZJacob AppelbaumFix switch_id to properly drop euid/uid/egid/gidI spent the day with Theo De Raadt and he pointed out that we incorrectly try to drop uid/gid. I'll attach a patch that fixes this.
[Automatically added by flyspray2trac: Operating System: All]I spent the day with Theo De Raadt and he pointed out that we incorrectly try to drop uid/gid. I'll attach a patch that fixes this.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/845Tor crash on ppc64 with bad descriptors2020-06-27T14:10:09ZcodermanTor crash on ppc64 with bad descriptorsTor 0.2.1.6-alpha on ppc64 (PS3 Ubuntu) fails assert reliably with a bad descriptor found in http://peertech.org/files/save-bad-cached-files-tor-ppc64-crash.tgz
The failed assert is:
[err] Bug: policies.c:1266: addr_policy_free: Asserti...Tor 0.2.1.6-alpha on ppc64 (PS3 Ubuntu) fails assert reliably with a bad descriptor found in http://peertech.org/files/save-bad-cached-files-tor-ppc64-crash.tgz
The failed assert is:
[err] Bug: policies.c:1266: addr_policy_free: Assertion p == found->policy failed; aborting.
The Tor instance attempts to remove a canonical policy returned by the hash table HT_REMOVE.
The policy to find is (i added some additional debugging info to help troubleshoot):
debug_policy(): Policy data for 0x101f2d88:
HASH: 1105958104
IsPrivate: 0
addr: 190.21.106.7
mask: 32
prt_min: 1
prt_max: 65535
type: 2
The matched policy shouldn't match, but does return:
debug_policy(): Policy data for 0x1027bb68:
HASH: 2801726591
IsPrivate: 0
addr: 89.2.10.96
mask: 32
prt_min: 1
prt_max: 65535
type: 2
The assert fails because the search policy does not match the found policy in addr_policy_free.
The policy at address 0x1027bb68 is for router "router Unnamed 221.207.2.77 443 0 9030" in the cached files.
The policy at address 0x101f2d88 is for router "router utumno 98.100.128.152 9001 0 0".
I can attempt to assist further if necessary. This does not appear to be a problem on x86 for the same alpha version.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/843tor exited unexpectedly2020-06-27T14:10:09ZTractor exited unexpectedlyI installed vidalia bundle on my mac. When I click on start tor a message saying tor exited unexpectedly cames out.
What is wrong? what should I do? the message log doesn't work either.
thks,
Adriana
[Automatically added by flyspray2tra...I installed vidalia bundle on my mac. When I click on start tor a message saying tor exited unexpectedly cames out.
What is wrong? what should I do? the message log doesn't work either.
thks,
Adriana
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: adrianaAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/840Should Hidden Service answer if a wrong 'begin' cell?2020-06-27T14:10:09ZTracShould Hidden Service answer if a wrong 'begin' cell?
After fix of 444, HS not anymore closing circuits if a wrong 'begin'
cells received. However they never sended 'RELAY_END' cells also.
So well-behaved clients don't known if problems happened.
On other hand, if HS answers then attacker...
After fix of 444, HS not anymore closing circuits if a wrong 'begin'
cells received. However they never sended 'RELAY_END' cells also.
So well-behaved clients don't known if problems happened.
On other hand, if HS answers then attacker can measure latency
(bad 'begin' <-> 'end' cell) on Tor-level so long as he want. (just IMO)
if HS should answer, then a fix:
--- connection_edge.original.c Mon Sep 29 19:20:02 2008
+++ connection_edge.c Mon Oct 20 15:34:18 2008
@@ -2566,7 +2566,7 @@
n_stream->_base.port);
end_payload[0] = END_STREAM_REASON_EXITPOLICY;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
- end_payload, 1, NULL);
+ end_payload, 1, origin_circ->cpath->prev);
connection_free(TO_CONN(n_stream));
tor_free(address);
return 0;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/839Tor 0.2.0.31 (r16744) crash on OpenBSD 4.3-stable (GENERIC)2020-06-27T14:10:09ZfredzupyTor 0.2.0.31 (r16744) crash on OpenBSD 4.3-stable (GENERIC)After only 3 days online, my new Tor relay crashed with no error in log.
Here is the backtrace from the core :
#0 0x0eb5828d in kill () from /usr/lib/libc.so.43.0
#1 0x0eb90833 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legac...After only 3 days online, my new Tor relay crashed with no error in log.
Here is the backtrace from the core :
#0 0x0eb5828d in kill () from /usr/lib/libc.so.43.0
#1 0x0eb90833 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legacy/trac#2 0x0eb31817 in __assert2 (file=0x2742ace0 "/usr/src/lib/libssl/src/crypto/rand/md_rand.c", line=313, func=0x2742ac74 "ssleay_rand_add",
failedexpr=0x2742ad80 "md_c[1] == md_count[1]") at /usr/src/lib/libc/gen/assert.c:52
legacy/trac#3 0x07492eb4 in ssleay_rand_add (buf=0xcfbccd7c, num=4, add=0) at /usr/src/lib/libssl/src/crypto/rand/md_rand.c:219
legacy/trac#4 0x0749282e in RAND_add (buf=0xcfbccd78, num=4, entropy=0) at /usr/src/lib/libssl/src/crypto/rand/rand_lib.c:167
legacy/trac#5 0x0036f9e3 in ssl23_connect (s=0x7fd8ec00) at /usr/src/lib/libssl/src/ssl/s23_clnt.c:114
legacy/trac#6 0x0037ac09 in SSL_connect (s=0x7fd8ec00) at /usr/src/lib/libssl/src/ssl/ssl_lib.c:825
legacy/trac#7 0x1c090d3f in tor_tls_handshake (tls=0x82987900) at tortls.c:936
legacy/trac#8 0x1c02b3e2 in connection_tls_continue_handshake (conn=0x84984900) at connection_or.c:629
legacy/trac#9 0x1c0219af in connection_read_to_buf (conn=0x84984900, max_to_read=0xcfbcce58) at connection.c:1950
legacy/trac#10 0x1c021338 in connection_handle_read (conn=0x84984900) at connection.c:1843
legacy/trac#11 0x1c04e990 in conn_read_callback (fd=181, event=2, _conn=0x84984900) at main.c:457
legacy/trac#12 0x0bcb6214 in event_process_active (base=0x839da1c0) at /usr/src/lib/libevent/event.c:317
legacy/trac#13 0x0bcb6482 in event_base_loop (base=0x839da1c0, flags=0) at /usr/src/lib/libevent/event.c:433
legacy/trac#14 0x0bcb631b in event_loop (flags=0) at /usr/src/lib/libevent/event.c:368
legacy/trac#15 0x1c050467 in do_main_loop () at main.c:1447
legacy/trac#16 0x1c0512c1 in tor_main (argc=3, argv=0xcfbccfe4) at main.c:1990
legacy/trac#17 0x1c07e7b7 in main (argc=3, argv=0xcfbccfe4) at tor_main.c:29
[Automatically added by flyspray2trac: Operating System: BSD]https://gitlab.torproject.org/tpo/core/tor/-/issues/833prefer canonical connections2020-06-27T14:10:09ZRoger Dingledineprefer canonical connectionsThis fix for checking prefer canonical connections even if that cases
looks as impossible.
helped in some cases against hypothetical situation which happened.
for two non-obsolete connections with a non-canonical newest one.
(currently ...This fix for checking prefer canonical connections even if that cases
looks as impossible.
helped in some cases against hypothetical situation which happened.
for two non-obsolete connections with a non-canonical newest one.
(currently for conns between 0.2.x and 0.1.2.x)
so it's cosmetic hypothetical fix for next future of old bugs.
--- connection_or.original.c Sat Jul 26 22:36:20 2008
+++ connection_or.c Tue Aug 19 09:38:30 2008
@@ -480,6 +480,8 @@
continue; /* We never prefer obsolete over non-obsolete connections. */
if (
+ /* We prefer canonical connections: */
+ (!best->is_canonical && conn->is_canonical) ||
/* We prefer non-obsolete connections: */
(best->_base.or_is_obsolete && !conn->_base.or_is_obsolete) ||
/* If both have circuits we prefer the newer: */
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/828native-connect sockaddr error2020-06-27T14:10:10ZTracnative-connect sockaddr errorI am running Tor in systrace v1.6d on OpenBSD 4.3
After an upgrade of Tor 0.1.2.19 to 0.2.0.30/31 a new policy appeared
native-connect: sockaddr eq "error" then permit
Apart from that, I get numerous messages on a terminal window:
sy...I am running Tor in systrace v1.6d on OpenBSD 4.3
After an upgrade of Tor 0.1.2.19 to 0.2.0.30/31 a new policy appeared
native-connect: sockaddr eq "error" then permit
Apart from that, I get numerous messages on a terminal window:
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
and so on. It makes it very hard to use the terminal because the error
messages come and go, often when you are in the middle of something. It
just makes it impossible to use. Unlike policy violations these errors
are not logged, they just scroll on screen.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: komohttps://gitlab.torproject.org/tpo/core/tor/-/issues/826tor-resolve can't adapt to SocksPort change2020-06-27T14:10:10ZTractor-resolve can't adapt to SocksPort changeOS: Ubuntu 8.04
TOR Version: 0.2.0.31-1~hardy+1
If the listening socks port changes in /etc/tor/torrc and /etc/tor/tor-tsocks.conf, i.e:
$ diff -ruN torrc torrc.bak
--- torrc.bak 2008-09-27 09:37:47.000000000 +0800
+++ torrc 2008-09-2...OS: Ubuntu 8.04
TOR Version: 0.2.0.31-1~hardy+1
If the listening socks port changes in /etc/tor/torrc and /etc/tor/tor-tsocks.conf, i.e:
$ diff -ruN torrc torrc.bak
--- torrc.bak 2008-09-27 09:37:47.000000000 +0800
+++ torrc 2008-09-27 09:39:48.000000000 +0800
@@ -18,1 +18,1 @@
-SocksPort 9050 # what port to open for local application connections
+SocksPort 9051 # what port to open for local application connections
$ diff -ruN tor-tsocks.conf.bak tor-tsocks.conf
--- tor-tsocks.conf.bak 2008-09-27 09:37:59.000000000 +0800
+++ tor-tsocks.conf 2008-09-27 09:40:53.000000000 +0800
@@ -7,1 +7,1 @@
-server_port = 9050
+server_port = 9051
tor-resolve will not work. Report this error:
$ tor-resolve www.google.com
Sep 27 09:46:41.704 [err] Error while connecting to SOCKS host: Connection refused
It seems tor-resolve does not read the configure files in /etc/tor. If I restore configure files to default, everything works OK.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: solrexhttps://gitlab.torproject.org/tpo/core/tor/-/issues/824More accurate calculation of bandwith limits in past.2020-06-27T14:10:10ZTracMore accurate calculation of bandwith limits in past.
Buckets decrements with raw bytes for OR connection which more than
real bytes. So global write bucket can and do run dry with negative
numbers, if Tor transmit cells.
Fix can repair possibly issue with DoS against relay with DirPort
...
Buckets decrements with raw bytes for OR connection which more than
real bytes. So global write bucket can and do run dry with negative
numbers, if Tor transmit cells.
Fix can repair possibly issue with DoS against relay with DirPort
reported by Scott Bennett on or-talk some time ago
(december '07 and later).
--- connection.original.c Mon Sep 8 13:10:16 2008
+++ connection.c Thu Sep 25 20:44:40 2008
@@ -1718,7 +1718,7 @@
tor_assert(seconds_elapsed >= 0);
write_buckets_empty_last_second =
- global_relayed_write_bucket == 0 || global_write_bucket == 0;
+ global_relayed_write_bucket <= 0 || global_write_bucket <= 0;
/* refill the global buckets */
connection_bucket_refill_helper(&global_read_bucket,
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/823r16621 introduced random stream detaching2020-06-27T14:10:10ZTracr16621 introduced random stream detachingWhen I use a relay of mine running a version later than r16621 as an exit to, for
example, http://upload.wikimedia.org/wikipedia/commons/7/79/Yellowjacket_nest_1_sjh.JPG
then the first few (between 3 and 100) times I try, the stream get...When I use a relay of mine running a version later than r16621 as an exit to, for
example, http://upload.wikimedia.org/wikipedia/commons/7/79/Yellowjacket_nest_1_sjh.JPG
then the first few (between 3 and 100) times I try, the stream gets DETACHED with reason=END and
remote_reason=unknown. Re-attaching the stream to another circuit works fine, and then
the stream succeeds. If I keep trying the same address through my relay a bunch of times,
it eventually succeeds. However, restarting my CLIENT Tor program (which I'm using to
test this, ie, not the relay), and trying again at the same address causes the same problem.
I narrowed down the problem to this block in eventdns.c:
/* we only bother with the first four addresses. */
if (j + 4*addrtocopy > length) goto err;
//if (name_matches) {
memcpy(&reply.data.a.addresses[reply.data.a.addrcount],
packet + j, 4*addrtocopy);
reply.data.a.addrcount += addrtocopy;
reply.have_answer = 1;
if (reply.data.a.addrcount == MAX_ADDRS) break;
//}
j += 4*addrtocopy;
Note that the // comments were added by me, and they actually fix this problem
(ie, the stream never detaches if those //'s are present, but the problem DOES
happen when they are NOT present). However, I dont understand this code at all,
so I figured I'd submit a bug report with what I've figured out so far, and see
what you guys think.
I printed out the names right after the assignment of name_matches in that function,
and the print statement was run twice for a single stream attach try. This is what
my tor log (level=debug) looked like:
launch_resolve(): Launching eventdns request for [scrubbed]
eventdns: Resolve requested.
eventdns: Setting timeout for request 3afe38
eventdns: req->name = upload.wikimedia.org and tmp_name = upload.wikimedia.org
eventdns: req->name = upload.wikimedia.org and tmp_name = upload.pmtpa.wikimedia.org
eventdns: Removing timeout for request 3afe38
Note that I'm running windows XP, compiling from source, and in case it matters,
my DNS server is 192.168.1.1, which is my router running DD-WRT
Hope this helps!
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: TheJashNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/820Tor left in broken state on startup2020-06-27T14:10:11ZseeessTor left in broken state on startupSep 21 20:05:21.660 [notice] Tor 0.2.1.5-alpha (r16710) opening log file.
Sep 21 20:05:21.661 [warn] /var/lib/tor/cached-status is not owned by this user (root, 0) but by username (1001). Perhaps you are running Tor as the wrong user?
Se...Sep 21 20:05:21.660 [notice] Tor 0.2.1.5-alpha (r16710) opening log file.
Sep 21 20:05:21.661 [warn] /var/lib/tor/cached-status is not owned by this user (root, 0) but by username (1001). Perhaps you are running Tor as the wrong user?
Sep 21 20:05:21.661 [warn] Couldn't access/create private data directory "/var/lib/tor/cached-status"
Sep 21 20:05:21.661 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying.
The directory initially wasnt owned by the correct user and it complained in system.out/err correctly so i could fix it,
but i forgot everything under it had the wrong perms too. But when i tried to start it the second time it just failed to launch
without anything significant printed out in system.out/err. I had to check the log for the above msg
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/814Fetching v0 and v2 rendezvous descriptors in parallel sometimes fails2020-06-27T14:10:11ZKarsten LoesingFetching v0 and v2 rendezvous descriptors in parallel sometimes failsThe logic to download v0 and v2 rendezvous descriptors in parallel does not
work correctly. If the v0 request returns first and unsuccessfully, the
hidden service connection is closed with the statement "[notice] Closing
stream for '[......The logic to download v0 and v2 rendezvous descriptors in parallel does not
work correctly. If the v0 request returns first and unsuccessfully, the
hidden service connection is closed with the statement "[notice] Closing
stream for '[...].onion': hidden service is unavailable (try again later)."
A subsequent successful result of a v2 request cannot be processed
correctly; while the descriptor is stored for later use, it cannot be used
for the requesting connection any more.
This is a minor problem, since hidden services that only publish v2
descriptors are still rare (unless people perform tests with them).
Patch follows.
[Automatically added by flyspray2trac: Operating System: All]Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/811can't open/start tor due to a bug2020-06-27T14:10:11ZTraccan't open/start tor due to a bugi can't open or start tor due to a bug. (Please note both od the bugs listed) I recently installed tor and can't seem to figure out why it says this:
Sep 06 19:04:09.948 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software...i can't open or start tor due to a bug. (Please note both od the bugs listed) I recently installed tor and can't seem to figure out why it says this:
Sep 06 19:04:09.948 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin Power Macintosh)
Sep 06 19:04:09.963 [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.
Sep 06 19:04:09.964 [Notice] Initialized libevent version 1.4.7-stable using method kqueue. Good.
Sep 06 19:04:09.965 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 06 19:04:09.966 [Notice] Opening Directory listener on 0.0.0.0:9030
Sep 06 19:04:09.967 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 06 19:04:09.967 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 06 19:04:11.640 [Notice] Your Tor server's identity key fingerprint is 'Unnamed E0FD F8F7 6A06 4AF1 3B2A CAD7 C323 CB8D 1FC2 1468'
Sep 06 19:04:11.648 [Error] Bug: policies.c:1230: addr_policy_free: Assertion p == found->policy failed; aborting.
Sep 06 22:35:36.885 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin Power Macintosh)
Sep 06 22:35:36.891 [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.
Sep 06 22:35:36.892 [Notice] Initialized libevent version 1.4.7-stable using method kqueue. Good.
Sep 06 22:35:36.893 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 06 22:35:36.894 [Notice] Opening Directory listener on 0.0.0.0:9030
Sep 06 22:35:36.895 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 06 22:35:36.896 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 06 22:35:38.614 [Notice] Your Tor server's identity key fingerprint is 'Unnamed E0FD F8F7 6A06 4AF1 3B2A CAD7 C323 CB8D 1FC2 1468'
Sep 06 22:35:38.616 [Error] Bug: policies.c:1230: addr_policy_free: Assertion p == found->policy failed; aborting.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ecoteahttps://gitlab.torproject.org/tpo/core/tor/-/issues/809Tor 0.2.1.5-alpha rejects valid bridge addresses2020-06-27T14:10:11ZedmanmTor 0.2.1.5-alpha rejects valid bridge addressesTor 0.2.1.5-alpha rejects what appear to be properly formatted bridge addresses. For example, placing
the following line in my torrc:
bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
results in the following ...Tor 0.2.1.5-alpha rejects what appear to be properly formatted bridge addresses. For example, placing
the following line in my torrc:
bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
results in the following error:
Sep 04 15:47:35.887 [warn] Missing port in Bridge address '128.31.0.34:9009'
even though a port is indeed specified.
[I selected 0.2.1.4-alpha for the "Reported Version", because 0.2.1.5-alpha is not currently in the list.]
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/807Stream status events for reverse resolve requests2020-06-27T14:10:12ZRobert HoganStream status events for reverse resolve requests(http://archives.seul.org/or/dev/Jul-2008/msg00017.html)
Stream status events for reverse resolve requests for which Tor has a cached
answer look like this:
650 STREAM 6 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 6 FAILED 0 REVERSE[64.4.33.7...(http://archives.seul.org/or/dev/Jul-2008/msg00017.html)
Stream status events for reverse resolve requests for which Tor has a cached
answer look like this:
650 STREAM 6 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 6 FAILED 0 REVERSE[64.4.33.7]:0
650 STREAM 7 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 7 FAILED 0 REVERSE[64.4.33.7]:0
The stream 'fails' because there is never a need to create it. The spec is a bit
unclear on this point but I think all streams deserve a CLOSE event. Or
is 'FAILED' considered sufficient?
I can allow a CLOSE event by doing:
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 15824)
+++ src/or/connection_edge.c (working copy)
@@ -1369,8 +1369,7 @@
map_expires);
connection_mark_unattached_ap(conn,
END_STREAM_REASON_DONE |
- END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED |
- END_STREAM_REASON_FLAG_ALREADY_SENT_CLOSED);
+ END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED);
return 0;
}
if (options->ClientDNSRejectInternalAddresses) {
but maybe it's the spec that needs to be clarified. A short note stating which
events should be expected for all streams maybe.
See also:
http://archives.seul.org/or/dev/Jul-2008/msg00033.html
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/806error during build on ming322020-06-27T14:10:12ZAndrew Lewmanerror during build on ming32When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I...When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include -g -O2 -Wall -g -O2 -MT config.o -MD -MP -MF .deps/config.Tpo -c -o config.o config.c
config.c: In function `options_act':
config.c:1268: warning: initialization makes integer from pointer without a cast
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/804seg fault on r16563 v3 authority2020-06-27T14:10:12ZRoger Dingledineseg fault on r16563 v3 authoritymoria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () ...moria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () from /lib/libc.so.6
#1 0x00002b93dfb07560 in vfprintf () from /lib/libc.so.6
legacy/trac#2 0x00002b93dfb276fa in vsnprintf () from /lib/libc.so.6
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
legacy/trac#4 0x0000000000496481 in tor_snprintf (
str=0x2b9300002b93 <Address 0x2b9300002b93 out of bounds>, size=4981567,
format=0x7fffcb8f0201 "3\v\002") at compat.c:321
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
legacy/trac#6 0x000000000044ec11 in dirvote_act (options=0x5faf00, now=1218934501)
at dirvote.c:1907
legacy/trac#7 0x0000000000459213 in second_elapsed_callback (fd=<value optimized out>,
event=<value optimized out>, args=<value optimized out>) at main.c:1067
legacy/trac#8 0x00002b93df3e90e2 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x00000000004599f8 in do_main_loop () at main.c:1459
legacy/trac#10 0x0000000000459b95 in tor_main (argc=3, argv=<value optimized out>)
at main.c:2025
legacy/trac#11 0x00002b93dfadf4ca in __libc_start_main () from /lib/libc.so.6
legacy/trac#12 0x0000000000406b0a in _start () at ../sysdeps/x86_64/elf/start.S:113
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
340 r = vsnprintf(str, size, format, args);
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
1049 int r = tor_snprintf(buf, sizeof(buf), "p %s\n", rs_out.exitsummary);
(gdb) print buf
$7 = 6401584
(gdb) print sizeof(buf)
$8 = 4
(gdb) print rs_out
No symbol "rs_out" in current context.
(another victim of optimization i guess)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/803assert in routerstatus_format_entry()2020-06-27T14:10:12ZRoger Dingledineassert in routerstatus_format_entry()r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the de...r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the descript
or with digest 009CF1422D2244E918B4530A673871D46009B752 for 5193811E81189B705618
C7DB16BE3B48170C2800.
Aug 16 19:33:57.208 [] routerstatus_format_entry(): Bug: descriptor digest in ro
uterlist does not match the one in routerstatus: 33503E7B5447030D4289F465F2BD0A0
44781B34E vs 78DB41D7DAA1B80572FB422E789FBDBCEF456C68
Aug 16 19:33:57.212 [] Bug: dirserv.c:1966: routerstatus_format_entry: Assertion
!memcmp(desc->cache_info.signed_descriptor_digest, rs->descriptor_digest, DIGES
T_LEN) failed; aborting.
#0 0xb7fd1410 in ?? ()
#1 0xbfe9327c in ?? ()
legacy/trac#2 0x00000006 in ?? ()
legacy/trac#3 0x00001144 in ?? ()
legacy/trac#4 0xb7d01811 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#5 0xb7d02fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
legacy/trac#7 0x080ab8da in networkstatus_getinfo_helper_single (rs=0x88f9918)
at networkstatus.c:1782
legacy/trac#8 0x080ad1e7 in getinfo_helper_networkstatus (conn=0x8663de0,
question=0x8170880 "ns/all", answer=0xbfe93be0) at networkstatus.c:1862
legacy/trac#9 0x08086535 in connection_control_process_inbuf (conn=0x8663de0)
at control.c:1976
legacy/trac#10 0x08070c68 in connection_process_inbuf (conn=0x8663de0, package_partial=6)
at connection.c:2733
legacy/trac#11 0x080729b1 in connection_handle_read (conn=0x8663de0) at connection.c:1931
legacy/trac#12 0x080ab5c8 in conn_read_callback (fd=10, event=2, _conn=0x8663de0)
at main.c:458
legacy/trac#13 0xb7f9cc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#14 0xb7f9cf65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#15 0xb7f9cdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#16 0x080ab10f in do_main_loop () at main.c:1459
legacy/trac#17 0x080ab2e5 in tor_main (argc=11, argv=0xbfe93e64) at main.c:2025
legacy/trac#18 0x080e5b92 in main (argc=Cannot access memory at address 0x1144
) at tor_main.c:29
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
1964 tor_assert(!memcmp(desc->cache_info.signed_descriptor_digest,
(gdb) print *rs
$4 = {published_on = 1218917681, nickname = "agate", '\0' <repeats 14 times>,
identity_digest = "\0014\f\214ß!^\220¹Ôÿ\032ëܤ\003Í/öåb",
descriptor_digest = "xÛA×Ú¡¸\005rûB.x\237½¼ïElh", addr = 3251270624,
or_port = 9001, dir_port = 0, is_authority = 0, is_exit = 0, is_stable = 0,
is_fast = 0, is_running = 1, is_named = 0, is_unnamed = 1, is_valid = 1,
is_v2_dir = 0, is_possible_guard = 0, is_bad_exit = 0, is_bad_directory = 0,
is_hs_dir = 0, version_known = 1, version_supports_begindir = 1,
version_supports_conditional_consensus = 0,
version_supports_extrainfo_upload = 1, version_supports_v3_dir = 1,
has_bandwidth = 0, has_exitsummary = 0, bandwidth = 0, exitsummary = 0x0,
need_to_mirror = 0, name_lookup_warned = 0, last_dir_503_at = 0,
dl_status = {next_attempt_at = 0, n_download_failures = 0 '\0',
schedule = DL_SCHED_GENERIC}}
(gdb) print desc
No symbol "desc" in current context.
(darn optimizer)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/802BandwidthBurst rate being used constantly2020-06-27T14:10:12Zmicahmicah@torproject.orgBandwidthBurst rate being used constantlyI have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year an...I have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year and a half.
I installed tor on one of the nodes to test an exit enclave setup, with the idea that if it worked well, I would deploy it
to the other nodes (as well as elsewhere). I used the following configuration:
SocksPort 0 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
Nickname auk
Address my.ip.here
OutboundBindAddress my.ip.here
ContactInfo my.contact.info.here
ORPort 9001
ExitPolicyRejectPrivate 0
ExitPolicy accept my.ip.here:80
ExitPolicy accept my.ip.here:443
ExitPolicy reject *:*
BandwidthRate 250 KB
BandwidthBurst 1MB
As you can see, I set BandwidthBurst to 1MB, and BadwidthRate to be 250KB, but looking at my bandwidth usage
statistics, I see that this node is using 1MB the entire time, averaging 872kbps in and 1.03M out (almost always at
this rate, with some fluctuations up to 2.35M in and 2.71M out.
This doesn't seem like what I would expect for these bandwidth settings, I could be misunderstanding how these
are applied, and if so please tell me what I am missing.
Thanks for your work on tor, its appreciated!
[Automatically added by flyspray2trac: Operating System: Other Linux]