Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:19Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/681encrypted dir conns confuse LeaveStreamsUnattached2020-06-27T14:10:19ZRoger Dingledineencrypted dir conns confuse LeaveStreamsUnattached(This is Mikeperry's bug)
When we launch an encrypted dir conn in directory.c via
connection_ap_make_link(), it'll put the stream in state
AP_CONN_STATE_CIRCUIT_WAIT. This means that even controllers
that set LeaveStreamsUnattached won'...(This is Mikeperry's bug)
When we launch an encrypted dir conn in directory.c via
connection_ap_make_link(), it'll put the stream in state
AP_CONN_STATE_CIRCUIT_WAIT. This means that even controllers
that set LeaveStreamsUnattached won't need to handle it,
since it's already being handled.
Bug #1: controllers don't know this, and can't distinguish
streams that are already being handled. Mike had a patch to
put an extra flag on the stream status line.
Bug legacy/trac#2: then if the stream causes a circuit to get created, and gets
attached to that circuit, but the circuit times out or otherwise
fails to fulfill the request, the stream will be handled by
connection_ap_detach_retriable() which will set it to state
AP_CONN_STATE_CONTROLLER_WAIT. And the controller doesn't realize
that this time it's supposed to handle it (and it probably shouldn't
need to handle it)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/678man page entries for RejectPlaintextPorts and WarnPlaintextPorts2020-06-27T14:10:19ZRoger Dingledineman page entries for RejectPlaintextPorts and WarnPlaintextPortswe're missing man page entries for those two config options.
[Automatically added by flyspray2trac: Operating System: All]we're missing man page entries for those two config options.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/672[warn] Still had some address policies cached at shutdown.2020-06-27T14:10:19ZRoger Dingledine[warn] Still had some address policies cached at shutdown.Apr 23 14:40:08.135 [notice] Clean shutdown finished. Exiting.
Apr 23 14:40:08.765 [warn] Still had some address policies cached at shutdown.
This happens consistently on moria1 (running 0.2.0.24-rc) and moria2 (running
0.2.1.0-alpha...Apr 23 14:40:08.135 [notice] Clean shutdown finished. Exiting.
Apr 23 14:40:08.765 [warn] Still had some address policies cached at shutdown.
This happens consistently on moria1 (running 0.2.0.24-rc) and moria2 (running
0.2.1.0-alpha-dev (r14424)).
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/671tor 0.2.0.24-rc: mutex initialization problem?2020-06-27T14:10:20ZTractor 0.2.0.24-rc: mutex initialization problem?This bug report actually applies only to 0.2.0.24-rc (the field was not
available yet in the Version entry above.) This version of tor cannot now
be built on FreeBSD 7-STABLE i386 with multithreading support. The resulting
binary du...This bug report actually applies only to 0.2.0.24-rc (the field was not
available yet in the Version entry above.) This version of tor cannot now
be built on FreeBSD 7-STABLE i386 with multithreading support. The resulting
binary dumps core. I believe the error is related to problems with the
initialization of the recursive mutexes introduced for logging in the new
version of tor. Pthreads in this version of FreeBSD are handled in libthr,
and the pertinent libraries are supposed to be POSIX compliant. (See
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libthr .) A backtrace of crashes
of the test program run during "make check" and of the tor binary:
#0 0x2838129b in pthread_mutexattr_init () from /lib/libthr.so.3
#1 0x2838141b in pthread_mutex_init () from /lib/libthr.so.3
legacy/trac#2 0x0810f835 in tor_mutex_new () at compat.c:1756
legacy/trac#3 0x08108b84 in init_logging () at log.c:498
legacy/trac#4 0x0810f4b0 in main (c=1 v=Cannot access memory at address 0x4
) at test.c:3564
#0 0x2835029b in pthread_mutexattr_init () from /lib/libthr.so.3
#1 0x2835041b in pthread_mutex_init () from /lib/libthr.so.3
legacy/trac#2 0x080e9f45 in tor_mutex_new () at compat.c:1756
legacy/trac#3 0x080e3294 in init_logging () at log.c:498
legacy/trac#4 0x080aae7c in tor_main (argc=1 argv=0xbfbfeaa4) at min.c:1968
legacy/trac#5 0x080e2982 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:29
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jmurphy0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/669Clients don't realize that a server has a different identity than stated in c...2020-06-27T14:10:20ZKarsten LoesingClients don't realize that a server has a different identity than stated in consensusThis problem came up when trying to access a hidden service on a "recent"
trunk version (0.2.1.0-alpha-dev, exact revision number unknown). Log by
killerchicken (times manually changed to GMT):
Apr 20 20:33:04.853 [Warning] Received NET...This problem came up when trying to access a hidden service on a "recent"
trunk version (0.2.1.0-alpha-dev, exact revision number unknown). Log by
killerchicken (times manually changed to GMT):
Apr 20 20:33:04.853 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 1 hours,
42 minutes, or that theirs is behind. Tor requires an accurate clock to
work: please check your time and date settings.
Apr 20 20:33:29.545 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:34.959 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.914 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.967 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.984 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
...
Apr 20 20:34:57.817 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:35:03.500 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:35:16.144 [Notice] Rend stream is 120 seconds late. Giving up on
address '[scrubbed].onion'.
Apr 20 20:37:16.783 [Notice] Rend stream is 120 seconds late. Giving up on
address '[scrubbed].onion'.
The server with identity CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 is
HALLIGonALB which has changed identity keys just before the consensus was
created. At 19:18:44 the server indeed had the identity CCFDBED5..., but
it changed to FDD88040... at 19:50:57:
router HALLIGonALB 91.89.159.76 9001 0 0
platform Tor 0.2.0.23-rc (r14173) on Linux i686
opt protocols Link 1 Circuit 1
published 2008-04-20 19:18:44
opt fingerprint CCFD BED5 463B 7F30 8C0E F909 F00B 2588 9F6A 7EF8
router HALLIGonALB 91.89.159.76 9001 0 9030
platform Tor 0.2.0.23-rc (r14173) on Linux i686
opt protocols Link 1 Circuit 1
published 2008-04-20 19:50:57
opt fingerprint FDD8 8040 C0C9 8EE9 EB57 3041 A2C8 824E 9EFC 4CE4
The server is listed in the consensus as:
r HALLIGonALB zP2+1UY7fzCMDvkJ8AsliJ9qfvg UcgjQHY3+4ftvO7CXn4DJ9v9TkY
2008-04-20 19:21:44 91.89.159.76 9001 9030
The bug here is that clients should stop creating connections to nodes that
have "lied" about their identity before. The warning message comes from
connection_or.c:789 in connection_or_check_valid_tls_handshake().
Attempts to reproduce this error by (1) always failing the condition in
connection_or.c:782 or (2) failing after 2 attempts by introducing a static
counter (rationale: the third connection attempt will be the first when
actually trying to access a hidden service) failed. In all cases the
"failing" nodes were correctly removed from the entry guards list and
marked as down.
When this bug will be spotted again, an info-level or even debug-level log
might help in understanding what happens in detail.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/663netinfo clock skew warn too loud2020-06-27T14:10:20ZRoger Dingledinenetinfo clock skew warn too loudkeb> ok i got another of these with Tor 0.2.0.23-rc (running as client only)
: Apr 17 12:52:19.184 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 2 hours, 15
minutes...keb> ok i got another of these with Tor 0.2.0.23-rc (running as client only)
: Apr 17 12:52:19.184 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 2 hours, 15
minutes, or that theirs is behind. Tor requires an accurate clock to work:
please check your time and date settings.
We only complain about skew for directory requests when
int trusted = router_digest_is_trusted_dir(conn->identity_digest);
Perhaps we should do something similar for clients looking at netinfo cells?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/656Tor server crash in SSL_free with DH crypto error in logs2020-06-27T14:10:21ZMike PerryTor server crash in SSL_free with DH crypto error in logsJust got a crash in r14173. Have a warn in the log right before:
Apr 12 12:30:19.323 [warn] crypto error while generating DH key: BN lib (in Diff
ie-Hellman routines:GENERATE_KEY).
Here is the backtrace of the thread that caused the cr...Just got a crash in r14173. Have a warn in the log right before:
Apr 12 12:30:19.323 [warn] crypto error while generating DH key: BN lib (in Diff
ie-Hellman routines:GENERATE_KEY).
Here is the backtrace of the thread that caused the crash:
#0 0x4cef366c in EVP_CIPHER_CTX_cleanup () from /lib/libcrypto.so.6
#1 0x4cfc4f35 in ssl_clear_cipher_ctx () from /lib/libssl.so.6
legacy/trac#2 0x4cfc6ab5 in SSL_free () from /lib/libssl.so.6
legacy/trac#3 0x080f335c in tor_tls_free (tls=0x40df1ac0) at tortls.c:831
legacy/trac#4 0x0806d2eb in _connection_free (conn=0x46229f00) at connection.c:328
legacy/trac#5 0x080a363c in connection_unlink (conn=0x46229f00) at main.c:212
legacy/trac#6 0x080a390e in close_closeable_connections () at main.c:603
legacy/trac#7 0x4cfe4125 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0x4cfe4349 in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x080a5149 in do_main_loop () at main.c:1446
legacy/trac#10 0x080a52fb in tor_main (argc=3, argv=0x59c9d5c4) at main.c:1986
legacy/trac#11 0x080d9ee2 in main (argc=Cannot access memory at address 0x0
The cpuworker thread was in the process of spitting out another
(or perhaps just finished the original?) warn:
#0 0x4cffe402 in __kernel_vsyscall ()
#1 0x4cdcbf7b in write () from /lib/libc.so.6
legacy/trac#2 0x4cd6d884 in _IO_new_file_write () from /lib/libc.so.6
legacy/trac#3 0x4cd6d545 in new_do_write () from /lib/libc.so.6
legacy/trac#4 0x4cd6d82f in _IO_new_do_write () from /lib/libc.so.6
legacy/trac#5 0x4cd6e006 in _IO_new_file_sync () from /lib/libc.so.6
legacy/trac#6 0x4cd62c3c in fflush () from /lib/libc.so.6
legacy/trac#7 0x080daaa7 in logv (severity=4, domain=2, funcname=0x0,
format=0x8124004 "crypto error while %s: %s (in %s:%s)",
ap=0x4aaa6eec "°<\022\baáõLÄßõL>ÀõLàV¾4\200") at log.c:295
legacy/trac#8 0x080dad0e in _log (severity=4, domain=2,
format=0x8124004 "crypto error while %s: %s (in %s:%s)") at log.c:314
legacy/trac#9 0x080eb1a7 in crypto_log_errors (severity=4,
doing=0x8123cb0 "generating DH key") at crypto.c:146
legacy/trac#10 0x080ec104 in crypto_dh_generate_public (dh=0x34be56e0) at crypto.c:1467
legacy/trac#11 0x080ec31b in crypto_dh_get_public (scrubbed) at crypto.c:1492
legacy/trac#12 0x080a9e7e in onion_skin_server_handshake (scrubbed)
at onion.c:267
legacy/trac#13 0x08083a70 in cpuworker_main (data=0x4c2f2090) at cpuworker.c:284
legacy/trac#14 0x080e11ed in tor_pthread_helper_fn (_data=0x4c2f20a0) at compat.c:1482
legacy/trac#15 0x4ce5745b in start_thread () from /lib/libpthread.so.0
legacy/trac#16 0x4cddb24e in clone () from /lib/libc.so.6
Unfortunately the logs were at notice. The node had just started, not much else was present.
I'm rerunning it at info.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/651assert in refetching v2 rend desc2020-06-27T14:10:21ZRoger Dingledineassert in refetching v2 rend descReported by nwf on irc:
650 DEBUG conn_read_callback(): socket 7 wants to read.
650 DEBUG connection_handle_listener_read(): Connection accepted on socket 10 (child of fd 7).
650 DEBUG connection_add(): new conn type Socks, socket 10, n...Reported by nwf on irc:
650 DEBUG conn_read_callback(): socket 7 wants to read.
650 DEBUG connection_handle_listener_read(): Connection accepted on socket 10 (child of fd 7).
650 DEBUG connection_add(): new conn type Socks, socket 10, n_conns 6.
650 DEBUG conn_read_callback(): socket 10 wants to read.
650 DEBUG read_to_chunk(): Read 41 bytes. 41 on inbuf.
650 DEBUG connection_ap_handshake_process_socks(): entered.
650 DEBUG fetch_from_buf_socks(): socks4: Everything is here. Success.
650 STREAM 2 NEW 0 eqt5g4fuenphqinx.onion:80 SOURCE_ADDR=127.0.0.1:34547
650 DEBUG connection_ap_handshake_rewrite_and_attach(): Client asked for eqt5g4fuenphqinx.onion:80
650 INFO connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'eqt5g4fuenphqinx'
650 INFO connection_ap_handshake_rewrite_and_attach(): Unknown descriptor eqt5g4fuenphqinx. Fetching.
650 DEBUG rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service eqt5g4fuenphqinx
650 DEBUG directory_initiate_command(): anonymized 1, use_begindir 1.
650 DEBUG directory_initiate_command(): Initiating hidden-service v2 descriptor fetch
650 INFO connection_ap_make_link(): Making internal anonymized tunnel to 192.251.226.205:443 ...
650 DEBUG connection_add(): new conn type Socks, socket -1, n_conns 7.
650 STREAM 3 NEW 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 SOURCE_ADDR=(Tor_internal):0
650 WARN Requested exit point '$5C3EC3DC1CD0E64016BA7C6ED308C98379645967' is not known. Closing.
650 STREAM 3 FAILED 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 REASON=CANT_ATTACH
650 WARN Making tunnel to dirserver failed.
650 INFO directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'eqt5g4fuenphqinx' with descriptor ID 'pejeujtytbl2uiuya6ixtcgmii5qgv46' to hidden service directory 'blutmagie' on port 80.
650 INFO rend_client_refetch_renddesc(): Fetching rendezvous descriptor for service "eqt5g4fuenphqinx"
650 DEBUG directory_initiate_command(): anonymized 1, use_begindir 1.
650 DEBUG directory_initiate_command(): Initiating hidden-service descriptor fetch
650 INFO connection_ap_make_link(): Making internal anonymized tunnel to 86.59.21.38:443 ...
650 DEBUG connection_add(): new conn type Socks, socket -1, n_conns 8.
650 STREAM 4 NEW 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 SOURCE_ADDR=(Tor_internal):0
650 WARN Requested exit point '$847B1F850344D7876491A54892F904934E4EB85D' is not known. Closing.
650 STREAM 4 FAILED 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 REASON=CANT_ATTACH
650 WARN Making tunnel to dirserver failed.
650 INFO connection_edge_process_inbuf(): data from edge while in 'waiting for rendezvous desc' state. Leaving it on buffer.
650 DEBUG conn_close_if_marked(): Cleaning up connection (fd -1).
650 STREAM 3 CLOSED 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 REASON=CANT_ATTACH
650 DEBUG connection_remove(): removing socket -1 (type Socks), n_conns now 8
650 INFO _connection_free(): Freeing linked Socks connection [waiting for circuit] with 0 bytes on inbuf, 0 on outbuf.
650+NS
r tor26 hHsfhQNE14dkkaVIkvkEk05OuF0 K9cFUCJz2k01fxgI9/CgaOzaID0 2008-04-01 23:36:04 86.59.21.38 443 80
s Authority Fast Named Stable V2Dir Valid
.
650 OK
650 DEBUG conn_close_if_marked(): Cleaning up connection (fd -1).
650 STREAM 4 CLOSED 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 REASON=CANT_ATTACH
650 DEBUG connection_remove(): removing socket -1 (type Socks), n_conns now 7
650 INFO _connection_free(): Freeing linked Socks connection [waiting for circuit] with 0 bytes on inbuf, 0 on outbuf.
650+NS
r blutmagie XD7D3BzQ5kAWunxu0wjJg3lkWWc IKLuwxRgB/abDds0UHeo0MSZQIk 2008-04-02 10:40:23 192.251.226.205 443 80
s Exit Fast Guard HSDir Stable Unnamed V2Dir Valid
.
650 OK
650 ERR Bug: rendclient.c:426: rend_client_refetch_v2_renddesc: Assertion strlen(query) == REND_SERVICE_ID_LEN_BASE32 failed; aborting.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/649When installing the Tor Bundle on OS X, Torbutton will not be installed into ...2020-06-27T14:10:21ZSebastian HahnWhen installing the Tor Bundle on OS X, Torbutton will not be installed into FirefoxI downloaded https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.0.23-rc-0.1.2-tiger.dmg and installed onto a clean OS X and Firefox install. Torbutton will not install, but its files are placed into /Library/Torbutton.
I...I downloaded https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.0.23-rc-0.1.2-tiger.dmg and installed onto a clean OS X and Firefox install. Torbutton will not install, but its files are placed into /Library/Torbutton.
Is it possible this has been introduced by r14238?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/648No available nodes after network outage2020-06-27T14:10:22ZTracNo available nodes after network outageActually, it's 23-rc, but the version dropdown box doesn't have the option!
After the dial-up network has gone down for any appreciable time, when it is brought back up I lose the Tor network
and my log file gets filled with:
Tor[4292...Actually, it's 23-rc, but the version dropdown box doesn't have the option!
After the dial-up network has gone down for any appreciable time, when it is brought back up I lose the Tor network
and my log file gets filled with:
Tor[4292]: Failed to find node for hop 0 of our path. Discarding this circuit.
Tor[4292]: No available nodes when trying to choose node. Failing.
It can only be remedied by restarting Tor, whereupon it creates circuits just fine.
I'm wondering if it's because the external IP address has changed but Tor hasn't noticed? If so, can Tor try to
figure out if the external IP address has changed when it encounters this error and reconfigure itself?
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandude0.2.0.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/622Tor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket ...2020-06-27T14:10:23ZTracTor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket 340 wants to read.I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] co...I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] conn_read_callback(): socket 34 wants to read.
Around 21000 of these per second.
This lasted for several minutes.
Tor started hahaving OK all by itself before I had time to do much, except for oprofile,
but this would probably be obvious also from the debug line.
CPU: P4 / Xeon, speed 2797.2 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 240000
Counted MACHINE_CLEAR events (cycles with entire machine pipeline cleared) with a unit mask of 0x01 (count a portion of cycles the machine is cleared for any cause) count 12000
Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 60000
Counted RETIRED_BRANCH_TYPE events (retired branches, selected by type) with a unit mask of 0x1f (multiple flags) count 180000
Counted RETIRED_MISPRED_BRANCH_TYPE events (retired mispredicted branched, selected by type) with a unit mask of 0x1f (multiple flags) count 6000
samples % samples % samples % samples % samples % image name symbol name
18142 10.9848 194 11.7150 40 2.1882 3891 11.3477 4608 24.4158 tor-0.2.1.0-r13924 connection_handle_read
18020 10.9109 164 9.9034 26 1.4223 4022 11.7297 3166 16.7753 tor-0.2.1.0-r13924 conn_read_callback
17185 10.4053 180 10.8696 38 2.0788 6272 18.2916 123 0.6517 tor-0.2.1.0-r13924 assert_connection_ok
12498 7.5674 95 5.7367 9 0.4923 1734 5.0570 72 0.3815 tor-0.2.1.0-r13924 tor_tls_get_error
11508 6.9680 94 5.6763 48 2.6258 3249 9.4753 46 0.2437 tor-0.2.1.0-r13924 assert_buf_ok
10444 6.3237 106 6.4010 23 1.2582 2296 6.6960 551 2.9195 tor-0.2.1.0-r13924 _openssl_locking_cb
9895 5.9913 83 5.0121 11 0.6018 1535 4.4767 38 0.2013 tor-0.2.1.0-r13924 connection_bucket_round_robin
9292 5.6262 89 5.3744 3 0.1641 1694 4.9404 3047 16.1448 tor-0.2.1.0-r13924 tor_tls_renegotiate
8628 5.2242 99 5.9783 17 0.9300 879 2.5635 166 0.8796 [vdso] (tgid:19150 range:0x7fffe7ffe000-0x7fffe8000000) (no symbols)
6003 3.6347 60 3.6232 16 0.8753 184 0.5366 6 0.0318 tor-0.2.1.0-r13924 buf_datalen
4633 2.8052 64 3.8647 751 41.0832 330 0.9624 27 0.1431 tor-0.2.1.0-r13924 router_get_by_nickname
4375 2.6490 41 2.4758 3 0.1641 775 2.2602 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_acquire
4128 2.4995 39 2.3551 3 0.1641 267 0.7787 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_release
4103 2.4843 40 2.4155 0 0 771 2.2485 4500 23.8436 tor-0.2.1.0-r13924 connection_tls_continue_handshake
2698 1.6336 33 1.9928 8 0.4376 511 1.4903 11 0.0583 tor-0.2.1.0-r13924 connection_process_inbuf
2303 1.3944 38 2.2947 7 0.3829 1113 3.2459 15 0.0795 tor-0.2.1.0-r13924 tor_addr_is_internal
2068 1.2521 18 1.0870 4 0.2188 484 1.4115 12 0.0636 tor-0.2.1.0-r13924 connection_is_listener
1699 1.0287 16 0.9662 48 2.6258 102 0.2975 65 0.3444 tor-0.2.1.0-r13924 rijndaelEncrypt
1618 0.9797 14 0.8454 8 0.4376 598 1.7440 6 0.0318 tor-0.2.1.0-r13924 connection_counts_as_relayed_traffic
1615 0.9779 15 0.9058 5 0.2735 151 0.4404 82 0.4345 tor-0.2.1.0-r13924 logv
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safari0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/619exit-policy-reject-star relays should refuse dns?2020-06-27T14:10:24ZRoger Dingledineexit-policy-reject-star relays should refuse dns?lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forc...lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forced to do. "also permit reverse resolve for private
addresses, which could lead to leaks of names, in normal circumstances,
only available locally."
Here's his patch:
--- dns.c Tue Feb 26 19:56:28 2008
+++ dns.c Sat Mar 8 12:11:34 2008
@@ -550,7 +550,12 @@
char *hostname = NULL;
is_resolve = exitconn->_base.purpose == EXIT_PURPOSE_RESOLVE;
- r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
+ routerinfo_t *me = router_get_my_routerinfo();
+ if (is_resolve && me &&
+ policy_is_reject_star(me->exit_policy)) /* non-exit */
+ r = -1;
+ else
+ r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
switch (r) {
case 1:
/* We got an answer without a lookup -- either the answer was
@@ -659,9 +664,12 @@
* .in-addr.arpa address but this isn't a resolve request, kill the
* connection.
*/
- if ((r = parse_inaddr_arpa_address(exitconn->_base.address, NULL)) != 0) {
- if (r == 1)
+ if ((r = parse_inaddr_arpa_address(exitconn->_base.address, &in)) != 0) {
+ if (r == 1) {
is_reverse = 1;
+ if (is_internal_IP(ntohl(in.s_addr), 0)) /* internal address */
+ return -1;
+ }
if (!is_reverse || !is_resolve) {
if (!is_reverse)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/612tor needs to perform a dir request whenever starting as a server?2020-06-27T14:10:24ZRobert Hogantor needs to perform a dir request whenever starting as a server?[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it ou...[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it out from hostname, then finds the internal address, then says neither of those will do and gives up
[12:02] <mwenge> because it gets nothing from router_pick_published_address it doesn't get past go in router_rebuild_descriptor
[12:02] <mwenge> this results in it failing to assign desc_routerinfo
[12:02] <mwenge> so if i then do a getinfo dir/server/fp/ on my own server fingerprint - I get a segfault
[12:03] <mwenge> because desc_routerinfo doesn't exist and tor's assuming one exists
[12:03] <mwenge> this solves the segfault: http://pastebin.ca/914977
[12:04] <mwenge> but the real problem is failing to guess the ip
[12:05] <mwenge> it can only have been introduced recently because i generally use trunk
[12:10] <mwenge> the real problem is probably in router_guess_address_from_dir_headers somewhere
[12:16] <karsten> mwenge: sry, looking at the commit statements did not reveal (to me) which one changed that behavior.
[12:17] <mwenge> karsten: same here. i think i see the problem. if tor starts and has relatively fresh server info cached it doesn't get an ip from the dir servers until the next time it requests something
[12:17] <mwenge> so last_guessed_ip remains 0. and if you run a server your address remains undetermined
[12:20] <mwenge> so it looks as if tor needs to perform a dir request when starting at all times
[12:20] <mwenge> or else cache x-your-address on file - which seems a bad idea
[12:22] <mwenge> yup. rm -rf cache- and restarting tor gets last_guessed_ip populated again
[12:22] <mwenge> just restarting tor with clearing the cache results it in remaining 0
sorry for the straight paste - i'm lazy
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/607INFO logging is a bit noisy.2020-06-27T14:10:25ZNick MathewsonINFO logging is a bit noisy.Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were i...Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were in old_routers); %d would_reject; %d wouldnt_use, %d in progress.
1102 info] routerlist_remove_old_routers(): We have %d live routers and %d old router descriptors. At most %d must be retained because of networkstatuses.
1318 info] update_extrainfo_downloads(): Extrainfo download status: %d router with no ei, %d with present ei, %d delaying, %d pending, %d downloadable.
1691 info] connection_close_immediate(): fd %d, type %s, state %s, %d bytes on outbuf.
1787 info] run_connection_housekeeping(): Expiring non-used OR connection to fd %d (%s:%d) [Not in clique mode].
2103 info] directory_handle_command_get(): Client asked for network status lists, but we've been writing too many bytes lately. Sending 503 Dir busy.
5037 info] entry_guards_compute_status(): Summary: Entry '%s' is %s, %s%s, and %s.
10352 info] directory_handle_command_get(): Client asked for server descriptors, but we've been writing too many bytes lately. Sending 503 Dir busy.
12993 info] circuit_extend(): Next router (%s:%d) not connected. Connecting.
15849 info] connection_read_to_buf(): tls error [%s]. breaking (nickname %s, address %s).
This is out of around 60k messages of severity INFO or higher; the top 4 account for 3/4 of all log messages.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/601tor ignores ExitNodes even when StrictExitNodes is set2020-06-27T14:10:26ZTractor ignores ExitNodes even when StrictExitNodes is setwin xp sp2, vidalia bundle 0.0.16, tor v0.1.2.19
log shows chosen exits not from the ExitNodes list
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: iarwin xp sp2, vidalia bundle 0.0.16, tor v0.1.2.19
log shows chosen exits not from the ExitNodes list
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: iar0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/600circuitlist.c:1165 crashing bug2020-06-27T14:10:26Zshamrockcircuitlist.c:1165 crashing bugThe Tonga tor server crashed with:
Feb 04 10:20:36.880 [err] Bug: circuitlist.c:1165: assert_circuit_ok: Assertion !c->onionskin failed; aborting.
OS:
Debian Etch
2.6.18-5-amd64
[Automatically added by flyspray2trac: Operating System: ...The Tonga tor server crashed with:
Feb 04 10:20:36.880 [err] Bug: circuitlist.c:1165: assert_circuit_ok: Assertion !c->onionskin failed; aborting.
OS:
Debian Etch
2.6.18-5-amd64
[Automatically added by flyspray2trac: Operating System: Other]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/583should load fallback consensus before fetching certs2020-06-27T14:10:27ZRoger Dingledineshould load fallback consensus before fetching certsCurrently we notice we're missing certs for our hardcoded authorities, and
launch directory requests to an authority for them. *Then* we load the
fallback consensus.
Should we load the fallback consensus earlier, and that way we ask dir...Currently we notice we're missing certs for our hardcoded authorities, and
launch directory requests to an authority for them. *Then* we load the
fallback consensus.
Should we load the fallback consensus earlier, and that way we ask directory
mirrors for the certs?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/574bridge or_conns aren't always setting identity map2020-06-27T14:10:28ZRoger Dingledinebridge or_conns aren't always setting identity mapDec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.909 [warn] connection_or_remove_from...Dec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.910 [warn] _connection_free(): Bug: called on OR conn with non-z
eroed identity_digest
I usually get this when I kill my bridge while the bridge user's connection to it
is still open.
I used to think it was due to the "unkeyed bridge" concept, where we don't specify
a digest and leave the or_conn with a digest of 000..000 for a while at the start.
But now I'm not so sure; I think I've seen this in cases where we specify the
digest when configuring the bridge too.
This bug has been around since 0.2.0.7-alpha or so. It appears harmless, but still
worth fixing sometime.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/571dir mirrors not fetching unexpected certs2020-06-27T14:10:28ZRoger Dingledinedir mirrors not fetching unexpected certsif you run 0.2.0.13-alpha, and you use
a bridge relay that doesn't think lefkada is a v3 auth
(say, running 0.2.0.12-alpha),
then you'll constantly ask it for lefkada's cert, and it'll never have it.
aren't mirrors supposed to fetch cer...if you run 0.2.0.13-alpha, and you use
a bridge relay that doesn't think lefkada is a v3 auth
(say, running 0.2.0.12-alpha),
then you'll constantly ask it for lefkada's cert, and it'll never have it.
aren't mirrors supposed to fetch certs for keys that sign the consensus,
even if they didn't expect them?
<nickm> I thought so.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/542looking for fallback-consensus in funny place2020-06-27T14:10:31ZRoger Dingledinelooking for fallback-consensus in funny placeNov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or d...Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/u
nverified-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "${prefix}/share/t
or/fallback-consensus": No such file or directory
My orconfig.h even says
/* Default location for platform-independent read-only data. */
#define SHARE_DATADIR "${prefix}/share"
Are we defining this wrong in the autoconf?
(Linux Debian Etch, I did an svn checkout and then ./autogen && ./configure &&
make && src/or/tor)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-final