Trac issues
https://gitlab.torproject.org/legacy/trac/-/issues
2020-06-13T13:56:05Z
https://gitlab.torproject.org/legacy/trac/-/issues/265
Tor fails to bootstrap if 24 hours pass without running it
2020-06-13T13:56:05Z
Roger Dingledine
Tor fails to bootstrap if 24 hours pass without running it
If I run my Tor client, then close it and wait 24 hours, it will fail
to realize that it has enough directory info to try to build circuits.
Restarting the Tor client a bunch of times doesn't seem to fix anything.
I need to rm -rf my ....
If I run my Tor client, then close it and wait 24 hours, it will fail
to realize that it has enough directory info to try to build circuits.
Restarting the Tor client a bunch of times doesn't seem to fix anything.
I need to rm -rf my .tor directory before it will start working again.
More investigation needed, but I presume the bug is that in one part of
the code it believes something is new enough that it doesn't need to fetch
another one, but in another part of the code it believes it's not new
enough to use.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.x-final
https://gitlab.torproject.org/legacy/trac/-/issues/256
rc.subr script for BSD's (contrib addon)
2020-06-13T13:56:02Z
Trac
rc.subr script for BSD's (contrib addon)
Pasted below is the rc.subr control file for tor that I created (and included) for the FreeBSD tor-devel port as the
newly included (as of 1.1.12) tor.sh and torctl do not work without some serious patching (the patch is longer than the...
Pasted below is the rc.subr control file for tor that I created (and included) for the FreeBSD tor-devel port as the
newly included (as of 1.1.12) tor.sh and torctl do not work without some serious patching (the patch is longer than the
rc.subr itself). I know this works on Net and FreeBSD as both use identical rc.subr format but unsure about OpenBSD.
Indifferent if actually included in the official release under contrib, posting here soley to get Arma off my case :)
######## START TOR.SH #############
#!/bin/sh
#
# $FreeBSD: ports/security/tor-devel/files/tor.in,v 1.1 2006/02/17 22:21:25 mnag Exp $
#
# REQUIRE: NETWORKING SERVERS USR
# BEFORE: LOGIN
#
# Add the following lines to /etc/rc.conf to enable tor
#
# tor_enable (bool): Set to "NO" by default
# Set it to "YES" to enable tor
# tor_conf (str): Points to your tor conf file
# Default: /usr/local/etc/tor/torrc
# tor_user (str): Tor Daemon user. Default _tor
# tor_groupr (str): Tor Daemon group. Default _tor
#
. /etc/rc.subr
name="tor"
rcvar=${name}_enable
load_rc_config ${name}
: ${tor_enable="NO"}
: ${tor_conf="/usr/local/etc/tor/torrc"}
: ${tor_user="_tor"}
: ${tor_group="_tor"}
: ${tor_pidfile="/var/run/tor/tor.pid"}
: ${tor_logfile="/var/log/tor"}
: ${tor_datadir="/var/run/tor"}
required_files=${tor_conf}
required_dirs=${tor_datadir}
command="/usr/local/bin/${name}"
command_args="-f ${tor_conf} --pidfile ${tor_pidfile} --runasdaemon 1 --datadirectory ${tor_datadir} --user ${tor_user} --group ${tor_group}"
extra_commands="log"
log_cmd="${name}_log"
tor_log() {
cat ${tor_logfile}
}
run_rc_command "$1"
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: thoenenp
https://gitlab.torproject.org/legacy/trac/-/issues/248
exit/dns assert failure when out of sockets
2020-06-13T13:55:59Z
Roger Dingledine
exit/dns assert failure when out of sockets
Feb 06 14:42:40.773 [warn] connection_add(): Failing because we have 8159 connections already. Please raise your ulimit -n.
Feb 06 14:55:33.357 [err] dns.c:177: purge_expired_resolves: Assertion pend->conn->s == -1 failed; aborting.
#2 ...
Feb 06 14:42:40.773 [warn] connection_add(): Failing because we have 8159 connections already. Please raise your ulimit -n.
Feb 06 14:55:33.357 [err] dns.c:177: purge_expired_resolves: Assertion pend->conn->s == -1 failed; aborting.
#2 0x00000000004320fe in purge_expired_resolves (now=1139255733) at dns.c:166
#3 0x00000000004323d0 in dns_resolve (exitconn=0x16c9cdf0) at dns.c:282
#4 0x0000000000421201 in connection_exit_begin_resolve (cell=0x7fbffff13e, circ=0x18ddac30)
at connection_edge.c:1608
#5 0x000000000043af87 in connection_edge_process_relay_cell (cell=0x7fbffff130,
circ=0x18ddac30, conn=0x0, layer_hint=0x0) at relay.c:1058
#6 0x0000000000439654 in circuit_receive_relay_cell (cell=0x7fbffff130, circ=0x18ddac30,
cell_direction=2) at relay.c:169
#7 0x0000000000412c03 in command_process_relay_cell (cell=0x7fbffff130, conn=0xae1b30)
at command.c:315
#8 0x0000000000423270 in connection_or_process_cells_from_inbuf (conn=0xae1b30)
at connection_or.c:777
#9 0x000000000041bc65 in connection_handle_read (conn=0xae1b30) at connection.c:1202
(gdb) print *oldest_cached_resolve
$2 = {node = {hte_next = 0x0, hte_hash = 1156299437},
address = "www.cinemanow.com", '\0' <repeats 238 times>, addr = 0, state = 0 '\0',
expire = 1139254227, pending_connections = 0xadc4900, next = 0x2c7bfb0}
(gdb) print *oldest_cached_resolve->pending_connections
$3 = {conn = 0xf6b00d0, next = 0x0}
(gdb) print *oldest_cached_resolve->pending_connections->conn
$4 = {magic = 2084319310, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
wants_to_read = 0, wants_to_write = 0, hold_open_until_flushed = 0, has_sent_end = 0,
control_events_are_extended = 0, is_obsolete = 0, s = 494, poll_index = 3343,
read_event = 0x7cf730, write_event = 0x9937ac0, inbuf = 0xa7194d0, inbuf_reached_eof = 0,
timestamp_lastread = 1139255616, outbuf = 0x700490, outbuf_flushlen = 0,
timestamp_lastwritten = 1139255618, timestamp_created = 1139254410,
timestamp_lastempty = 1139255733, addr = 1166092339, port = 1062, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x10812050 "69.129.40.51", identity_pkey = 0x0,
identity_digest = "tE3¯&i\027\025\204Áª»i\f\001>©ÕßH",
nickname = 0x1a062760 "$744533AF2669171584C1AABB690C013EA9D5DF48",
chosen_exit_name = 0x0, tls = 0x627d8c0, bandwidth = 6291456, receiver_bucket = 6291456,
circ_id_type = CIRC_ID_TYPE_HIGHER, n_circuits = 1, next_with_same_id = 0x0,
next_circ_id = 767, stream_id = 0, next_stream = 0x0, cpath_layer = 0x0,
package_window = 0, deliver_window = 0, requested_resource = 0x0, socks_request = 0x0,
global_identifier = 5000930, event_mask = 0, incoming_cmd_len = 0,
incoming_cmd_cur_len = 0, incoming_cmd = 0x0, on_circuit = 0x0,
rend_query = '\0' <repeats 16 times>, incoming_cmd_type = 0}
This is an OR conn that's pending on a DNS resolve? What the heck.
[Automatically added by flyspray2trac: Operating System: All]
0.1.2.x-final
https://gitlab.torproject.org/legacy/trac/-/issues/246
segfault after upgrade to Openssl-0.9.8
2020-06-13T13:55:58Z
Trac
segfault after upgrade to Openssl-0.9.8
After upgrading to Openssl-0.9.8, tor SegFaults when trying to establish a TLSv3 session.
This bug exists in both current-stable, and .11-alpha and .12-alpha.
Relevent debug info :
(tor compiled with --enable-debug)
Jan 25 10:32:02.287...
After upgrading to Openssl-0.9.8, tor SegFaults when trying to establish a TLSv3 session.
This bug exists in both current-stable, and .11-alpha and .12-alpha.
Relevent debug info :
(tor compiled with --enable-debug)
Jan 25 10:32:02.287 [debug] connection_or_finished_connecting(): OR connect() to router at 82.165.233.43:9001 finished.
Jan 25 10:32:02.287 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 7
Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read
Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read
Jan 25 10:32:02.501 [debug] conn_read_callback(): socket 7 wants to read.
Segmentation fault (core dumped)
stack backtrace :
#268 0x40066fd0 in ?? () from /usr/lib/libssl.so.0
#269 0x082a4a78 in ?? ()
#270 0x081c2120 in ?? ()
#271 0xbfdd26a8 in ?? ()
#272 0x4005485a in SSL_connect () from /usr/lib/libssl.so.0
#273 0x082a4a78 in ?? ()
#274 0x0825bbe8 in ?? ()
#275 0x082d5fe0 in ?? ()
#276 0x080be2eb in tor_tls_handshake (tls=0xbfdd23c4) at tortls.c:556
Previous frame inner to this frame (corrupt stack?)
OpenSSL version info :
OpenSSL 0.9.8a 11 Oct 2005
built on: Tue Jan 24 14:01:00 EST 2006
platform: linux-elf
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
OPENSSLDIR: "/etc/ssl"
LDD info for TOR binary :
ldd /usr/local/bin/tor
libz.so.1 => /usr/lib/libz.so.1 (0x40026000)
libssl.so.0 => /usr/lib/libssl.so.0 (0x40037000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40068000)
libdl.so.2 => /lib/libdl.so.2 (0x400b9000)
libevent-1.1a.so.1 => /usr/local/lib/libevent-1.1a.so.1 (0x400bd000)
libc.so.6 => /lib/libc.so.6 (0x400c4000)
libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x401f3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: mindcandy28
https://gitlab.torproject.org/legacy/trac/-/issues/245
tcp connection rollover still buggy
2020-06-13T13:55:57Z
weasel (Peter Palfrader)
tcp connection rollover still buggy
<weasel> hmm, weird
<weasel> tor26 uses 2500 FDs, but there are only 600 connections to its ORPort
<arma> dir connections?
<arma> kill -usr1 it and see what they are? :)
<weasel> no, those are well below 50
<weasel> netstat suggests ther...
<weasel> hmm, weird
<weasel> tor26 uses 2500 FDs, but there are only 600 connections to its ORPort
<arma> dir connections?
<arma> kill -usr1 it and see what they are? :)
<weasel> no, those are well below 50
<weasel> netstat suggests there are about 1700 connections from tor26 to other nodes
<arma> 600 + 1700 + 50 + fudge = 2500
<weasel> yes, only 1700 is a bit much, isn't it?
<weasel> there aren't that many routers :)
<weasel> ouch
<arma> ?
<weasel> there's over 90 connections just to 140.247.62.121:9001
<weasel> (rodos)
<weasel> bug?
<arma> does each connection have a circuit open?
<arma> or are all the circuits clustered on one or a few connections?
* weasel USR1s tor
<arma> were they all born around the same time, or are they spaced evenly?
<weasel> grr
<weasel> they are all [scrubbed] :)
<weasel> | Jan 22 22:37:26.798 [info] OR rodos [DFF1D66324E1CD02DC7A594EB7DC5F573CDDBDE0]: 93/93 good connections; uptime 118912/118912 sec (100.00%)
<weasel> (it seems it never expired a single one of them tho)
<arma> exciting.
<weasel> there are several that don't have any connections,
<arma> i keep oscillating between fixing this bug and creating new ones.
<weasel> and also several that have connections
<arma> you mean circuits
<weasel> yes
<arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 288565965253/426289 = 676925 byt
<arma> es/sec reading
<arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 377444609668/426289 = 885419 byt
<arma> es/sec writing
<arma> Jan 22 16:43:46.483 [notice] --------------- Dumping memory information:
<arma> Jan 22 16:43:46.483 [notice] In buffers: 8255274 used/86016000 allocated (5803 c
<arma> onns).
<arma> Jan 22 16:43:46.483 [notice] In rephist: 4579240 used by 62619 Tors.
<arma> Jan 22 16:43:46.483 [notice] In 605 live descriptors: 1485855 bytes. In 2247 ol
<arma> d descriptors: 5706345 bytes.
<weasel> 59 without circuits. 32 with circuits
<weasel> most circuits any connection has is 17. then 11, 10, 8, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 2, and the rest has 1 or 0
<arma> moria2 has 5803 conns open.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.13-alpha
https://gitlab.torproject.org/legacy/trac/-/issues/241
segfaults with HW acceleration
2020-06-13T13:55:55Z
weasel (Peter Palfrader)
segfaults with HW acceleration
as reported in #tor, Tor 0.1.1.12 (from the RPM) crashes when HW
crypto engines are available. OpenSSL was probably at 0.9.7.
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RSA ...
as reported in #tor, Tor 0.1.1.12 (from the RPM) crashes when HW
crypto engines are available. OpenSSL was probably at 0.9.7.
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RSA
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for DH
Jan 16 11:22:48.846 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RAND
Core was generated by `tor -f /etc/tor/torrc'.
(gdb) bt
#0 0x00828480 in ?? ()
#1 0x02f5affe in ENGINE_load_aep () from /lib/libcrypto.so.4
#2 0x02f5aadb in ENGINE_load_aep () from /lib/libcrypto.so.4
#3 0x02f48082 in RSA_blinding_on () from /lib/libcrypto.so.4
#4 0x02f460a4 in RSA_PKCS1_SSLeay () from /lib/libcrypto.so.4
#5 0x02f46531 in RSA_PKCS1_SSLeay () from /lib/libcrypto.so.4
#6 0x02f47e9e in RSA_private_encrypt () from /lib/libcrypto.so.4
#7 0x02f486c6 in RSA_sign () from /lib/libcrypto.so.4
#8 0x02f75393 in EVP_SignFinal () from /lib/libcrypto.so.4
#9 0x02f7de9d in ASN1_item_sign () from /lib/libcrypto.so.4
#10 0x02f9c74e in X509_sign () from /lib/libcrypto.so.4
#11 0x080b122a in tor_tls_create_certificate ()
#12 0x080b14fc in tor_tls_context_new ()
#13 0x097ba2f0 in ?? ()
#14 0x080ba9cf in command_c_id ()
#15 0xbfeea670 in ?? ()
#16 0x43cc17af in ?? ()
#17 0xffffffff in ?? ()
#18 0xbfeea668 in ?? ()
#19 0x02f22e1d in CRYPTO_free () from /lib/libcrypto.so.4
Previous frame inner to this frame (corrupt stack?)
[Automatically added by flyspray2trac: Operating System: All]