Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:58:55Zhttps://gitlab.torproject.org/legacy/trac/-/issues/546missing cert launches never back off2020-06-13T13:58:55ZRoger Dingledinemissing cert launches never back offI just added ides as a new v3 authority to my config.c (on moria[12] and on my
bridge relay), and now
Nov 07 16:24:07.260 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.261 [warn] Received http status code 404 ("N...I just added ides as a new v3 authority to my config.c (on moria[12] and on my
bridge relay), and now
Nov 07 16:24:07.260 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.261 [warn] Received http status code 404 ("Not found") from serv
er '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BC
EB6BCC86956".
Nov 07 16:24:07.261 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.469 [warn] Received http status code 404 ("Not found") from serv
er '86.59.21.38:80' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB
6BCC86956".
Nov 07 16:24:07.469 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.616 [warn] Received http status code 404 ("Not found") from serv
er '216.224.124.114:9030' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488A
A5BCEB6BCC86956".
Nov 07 16:24:07.616 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.616 [warn] Received http status code 404 ("Not found") from serv
er '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BC
EB6BCC86956".
Nov 07 16:24:07.617 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.618 [warn] Received http status code 404 ("Not found") from server '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
it repeats ad infinitum without ever backing off.
(The other half of the bug might be that this cert isn't to be found anywhere,
even though ides is running. How are certs for new authorities supposed to get
spread around the network?)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.10-alphahttps://gitlab.torproject.org/legacy/trac/-/issues/547consensus with very few running routers2020-06-13T13:58:56Zweasel (Peter Palfrader)consensus with very few running routerswhen a majority of the authorities upgrade/restart just when it's time
to vote then they will builds votes with only themselves marked as running.
This causes consensus documents with only very few, if any routers marked
as running. ...when a majority of the authorities upgrade/restart just when it's time
to vote then they will builds votes with only themselves marked as running.
This causes consensus documents with only very few, if any routers marked
as running. In such cases it'd probably smarter to continue using an old
consensus.
Maybe the solution is to not vote when you have only been running for a
few (5 to 20?) minutes.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/548recent dir auths are dropping routers from networkstatus2020-06-13T13:58:56ZRoger Dingledinerecent dir auths are dropping routers from networkstatusNov 09 18:11:21.626 [notice] Tongagetting added to v2 vote.
Nov 09 18:11:21.647 [notice] I added 1 Tongas to the v2 vote
Nov 09 18:11:52.892 [notice] Tongagetting added to v2 vote.
Nov 09 18:11:52.911 [notice] I added 1 Tongas to the v2 ...Nov 09 18:11:21.626 [notice] Tongagetting added to v2 vote.
Nov 09 18:11:21.647 [notice] I added 1 Tongas to the v2 vote
Nov 09 18:11:52.892 [notice] Tongagetting added to v2 vote.
Nov 09 18:11:52.911 [notice] I added 1 Tongas to the v2 vote
Nov 09 18:11:57.496 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_add_to_routerlist
Nov 09 18:11:57.496 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_replace, replacing another descriptor
Nov 09 18:11:57.496 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_add_to_routerlist, being better than the old Tonga
Nov 09 18:12:28.223 [notice] Tongagetting added to v2 vote.
Nov 09 18:12:28.242 [notice] I added 1 Tongas to the v2 vote
Nov 09 18:12:59.058 [notice] Tongagetting added to v2 vote.
Nov 09 18:12:59.077 [notice] I added 1 Tongas to the v2 vote
...
Nov 10 12:12:32.405 [notice] Tongagetting added to v2 vote.
Nov 10 12:12:32.422 [notice] I added 1 Tongas to the v2 vote
Nov 10 12:12:36.812 [notice] A descriptor for Tonga (published 2007-11-10 17:12:
36) was spotted in routerlist_add_to_routerlist
Nov 10 12:12:36.812 [notice] A descriptor for Tonga (published 2007-11-10 17:12:
36) was spotted in routerlist_replace, replacing another descriptor
Nov 10 12:12:36.812 [notice] A descriptor for Tonga (published 2007-11-10 17:12:
36) was spotted in routerlist_add_to_routerlist, being better than the old Tonga
Nov 10 12:13:04.723 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_reparse_old, getting ready to go back onto the rou
terlist.
Nov 10 12:13:04.723 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_add_to_routerlist
Nov 10 12:13:04.723 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_replace, replacing another descriptor
Nov 10 12:13:04.723 [notice] A descriptor for Tonga (published 2007-11-09 23:11:
57) was spotted in routerlist_add_to_routerlist, being better than the old Tonga
Nov 10 12:13:06.003 [notice] Tongagetting added to v2 vote.
Nov 10 12:13:06.027 [notice] I added 1 Tongas to the v2 vote
...
Nov 10 12:22:37.467 [notice] Tongagetting added to v2 vote.
Nov 10 12:22:37.485 [notice] I added 1 Tongas to the v2 vote
Nov 10 12:22:50.643 [info] dirserv_orconn_tls_done(): Found router Tonga to be r
eachable. Yay.
Nov 10 12:23:11.088 [notice] Tongagetting added to v2 vote.
Nov 10 12:23:11.106 [notice] I added 1 Tongas to the v2 vote
...
Nov 10 12:43:42.098 [notice] Tongagetting added to v2 vote.
Nov 10 12:43:42.116 [notice] I added 1 Tongas to the v2 vote
Nov 10 12:44:20.516 [info] dirserv_orconn_tls_done(): Found router Tonga to be r
eachable. Yay.
Nov 10 12:44:21.532 [notice] Tongagetting added to v2 vote.
Nov 10 12:44:21.550 [notice] I added 1 Tongas to the v2 vote
Nov 10 12:45:01.439 [notice] Tongagetting added to v2 vote.
Nov 10 12:45:01.466 [notice] I added 1 Tongas to the v2 vote
...
Nov 10 14:09:42.178 [notice] Tongagetting added to v2 vote.
Nov 10 14:09:42.197 [notice] I added 1 Tongas to the v2 vote
Nov 10 14:10:14.103 [notice] Tongagetting added to v2 vote.
Nov 10 14:10:14.121 [notice] I added 1 Tongas to the v2 vote
Nov 10 14:10:40.705 [info] dirserv_orconn_tls_done(): Found router Tonga to be r
eachable. Yay.
Nov 10 14:10:41.115 [info] connection_read_to_buf(): tls error [unexpected close
]. breaking (nickname Tonga, address 82.94.251.206).
Nov 10 14:10:47.784 [notice] Tongagetting added to v2 vote.
Nov 10 14:10:47.803 [notice] I added 1 Tongas to the v2 vote
Nov 10 14:11:21.388 [notice] Tongagetting added to v2 vote.
Nov 10 14:11:21.408 [notice] I added 1 Tongas to the v2 vote
Nov 10 14:11:54.131 [notice] Tongagetting added to v2 vote.
Nov 10 14:11:54.151 [notice] I added 1 Tongas to the v2 vote
Nov 10 14:12:31.128 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:13:02.633 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:13:34.137 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:14:06.078 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:14:39.603 [notice] I added 0 Tongas to the v2 vote
...
Nov 10 14:31:08.730 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:31:41.332 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:32:00.538 [info] dirserv_orconn_tls_done(): Found router Tonga to be r
eachable. Yay.
Nov 10 14:32:12.992 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:32:45.342 [notice] I added 0 Tongas to the v2 vote
Nov 10 14:33:17.402 [notice] I added 0 Tongas to the v2 vote
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/549massive memory leak in exit nodes2020-06-13T13:58:57ZRoger Dingledinemassive memory leak in exit nodesmikeperry ran 0.1.2.17 on his exit node under valgrind:
==1715== 141,696 bytes in 492 blocks are possibly lost in loss record 15 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (uti...mikeperry ran 0.1.2.17 on his exit node under valgrind:
==1715== 141,696 bytes in 492 blocks are possibly lost in loss record 15 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (util.c:116)
==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135)
==1715== by 0x808AB2A: dns_resolve (dns.c:719)
==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250)
==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023)
==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171)
==1715== by 0x805B96E: command_process_cell (command.c:327)
==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768)
==1715== by 0x8067954: connection_process_inbuf (connection.c:2238)
==1715== by 0x806A792: connection_handle_read (connection.c:1449)
==1715== by 0x8091107: conn_read_callback (main.c:422)
==1715==
==1715==
==1715== 178,968,672 (177,808,896 direct, 1,159,776 indirect) bytes in 617,392 blocks are definitely lost in loss record 17 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (util.c:116)
==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135)
==1715== by 0x808AB2A: dns_resolve (dns.c:719)
==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250)
==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023)
==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171)
==1715== by 0x805B96E: command_process_cell (command.c:327)
==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768)
==1715== by 0x8067954: connection_process_inbuf (connection.c:2238)
==1715== by 0x806A792: connection_handle_read (connection.c:1449)
==1715== by 0x8091107: conn_read_callback (main.c:422)
That's this malloc in dns.c:
/* not there, need to add it */
resolve = tor_malloc_zero(sizeof(cached_resolve_t));
resolve->magic = CACHED_RESOLVE_MAGIC;
My first thought is that the "if" above that can still have resolve there,
just without the expected 'expired' value. We should convert r12469 into an
assert at some point.
On closer inspection, r12470 looks like a better candidate for the problem.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/550TOR 407 Proxy authentication required2020-06-13T13:58:57ZTracTOR 407 Proxy authentication requiredNov 11 10:06:41.421 [Notice] Tor v0.1.2.18. This is experimental software. Do not rely on it for strong anonymity.
Nov 11 10:06:41.531 [Notice] Initialized libevent version 1.3e using method win32. Good.
Nov 11 10:06:41.531 [Notice] Open...Nov 11 10:06:41.421 [Notice] Tor v0.1.2.18. This is experimental software. Do not rely on it for strong anonymity.
Nov 11 10:06:41.531 [Notice] Initialized libevent version 1.3e using method win32. Good.
Nov 11 10:06:41.531 [Notice] Opening Socks listener on 127.0.0.1:9050
Nov 11 10:06:41.531 [Notice] Opening Control listener on 127.0.0.1:9051
Nov 11 10:07:42.968 [Warning] Received http status code 407 ("Proxy Authentication Required") from server '128.31.0.34:9032' while fetching "/tor/status/fp/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32+719BE45DE224B607C53707D0E2143E2D423E74CF+7EA6EAD6FD83083C538F44038BBFA077587DD755+847B1F850344D7876491A54892F904934E4EB85D+FFCB46DB1339DA84674C70D7CB586434C4370441.z". I'll try again soon.
Nov 11 10:08:43.859 [Warning] Received http status code 407 ("Proxy Authentication Required") from server '194.109.206.212:80' while fetching "/tor/status/fp/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32+719BE45DE224B607C53707D0E2143E2D423E74CF+7EA6EAD6FD83083C538F44038BBFA077587DD755+847B1F850344D7876491A54892F904934E4EB85D+FFCB46DB1339DA84674C70D7CB586434C4370441.z". I'll try again soon.
Nov 11 10:09:44.859 [Warning] Received http status code 407 ("Proxy Authentication Required") from server '194.109.206.212:80' while fetching "/tor/status/fp/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32+719BE45DE224B607C53707D0E2143E2D423E74CF+7EA6EAD6FD83083C538F44038BBFA077587DD755+847B1F850344D7876491A54892F904934E4EB85D+FFCB46DB1339DA84674C70D7CB586434C4370441.z". I'll try again soon.
Nov 11 10:10:45.859 [Warning] Received http status code 407 ("Proxy Authentication Required") from server '140.247.60.64:80' while fetching "/tor/status/fp/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32+719BE45DE224B607C53707D0E2143E2D423E74CF+7EA6EAD6FD83083C538F44038BBFA077587DD755+847B1F850344D7876491A54892F904934E4EB85D+FFCB46DB1339DA84674C70D7CB586434C4370441.z". I'll try again soon.
Nov 11 10:11:46.843 [Warning] Received http status code 407 ("Proxy Authentication Required") from server '140.247.60.64:80' while fetching "/tor/status/fp/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32+719BE45DE224B607C53707D0E2143E2D423E74CF+7EA6EAD6FD83083C538F44038BBFA077587DD755+847B1F850344D7876491A54892F904934E4EB85D+FFCB46DB1339DA84674C70D7CB586434C4370441.z". I'll try again soon.
This is my error log.
My frd's (same school network) computer can use the tor network in his computer, but mine's kept on receiving 407...
I have typed in http proxy as proxy:8080, domain\user pw:xxxx in the latest version of Vidalia in the network field of Vidalia 0.0.15
I have no idea wt I have to do now. I have changed versions of TOR and Vidalia, but it still gives me this problem.
I have shut down ZA and my Anti-Virus, but still this went on...
Anyone here can help me out of this?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: lsc01287post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/552Mac OS X 0.1.2.18 Tiger Universal Bundle postflight Error2020-06-13T13:58:58ZTracMac OS X 0.1.2.18 Tiger Universal Bundle postflight ErrorTor.pkg:postflight contains the following code:
# Create the configuration file only if there wasn't one already.
if [ ! -f $TARGET/torrc ]; then
cp $TARGET/torrc.sample $TARGET/torrc.sample
fi
which _should_ read
# Create the confi...Tor.pkg:postflight contains the following code:
# Create the configuration file only if there wasn't one already.
if [ ! -f $TARGET/torrc ]; then
cp $TARGET/torrc.sample $TARGET/torrc.sample
fi
which _should_ read
# Create the configuration file only if there wasn't one already.
if [ ! -f $TARGET/torrc ]; then
cp $TARGET/torrc.sample $TARGET/torrc
fi
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: mwfongAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/5530.2.0.11-alpha fails to compile in osx 10.32020-06-13T13:58:58ZAndrew Lewman0.2.0.11-alpha fails to compile in osx 10.3cc -DHAVE_CONFIG_H -I. -I../.. -I../common -g -O2 -Wall -g -O2 -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -g -O2 -Wall -g -O2 -MT util.o ...cc -DHAVE_CONFIG_H -I. -I../.. -I../common -g -O2 -Wall -g -O2 -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -g -O2 -Wall -g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -g -O2 -Wall -g -O2 -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c:670: error: conflicting types for `rlim_t'
/usr/include/sys/types.h:103: error: previous declaration of `rlim_t'
make[4]: *** [compat.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]0.2.0.10-alphahttps://gitlab.torproject.org/legacy/trac/-/issues/555Mac OS X 0.1.2.18 Tiger Universal Bundle addsysuser RFE2020-06-13T13:58:59ZTracMac OS X 0.1.2.18 Tiger Universal Bundle addsysuser RFEOne side-effect of the 2007-06-12 modifications to addsysuser for Mac
OS X 10.5 (Leopard) is that the "_tor" account is no longer assigned
an explicit uid. Cf., the statement in "else" clause that executes
uiddef=`nidump passwd / | ...One side-effect of the 2007-06-12 modifications to addsysuser for Mac
OS X 10.5 (Leopard) is that the "_tor" account is no longer assigned
an explicit uid. Cf., the statement in "else" clause that executes
uiddef=`nidump passwd / | cut -d: -f3 | sort -n | grep -v '!^[56789]..' |grep -v '!^....$' | tail -n 1`
However, these modifications now cause the "else" clause that employs
nidump to never be executed even for older versions of the Mac OS X
(including 10.2 through 10.4) because they (too) have /usr/bin/dscl.
Therefore, I suggest that something along the following be added
within the "if [ -x /usr/bin/dscl ]; then" clause:
if [ -x /usr/bin/nidump ]; then
uiddef=`nidump passwd / | cut -d: -f3 | sort -n | grep -v '!^[56789]..' |grep -v '!^....$' | tail -n 1`
else
set _tmp=/tmp/_dsexport_tmp.txt.$$
rm -f $_tmp
dsexport $_tmp '/Local/Default' 'dsRecTypeStandard:Users' > /dev/null 2>&1
uiddef=`cat $_tmp | sed 's/\\\://g' | cut -d: -f6 | grep '!^[0-9]' | sort -n | grep -v '!^[56789]..' | grep -v '!^....$' | tail -n 1`
rm -f $_tmp
fi
uiddef=`echo $uiddef + 1 | bc`
dscl . -create /users/$username uid $uiddef
(Note that the "if [ -x /usr/bin/nidump ]; then" protection exists
because OSes prior to 10.5 do _not_ have /usr/bin/dsexport (sigh).)
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: mwfongAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/556avoid going to the authorities so much2020-06-13T13:58:59Zweasel (Peter Palfrader)avoid going to the authorities so muchWhen we have a dirport enabled in our config we always go to the
authorities for our directory requests. We should probably only
go to the DAs when we actually have a dirport published.
[Automatically added by flyspray2trac: Operating...When we have a dirport enabled in our config we always go to the
authorities for our directory requests. We should probably only
go to the DAs when we actually have a dirport published.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/557http[s]proxyauthenticator in torrc can't contain # symbol2020-06-13T13:59:00ZRoger Dingledinehttp[s]proxyauthenticator in torrc can't contain # symbolThis was reported in a comment on bug 550, but it deserves its own flyspray entry.
If you add a line to your torrc like
httpproxyauthenticator foo:bar#5
then you can see via getconf that it only sets the value to 'foo:bar'.
One option ...This was reported in a comment on bug 550, but it deserves its own flyspray entry.
If you add a line to your torrc like
httpproxyauthenticator foo:bar#5
then you can see via getconf that it only sets the value to 'foo:bar'.
One option would be to force the user to provide a base64'ed value in the
first place. That's not a very convenient approach though.
Another option would be to make them put it in double quotes, or put a
backslash before it, or otherwise quote it.
Would supporting that in torrc parsing introduce any problems elsewhere?
I can't think of any.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/560tor app for iphone2020-06-13T13:59:00ZTractor app for iphonesince the iphone does wifi, it would be great if tor could be ported to the iphone so we could surf more safely.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: dramsince the iphone does wifi, it would be great if tor could be ported to the iphone so we could surf more safely.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: dramhttps://gitlab.torproject.org/legacy/trac/-/issues/561tor segfaults in libevent2020-06-13T13:59:01ZTractor segfaults in libeventtor-0.2.0.11-alpha as well as tor-0.2.0.12-alpha did core dump after about one week of operation on my Debian “lenny” exit gw.
1.) backtrace for 0.2.0.11
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segment...tor-0.2.0.11-alpha as well as tor-0.2.0.12-alpha did core dump after about one week of operation on my Debian “lenny” exit gw.
1.) backtrace for 0.2.0.11
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7f3d4c2 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
(gdb) bt
#0 0xb7f3d4c2 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
#1 0xb7f3d7b7 in event_tree_RB_REMOVE () from /usr/lib/libevent-1.3d.so.1
#2 0xb7f3dc0b in ?? () from /usr/lib/libevent-1.3d.so.1
#3 0x0812b614 in ?? ()
#4 0xa3f22300 in ?? ()
#5 0x0810cd0d in ?? ()
#6 0x08125ea0 in evdns_log_fn ()
#7 0xb7e14977 in AES_encrypt () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#8 0xa3f22300 in ?? ()
#9 0xbfccc848 in ?? ()
#10 0xb7f3ded1 in event_del () from /usr/lib/libevent-1.3d.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
2.) backtrace for 0.2.0.12
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7f6e4b6 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
(gdb) bt
#0 0xb7f6e4b6 in event_tree_RB_REMOVE_COLOR () from /usr/lib/libevent-1.3d.so.1
#1 0xb7f6e7b7 in event_tree_RB_REMOVE () from /usr/lib/libevent-1.3d.so.1
#2 0xb7f6ec0b in ?? () from /usr/lib/libevent-1.3d.so.1
#3 0x0813a614 in ?? ()
#4 0xa19c9398 in ?? ()
#5 0x0811beed in ?? ()
#6 0x081351e0 in evdns_log_fn ()
#7 0xa6a5f390 in ?? ()
#8 0x36dbdff4 in ?? ()
#9 0x0813a478 in ?? ()
#10 0xb7f7d170 in ?? () from /usr/lib/libevent-1.3d.so.1
#11 0x0813a478 in ?? ()
#12 0xa19c9398 in ?? ()
#13 0xbf90b498 in ?? ()
#14 0xb7f6eed1 in event_del () from /usr/lib/libevent-1.3d.so.1
Backtrace stopped: frame did not save the PC
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: FaloNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/563we are 43197 minutes ahead, or the directory is 43197 minutes behind.2020-06-13T13:59:02ZTracwe are 43197 minutes ahead, or the directory is 43197 minutes behind.Hi,
I'm from Germany so English isn't my native language. Please excuse if there are any difficulties understanding me.
Well, I've been using the vidalia bundle for quite a time, both on my laptop and pc.
A week ago some troubles with m...Hi,
I'm from Germany so English isn't my native language. Please excuse if there are any difficulties understanding me.
Well, I've been using the vidalia bundle for quite a time, both on my laptop and pc.
A week ago some troubles with my pc-vidalia have started.
Vidalia (and Tor) started, but I couldn't use, all I got were the no connection error-message when I tried to load a homepage.
I updated to the 0.1.2.18 version today but the error stayed the same.
Here are the lines from the log I believe to be important.
Jan 05 19:22:46.456 [Hinweis] Tor v0.1.2.18. This is experimental software. Do not rely on it for strong anonymity.
Jan 05 19:22:46.476 [Hinweis] Initialized libevent version 1.3e using method win32. Good.
Jan 05 19:22:46.476 [Hinweis] Opening Socks listener on 127.0.0.1:9050
Jan 05 19:22:46.476 [Hinweis] Opening Control listener on 127.0.0.1:9051
Jan 05 19:22:51.143 [Warnung] Received directory with skewed time (server '128.31.0.34:9031'): we are 43197 minutes ahead, or the directory is 43197 minutes behind.
Jan 05 19:22:51.143 [Hinweis] I learned some more directory information, but not enough to build a circuit.
Jan 05 19:23:00.887 [Hinweis] Application request when we're believed to be offline. Optimistically trying directory fetches again.
I use Windows XP, Firefox 2.0.0.11, the Vidalia-Bundle 0.1.2.18 with Tor-Button.
Please help me, I tried to find some information my self, but couldn't help it.
Thanks a lot,
Tobi
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: tobi84https://gitlab.torproject.org/legacy/trac/-/issues/566Warning2020-06-13T13:59:02ZTracWarningI have the following warning : your server (xxxxxxxx) has not managed to confirm that its ORPort is reachable, please check your firewalls, ports, address, host file, etc...
I use Comodo firewall with Videlia, Tor, and Privoxy are all au...I have the following warning : your server (xxxxxxxx) has not managed to confirm that its ORPort is reachable, please check your firewalls, ports, address, host file, etc...
I use Comodo firewall with Videlia, Tor, and Privoxy are all autorised.
I use a Host file up to date (MVPs Host)
I installed the relay traffic for Tor (setting as recommanded with security).
What can do to settle this problem.
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: nounhttps://gitlab.torproject.org/legacy/trac/-/issues/567Firefox2020-06-13T13:59:03ZTracFirefoxWhen I use Firefox browser with Torbuton, I am offen lost my connection, sometime for few minutes sometimes for longer time.
I get " connection refused, Firefox is configured to be used with proxy but this one do not accepte connection....When I use Firefox browser with Torbuton, I am offen lost my connection, sometime for few minutes sometimes for longer time.
I get " connection refused, Firefox is configured to be used with proxy but this one do not accepte connection....."
But when I have this problem I switch to Opera browser and I dont have any problem.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: nounhttps://gitlab.torproject.org/legacy/trac/-/issues/568panther dislikes tor r128012020-06-13T13:59:03ZAndrew Lewmanpanther dislikes tor r12801panther can't even configure tor anymore:
/autogen.sh
configure.in:23: error: possibly undefined macro: AS_HELP_STRING
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
CO...panther can't even configure tor anymore:
/autogen.sh
configure.in:23: error: possibly undefined macro: AS_HELP_STRING
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
CONFDIR=/Library/Tor ./configure --prefix=/Library/Tor --bindir=/Library/Tor --sysconfdir=/Library
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]https://gitlab.torproject.org/legacy/trac/-/issues/569"We're missing a certificate from authority moria1 with signing key" log mess...2020-06-13T13:59:04ZTrac"We're missing a certificate from authority moria1 with signing key" log messages!Latest SVN version. Running as exit node.
grep 'missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request' /var/log/tor/tor.log
Dec 15 19:12:12.907 [notice] We're missing a...Latest SVN version. Running as exit node.
grep 'missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request' /var/log/tor/tor.log
Dec 15 19:12:12.907 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:12:36.838 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:13:36.509 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:14:37.233 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:15:38.925 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:16:39.644 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:17:40.357 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:18:41.158 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:19:42.868 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:20:43.605 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:21:44.380 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:22:45.223 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:23:46.951 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:24:47.683 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:25:48.381 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:26:50.148 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:27:50.888 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:28:51.745 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:29:52.513 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:30:53.229 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:31:54.965 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:32:55.692 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:33:56.448 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:34:57.208 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:35:58.917 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:36:59.753 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:38:00.562 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:39:01.516 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:40:02.308 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:41:03.188 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:42:04.946 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:43:05.678 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:44:06.393 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:45:08.143 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:46:09.965 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:47:10.685 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:48:11.423 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:49:12.154 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:50:13.914 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:51:14.836 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:52:15.575 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:53:16.379 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:54:17.151 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:55:18.872 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:56:19.605 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:57:20.647 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:58:21.472 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 19:59:22.198 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:00:23.884 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:01:24.619 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:02:25.396 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:03:26.246 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:04:27.946 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:05:28.882 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:06:29.602 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:07:30.345 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:08:32.147 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:09:33.902 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:10:34.698 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:11:35.462 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:12:36.196 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:13:37.917 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:14:38.672 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:15:39.335 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
Dec 15 20:16:41.147 [notice] We're missing a certificate from authority moria1 with signing key 0000000000000000000000000000000000000000: launching request.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiandohttps://gitlab.torproject.org/legacy/trac/-/issues/570possible tor exploit2020-06-13T13:59:04ZTracpossible tor exploitfrom http://www.oreillynet.com/onlamp/blog/2007/03/circumventing_yet_strengthenin.html
While the idea of circumventing the privacy offered by Tor via DNS, Flash, and Java (applets) is nothing new, HD Moore’s “Torment” Tor server hack has...from http://www.oreillynet.com/onlamp/blog/2007/03/circumventing_yet_strengthenin.html
While the idea of circumventing the privacy offered by Tor via DNS, Flash, and Java (applets) is nothing new, HD Moore’s “Torment” Tor server hack has made news at Securityfocus and ZDNet. Although I’m not quite sure why this big news now all of a sudden, it does have positive side effects for the Tor project (see my opinions below).
Moore’s methodology is based on the following strategy (also see Decloak):
1) A modified version of the Tor server is used.
2) When the Tor server is an exit node for a particular connection, it parses HTTP traffic for keywords that indicate criminal activity.
3) When an active keyword is found, the modified Tor server will embed HTML code in the response that will cause the Tor client’s browser to:
- Resolve a host name containing a unique identifier. Applications that use SOCKS 4 resolve hostnames using the ISP’s DNS (without going through the proxy server). In this scenario, the entity running the modified Tor server will also have to run a modified version of a DNS server that will match DNS queries to the unique identifier. This technique allows for the identity of the ISP of the client to be revealed (unless the user is using DNS that does not belong to his or her ISP).
- Load and run a Java applet hosted by the entity running the modified Tor server. The applet will determine the local IP address and pass it to the Tor server owner. If the end user is behind a NAT router, his internal (non-routable) IP address will be revealed.
- The Java applet will send a UDP packet to the server that served the applet. This UDP packet will be sent directly to the destination without going through TOR and will reveal the actual IP address of the client.
Here are my opinions on this:
1) Attempting to identify criminal activity based on keywords may help identify some criminals, but it will most likely result in too many false positives. This will compromise the anonymity of many legitimate Tor users, thus defeating the entire idea behind the Tor project.
2) The proposed methodology uses techniques that are circumvent-able by using Socks4a aware browsers and disabling plugins such as Flash and Java. I am sure Moore is aware of this, and to his credit, most users as of today are most likely to install and use Tor out-of-the-box. Also, disabling plugins such as Flash and Java may not be an option for many users because many web applications require these.
3) The fact that this topic has gained attention will have the following positive side effects on the Tor project:
- Some legitimate Tor users will pay attention to post-installation steps (use Socks4a, disable plugins) they need to perform in order lower the chances of their anonymity being circumvented.
- The Tor project, or a new project that utilizes the Tor system, may make an effort of offering a one stop solution or enhancement to the download package that may aid in automating some of the post-installation steps.
- The Tor download page provides warnings against the limitations of Tor, and even suggests that users investigate plugins such as NoScript and QuickJava. Unfortunately, a regular Tor user is not likely to spend time researching these proposed suggestions and will end up being suscsceptible to the techniques described by Moore. In addition, Tor users who use plugins such as QuickJava may still be susceptible because of the dynamic tag generation proposed by Moore, and there are already ongoing efforts by Tor volunteers to fix this.
In summary, I don’t believe Moore’s proposed idea is the most efficient solution to catching criminals who use Tor as the ZDNet seems to suggest, but I do believe that he has done a great job of demonstrating how most Tor users are susceptible to information leakage, and I believe this will in turn strengthen the Tor project
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jay2007techhttps://gitlab.torproject.org/legacy/trac/-/issues/571dir mirrors not fetching unexpected certs2020-06-13T13:59:05ZRoger 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/legacy/trac/-/issues/572fallback-consensus file impractical to use2022-06-17T18:25:28ZRoger Dingledinefallback-consensus file impractical to useWe can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rp...We can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rpm do its thing too, before
we can reenable it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/573Error: C compiler cannot create executables2020-06-13T13:59:07ZTracError: C compiler cannot create executablesVersion: tor-0.2.0.12-alpha
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.61. Invocatio...Version: tor-0.2.0.12-alpha
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.61. Invocation command line was
$ ./configure
## --------- ##
## Platform. ##
## --------- ##
hostname = COMPUTER
uname -m = i686
uname -r = 2.6.22-14-generic
uname -s = Linux
uname -v = #1 SMP Sun Oct 14 23:05:12 GMT 2007
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1805: checking for a BSD-compatible install
configure:1861: result: /usr/bin/install -c
configure:1872: checking whether build environment is sane
configure:1915: result: yes
configure:1943: checking for a thread-safe mkdir -p
configure:1982: result: /bin/mkdir -p
configure:1995: checking for gawk
configure:2025: result: no
configure:1995: checking for mawk
configure:2011: found /usr/bin/mawk
configure:2022: result: mawk
configure:2033: checking whether make sets $(MAKE)
configure:2054: result: yes
configure:2251: checking build system type
configure:2269: result: i686-pc-linux-gnulibc1
configure:2291: checking host system type
configure:2306: result: i686-pc-linux-gnulibc1
configure:2465: checking for gcc
configure:2481: found /usr/bin/gcc
configure:2492: result: gcc
configure:2730: checking for C compiler version
configure:2737: gcc --version >&5
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2740: $? = 0
configure:2747: gcc -v >&5
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
configure:2750: $? = 0
configure:2757: gcc -V >&5
gcc: '-V' option must have argument
configure:2760: $? = 1
configure:2783: checking for C compiler default output file name
configure:2810: gcc -I../common conftest.c >&5
/usr/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
configure:2813: $? = 1
configure:2851: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "tor"
| #define VERSION "0.2.0.12-alpha"
| #define ENABLE_CELL_POOL 1
| #define ENABLE_THREADS 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2858: error: C compiler cannot create executables
See `config.log' for more details.
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_build=i686-pc-linux-gnulibc1
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i686-pc-linux-gnulibc1
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=mawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_make_make_set=yes
## ----------------- ##
## Output variables. ##
## ----------------- ##
ACLOCAL='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run aclocal-1.10'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run tar'
AUTOCONF='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run autoconf'
AUTOHEADER='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run autoheader'
AUTOMAKE='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run automake-1.10'
AWK='mawk'
BINDIR=''
BUILD_NT_SERVICES_FALSE=''
BUILD_NT_SERVICES_TRUE=''
CC='gcc'
CCDEPMODE=''
CFLAGS=''
CONFDIR=''
CPP=''
CPPFLAGS=' -I../common'
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LOCALSTATEDIR=''
LOGFACILITY=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /home/user/tor-0.2.0.12-alpha/missing --run makeinfo'
OBJEXT=''
PACKAGE='tor'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
RANLIB=''
SET_MAKE=''
SHELL='/bin/bash'
STRIP=''
TORGROUP=''
TORUSER=''
TOR_CPPFLAGS_libevent=''
TOR_CPPFLAGS_openssl=''
TOR_CPPFLAGS_zlib=''
TOR_LDFLAGS_libevent=''
TOR_LDFLAGS_openssl=''
TOR_LDFLAGS_zlib=''
TOR_LIB_GDI=''
TOR_LIB_WS32=''
VERSION='0.2.0.12-alpha'
ac_ct_CC='gcc'
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build='i686-pc-linux-gnulibc1'
build_alias=''
build_cpu='i686'
build_os='linux-gnulibc1'
build_vendor='pc'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE}'
dvidir='${docdir}'
exec_prefix='NONE'
host='i686-pc-linux-gnulibc1'
host_alias=''
host_cpu='i686'
host_os='linux-gnulibc1'
host_vendor='pc'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='$(SHELL) /home/user/tor-0.2.0.12-alpha/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='/bin/mkdir -p'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## ----------- ##
## confdefs.h. ##
## ----------- ##
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "tor"
#define VERSION "0.2.0.12-alpha"
#define ENABLE_CELL_POOL 1
#define ENABLE_THREADS 1
configure: exit 77
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: johndoe32102002https://gitlab.torproject.org/legacy/trac/-/issues/574bridge or_conns aren't always setting identity map2020-06-13T13:59:08ZRoger 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/legacy/trac/-/issues/575cpuworker races to close logs2020-06-13T13:59:08ZRoger Dingledinecpuworker races to close logsmoria1 running 0.2.0.14-alpha when I !^c'ed and let it close after 30 seconds, it
ended with a seg fault.
#0 logv (severity=6, domain=32768, funcname=0x4ae3cf "cpuworker_main",
format=0x4adeb0 "CPU worker exiting because Tor proces...moria1 running 0.2.0.14-alpha when I !^c'ed and let it close after 30 seconds, it
ended with a seg fault.
#0 logv (severity=6, domain=32768, funcname=0x4ae3cf "cpuworker_main",
format=0x4adeb0 "CPU worker exiting because Tor process closed connection (either rotated keys or died).", ap=0x41000d70) at log.c:246
246 if (severity > lf->min_loglevel || severity < lf->max_loglevel) {
(gdb) print lf
$1 = (logfile_t *) 0x20
(gdb) where
#0 logv (severity=6, domain=32768, funcname=0x4ae3cf "cpuworker_main",
format=0x4adeb0 "CPU worker exiting because Tor process closed connection (either rotated keys or died).", ap=0x41000d70) at log.c:246
#1 0x000000000048473f in _log_fn (severity=6294272, domain=0, fn=0x600b00 "",
format=0x2b809b5f73fd "Z!^Ã\213W\020H\211ø\205Òu\006óÃfff\220H\213\177\bL\213\030Aÿãff\220ff\220\203ç\002u#d\213\024%¨") at log.c:304
#2 0x0000000000438207 in cpuworker_main (data=<value optimized out>)
at cpuworker.c:258
#3 0x000000000048a395 in tor_pthread_helper_fn (_data=0x24a9150)
at compat.c:1367
#4 0x00002b809b30ef1a in start_thread () from /lib/libpthread.so.0
#5 0x00002b809b5eb6c2 in clone () from /lib/libc.so.6
#6 0x0000000000000000 in ?? ()
Is it racing with the main thread to print its log entry while closing the log?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/576Tor Node Block (For Malicious Tor Nodes)2020-06-13T13:59:09ZTracTor Node Block (For Malicious Tor Nodes)Hi,
I want tor to enable me to block some Tor Nodes, by IP or any other criteria. This is to block Malicious Tor nodes.
Also allow us to block countries if we want. So that Tor nodes in country X cannot be connected to.
Also, enable M...Hi,
I want tor to enable me to block some Tor Nodes, by IP or any other criteria. This is to block Malicious Tor nodes.
Also allow us to block countries if we want. So that Tor nodes in country X cannot be connected to.
Also, enable Multi-Layered Cryptography using different algorithm , like in TrueCrypt. RSA-AES-DES etc..
this could make things better.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: DarkNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/579Failed to parse/validate config: Configs without ports should be valid2020-06-13T13:59:09ZTracFailed to parse/validate config: Configs without ports should be validTor story regarding a configuration I tried is:
"Failed to parse/validate config: SocksPort, TransPort, NatdPort, and ORPort are all undefined? Quitting."
If I - in theory - were to define
HiddenServiceDir
HiddenServicePort
then I wo...Tor story regarding a configuration I tried is:
"Failed to parse/validate config: SocksPort, TransPort, NatdPort, and ORPort are all undefined? Quitting."
If I - in theory - were to define
HiddenServiceDir
HiddenServicePort
then I would not, if that was indeed the case, require or desire to have anything at all
to do with SocksPort, TransPort, NatdPort, and ORPort.
Tor just atleast start (maby just give a warning? or nothing?) if involvement with
HiddenServiceDir / HiddenServicePort is indicated.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: xiandohttps://gitlab.torproject.org/legacy/trac/-/issues/582tls cert memory leak2020-06-13T13:59:10ZRoger Dingledinetls cert memory leakRunning r13408 as a bridge relay:
==13967== 1,141 (92 direct, 1,049 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 13
==13967== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==13967== by 0x40CC56D: ...Running r13408 as a bridge relay:
==13967== 1,141 (92 direct, 1,049 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 13
==13967== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==13967== by 0x40CC56D: (within /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==13967== by 0x40CCBD8: CRYPTO_malloc (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==13967== by 0x4154E25: (within /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==13967== by 0x4154F1A: ASN1_item_new (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==13967== by 0x414EB3F: X509_new (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==13967== by 0x80F15C3: tor_tls_create_certificate (tortls.c:347)
==13967== by 0x80F1AFE: tor_tls_context_new (tortls.c:525)
==13967== by 0x80C1BC8: init_keys (router.c:483)
==13967== by 0x80A6478: do_main_loop (main.c:1353)
==13967== by 0x80A676A: tor_main (main.c:1963)
==13967== by 0x80DAC11: main (tor_main.c:29)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/583should load fallback consensus before fetching certs2020-06-13T13:59:10ZRoger 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/legacy/trac/-/issues/584Clients process descriptor fetches as they arrive?2020-06-13T13:59:10ZRoger DingledineClients process descriptor fetches as they arrive?While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fall...While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fallback consensus and start using slow dir caches to
bootstrap.
It will also avoid the 250K blobs sitting in ram.
This might be destabilizing enough that it should wait til 0.2.1.x. Not sure.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/586alpha users accumulating hashedcontrolpassword lines2020-06-13T13:59:11ZRoger Dingledinealpha users accumulating hashedcontrolpassword linesIn Tor 0.2.0.13-alpha, I added this feature:
- Allow multiple HashedControlPassword config lines, to support
multiple controller passwords.
But since Vidalia launches Tor by listing a newly generated
HashedControlPassword on t...In Tor 0.2.0.13-alpha, I added this feature:
- Allow multiple HashedControlPassword config lines, to support
multiple controller passwords.
But since Vidalia launches Tor by listing a newly generated
HashedControlPassword on the command-line, every time you
launch Vidalia and change thing and saveconf, it will append
that new HashedControlPassword to your torrc.
So my ~/.vidalia/torrc has 8 of them now. I bet there are people
who have even more.
It occurs to me that options given on the command line might not
need to be saved during a saveconf. But it's far too late to act
on that realization.
The best idea I've got is to change HashedControlPassword back so
you can only have one, and add a new config option
AlternateHashedControlPassword which lets you set multiple and
acts like the current one.
Then we should clear out the extra lines in the current torrcs,
and that new feature is still around in case somebody wants to
use it.
Anybody have a better answer?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/587osx warns on malloc_good_size declaration2020-06-13T13:59:12ZAndrew Lewmanosx warns on malloc_good_size declarationutil.c: In function '_tor_malloc_roundup':
util.c:234: warning: implicit declaration of function 'malloc_good_size'
/usr/include/malloc/malloc.h
size_t (*good_size)(malloc_zone_t *zone, size_t size);
checking malloc/malloc.h usa...util.c: In function '_tor_malloc_roundup':
util.c:234: warning: implicit declaration of function 'malloc_good_size'
/usr/include/malloc/malloc.h
size_t (*good_size)(malloc_zone_t *zone, size_t size);
checking malloc/malloc.h usability... yes
checking malloc/malloc.h presence... yes
checking for malloc/malloc.h... yes
and orconfig.h has:
#define HAVE_MALLOC_MALLOC_H 1
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]https://gitlab.torproject.org/legacy/trac/-/issues/588Tor & MS Explorer2020-06-13T13:59:12ZTracTor & MS ExplorerHi,
have installed Tor, the full pagage.
All seems to be rumming.
How I use the Tor surfing with MS Explorer etc?
Is there a setup like done with JAP, changeing the setup within MS Explorer etc?
Somehow Tor seems not to realize the use...Hi,
have installed Tor, the full pagage.
All seems to be rumming.
How I use the Tor surfing with MS Explorer etc?
Is there a setup like done with JAP, changeing the setup within MS Explorer etc?
Somehow Tor seems not to realize the use of a browser like JAP does.
Thank
you
Werner
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Yougyhttps://gitlab.torproject.org/legacy/trac/-/issues/589memory leak in tor_tls_handshake2020-06-13T13:59:12ZRoger Dingledinememory leak in tor_tls_handshakeRunning r13176, first as a client, then (when Vidalia connects and
setconfs it) as a server.
Looks like it's happening inside openssl. Is this openssl's fault, or
our fault for messing with openssl wrong?
==12945== 15,648 (644 direct, ...Running r13176, first as a client, then (when Vidalia connects and
setconfs it) as a server.
Looks like it's happening inside openssl. Is this openssl's fault, or
our fault for messing with openssl wrong?
==12945== 15,648 (644 direct, 15,004 indirect) bytes in 7 blocks are definitely
lost in loss record 14 of 18
==12945== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==12945== by 0x40CC56D: (within /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==12945== by 0x40CCBD8: CRYPTO_malloc (in /usr/lib/i686/cmov/libcrypto.so.0.9
.8)
==12945== by 0x4154E25: (within /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==12945== by 0x41579EA: ASN1_item_ex_d2i (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==12945== by 0x41580F1: ASN1_item_d2i (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==12945== by 0x414EC94: d2i_X509 (in /usr/lib/i686/cmov/libcrypto.so.0.9.8)
==12945== by 0x406CF7A: ssl3_get_server_certificate (in /usr/lib/i686/cmov/libssl.so.0.9.8)
==12945== by 0x406E420: ssl3_connect (in /usr/lib/i686/cmov/libssl.so.0.9.8)
==12945== by 0x407F3A9: SSL_connect (in /usr/lib/i686/cmov/libssl.so.0.9.8)
==12945== by 0x4074B73: ssl23_connect (in /usr/lib/i686/cmov/libssl.so.0.9.8)
==12945== by 0x407F3A9: SSL_connect (in /usr/lib/i686/cmov/libssl.so.0.9.8)
==12945== by 0x80F1951: tor_tls_handshake (tortls.c:859)
==12945== by 0x807AF49: connection_tls_continue_handshake (connection_or.c:616)
==12945== by 0x8071879: connection_handle_read (connection.c:1904)
==12945== by 0x80A70B7: conn_read_callback (main.c:456)
==12945== by 0x4050C78: (within /usr/lib/libevent-1.1a.so.1.0.2)
==12945== by 0x4050F64: event_base_loop (in /usr/lib/libevent-1.1a.so.1.0.2)
==12945== by 0x4050DCA: event_loop (in /usr/lib/libevent-1.1a.so.1.0.2)
==12945== by 0x80A6C0E: do_main_loop (main.c:1424)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/590false positives for v2 handshake?2020-06-13T13:59:13ZRoger Dingledinefalse positives for v2 handshake?moria1 (running r13177) got this in its logs, even though nick said that
we're not supposed to be playing the v2 game yet:
Jan 19 13:30:27.637 [notice] I think I got a v2 handshake!
Jan 19 13:30:27.638 [warn] TLS error while renegotiati...moria1 (running r13177) got this in its logs, even though nick said that
we're not supposed to be playing the v2 game yet:
Jan 19 13:30:27.637 [notice] I think I got a v2 handshake!
Jan 19 13:30:27.638 [warn] TLS error while renegotiating handshake: unexpected r
ecord (in SSL routines:SSL3_READ_BYTES)
Jan 19 13:30:27.638 [info] connection_tls_continue_handshake(): tls error [misc
error]. breaking connection.
Jan 19 13:30:27.680 [info] TLS error while handshaking: unknown protocol (in SSL
routines:SSL23_GET_SERVER_HELLO)
Jan 19 13:30:27.680 [info] connection_tls_continue_handshake(): tls error [misc
error]. breaking connection.
I also get several
Jan 19 13:49:20.899 [notice] I think I got a v2 handshake!
Jan 19 13:49:20.912 [info] dirserv_orconn_tls_done(): Found router peacetime to
be reachable. Yay.
which makes me think we *are* playing the v2 game.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/591What is the control password in the last Alpha version ?2020-06-13T13:59:13ZTracWhat is the control password in the last Alpha version ?Hello,
First of all, I'm experiencing a lot of problems to register for the TOR newsletter (lots of confirmation e-mails to send...).
But my problem is that since the installation of the Alpha 0.2.0.17 (installed 10 minutes ago), each ...Hello,
First of all, I'm experiencing a lot of problems to register for the TOR newsletter (lots of confirmation e-mails to send...).
But my problem is that since the installation of the Alpha 0.2.0.17 (installed 10 minutes ago), each time I launch TOR, it asks a control password to launch...
What is the password please, whereas I don't have assigned one...
Thanks for your help...
Regards...
Alex
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: King_Alexiushttps://gitlab.torproject.org/legacy/trac/-/issues/592Neuer Task, tor & Firefox2020-06-13T13:59:14ZTracNeuer Task, tor & FirefoxHi,
schade das der task schon geschlossen war, bevor ein Test der Infos erfolgen konnte.
Habe die neuste Version Tor etc. installiert & mit Arcor.de probiert.
Bekomme nun wenigstens ein Error 404 nach einiger Zeit.
Ein Screenshot habe i...Hi,
schade das der task schon geschlossen war, bevor ein Test der Infos erfolgen konnte.
Habe die neuste Version Tor etc. installiert & mit Arcor.de probiert.
Bekomme nun wenigstens ein Error 404 nach einiger Zeit.
Ein Screenshot habe ich, aber ich kann scheinbar diesen nicht anfügen.
Die Infos auf den entsprechenden Seiten entsprechen nicht ganz den
wirklichen Einstellungen/Positionen.
Hat da jemand ein Tip, damit ich alle Einträge IPs etc. wirklich richtig mache?
Danke
Werner
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Yougyhttps://gitlab.torproject.org/legacy/trac/-/issues/593signature download for consensuses fail.2020-06-13T13:59:14Zweasel (Peter Palfrader)signature download for consensuses fail.In order to ensure that each directory authority has all the signatures
from other authorities before they publish a consensus an authority X
goes out and fetches the list of all detached sigs from every other
authority if X is missing s...In order to ensure that each directory authority has all the signatures
from other authorities before they publish a consensus an authority X
goes out and fetches the list of all detached sigs from every other
authority if X is missing sigs from at least one.
However, this doesn't work.
With some additional/louder logging I can see this at tor26:
Jan 24 15:57:31.143 [notice] Time to fetch any signatures that we're missing.
Jan 24 15:57:31.143 [notice] Fetching missing votes/signatures from all authorities (purpose 13)
Jan 24 15:57:31.143 [notice] Sending command to fetch detached sigs. base.state is 1
Jan 24 15:57:31.143 [notice] Asking 128.31.0.34:9031 for /tor/status-vote/next/consensus-signatures.z
Jan 24 15:57:31.143 [notice] Sending command to fetch detached sigs. base.state is 1
Jan 24 15:57:31.143 [notice] Asking 140.247.60.64 for /tor/status-vote/next/consensus-signatures.z
Jan 24 15:57:31.143 [notice] Sending command to fetch detached sigs. base.state is 1
Jan 24 15:57:31.143 [notice] Asking 216.224.124.114:9030 for /tor/status-vote/next/consensus-signatures.z
Jan 24 15:57:31.143 [notice] Sending command to fetch detached sigs. base.state is 1
Jan 24 15:57:31.143 [notice] Asking 88.198.7.215 for /tor/status-vote/next/consensus-signatures.z
Jan 24 15:57:31.143 [notice] Sending command to fetch detached sigs. base.state is 1
Jan 24 15:57:31.143 [notice] Asking 213.73.91.31 for /tor/status-vote/next/consensus-signatures.z
Jan 24 15:57:31.165 [notice] Dir connection to router 88.198.7.215:80 established.
Jan 24 15:57:31.165 [notice] client finished sending command (88.198.7.215).
Jan 24 15:57:31.174 [notice] Dir connection to router 213.73.91.31:80 established.
Jan 24 15:57:31.174 [notice] client finished sending command (213.73.91.31).
Jan 24 15:57:31.187 [notice] 'fetch' response not all here, but we're at eof. Closing.
Jan 24 15:57:31.187 [notice] conn to 88.198.7.215 reached eof, retval is -1
Jan 24 15:57:31.187 [notice] Giving up downloading detached signatures from '88.198.7.215'
Jan 24 15:57:31.206 [notice] 'fetch' response not all here, but we're at eof. Closing.
Jan 24 15:57:31.206 [notice] conn to 213.73.91.31 reached eof, retval is -1
Jan 24 15:57:31.206 [notice] Giving up downloading detached signatures from '213.73.91.31'
Jan 24 15:57:31.247 [notice] Dir connection to router 128.31.0.34:9031 established.
Jan 24 15:57:31.247 [notice] client finished sending command (128.31.0.34).
Jan 24 15:57:31.322 [notice] Dir connection to router 216.224.124.114:9030 established.
Jan 24 15:57:31.322 [notice] client finished sending command (216.224.124.114).
Jan 24 15:57:31.352 [notice] 'fetch' response not all here, but we're at eof. Closing.
Jan 24 15:57:31.352 [notice] conn to 128.31.0.34 reached eof, retval is -1
Jan 24 15:57:31.352 [notice] Giving up downloading detached signatures from '128.31.0.34'
Jan 24 15:57:31.521 [notice] 'fetch' response not all here, but we're at eof. Closing.
Jan 24 15:57:31.521 [notice] conn to 216.224.124.114 reached eof, retval is -1
Jan 24 15:57:31.521 [notice] Giving up downloading detached signatures from '216.224.124.114'
Jan 24 16:00:01.895 [notice] Time to publish the consensus and discard old votes
Note the "'fetch' response not all here, but we're at eof. Closing." log entry.
The problem appears to be that
a) we send bogus Content-Length headers for compressed stuff like
next/conensus.z and next/consensus-signatures.z, and
b) we declare a download failed when we don't have as many bytes as the
Content-Length says there should be.
Point (a) also confuses the hell out of wget.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/597Tor tells admins to send their nickname to tor-ops2020-06-13T13:59:14ZAndrew LewmanTor tells admins to send their nickname to tor-opsAs I was reading through the log the other day:
[info] routers_update_all_from_networkstatus(): The directory authorities do not recognize your nickname.
Please consider sending your nickname and identity fingerprint to the tor-ops.
Sh...As I was reading through the log the other day:
[info] routers_update_all_from_networkstatus(): The directory authorities do not recognize your nickname.
Please consider sending your nickname and identity fingerprint to the tor-ops.
Should we be encouraging this, since we don't need to do this anymore?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/5990.2.0.18-alpha can't create a server behind NAT automatically2020-06-13T14:09:03ZAndrew Lewman0.2.0.18-alpha can't create a server behind NAT automaticallyIt appears 0.2.0.18-alpha can't detect my external IP address while behind NAT. Exact same torrc works in 0.2.0.16-alpha.
Feb 04 22:05:17.479 [Info] resolve_my_address(): Guessed local hostname 'mini.local' resolves to a private IP add...It appears 0.2.0.18-alpha can't detect my external IP address while behind NAT. Exact same torrc works in 0.2.0.16-alpha.
Feb 04 22:05:17.479 [Info] resolve_my_address(): Guessed local hostname 'mini.local' resolves to a private IP address (172.16.31.3). Trying something else.
Feb 04 22:05:17.483 [Info] get_interface_address6(): connect() failed: Invalid argument
Feb 04 22:05:17.486 [Info] resolve_my_address(): Could not get local interface IP address. Too bad.
Feb 04 22:05:17.490 [Info] resolve_my_address(): Address 'mini.local' resolves to private IP address '172.16.31.3'. Tor servers that use the default DirServers must have public IP addresses.
Feb 04 22:05:17.494 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints.
Feb 04 22:05:17.500 [Info] router_pick_published_address(): No hints from directory headers either. Will try again later.
Feb 04 22:05:29.379 [Notice] Opening OR listener on 0.0.0.0:8443
Feb 04 22:05:29.383 [Notice] Opening Directory listener on 0.0.0.0:8080
I configured everything via Vidalia only. I know I can put in the external IP, but as the external IP is on DHCP, it changes every few days.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/600circuitlist.c:1165 crashing bug2020-06-13T13:59:16Zshamrockcircuitlist.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/legacy/trac/-/issues/601tor ignores ExitNodes even when StrictExitNodes is set2020-06-13T13:59:17ZTractor 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/legacy/trac/-/issues/602Add ability to ExcludeNodes by IP.2020-06-13T13:59:17ZNick MathewsonAdd ability to ExcludeNodes by IP.Some people would like to be able to reject Tor nodes by IP or subnet rather than by fingerprint or nickname.
[Automatically added by flyspray2trac: Operating System: All]Some people would like to be able to reject Tor nodes by IP or subnet rather than by fingerprint or nickname.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/603option to specify minimal eligible speed for nodes used2020-06-13T13:59:17ZTracoption to specify minimal eligible speed for nodes usedI think it would be nice if I could set a bandwidth limit and/or average ping limit for my tor client.
For example I could ensure that all nodes to be used has 1Mbit or greater bandwidth. Its really slow to
have a 50Kbit node in the midd...I think it would be nice if I could set a bandwidth limit and/or average ping limit for my tor client.
For example I could ensure that all nodes to be used has 1Mbit or greater bandwidth. Its really slow to
have a 50Kbit node in the middle of two 4Mbit nodes...
Thanks,
András
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: iarpost 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/604Tor 0.1.2.19 server crash on Solaris Sparc2020-06-13T13:59:19ZTracTor 0.1.2.19 server crash on Solaris SparcDear Developpers,
I have successfully compiled and run openssl 0.9.8g, libevent 1.3e and tor 0.1.2.19 with gcc-4.2.2 in a Solaris 10 Sparc Zone as a Tor client.
As soon as I uncomment ORPort in torrc to enable the server it starts initi...Dear Developpers,
I have successfully compiled and run openssl 0.9.8g, libevent 1.3e and tor 0.1.2.19 with gcc-4.2.2 in a Solaris 10 Sparc Zone as a Tor client.
As soon as I uncomment ORPort in torrc to enable the server it starts initializing and crashes with a "Bus Error" while checking reachability and bandwidth.
When I block port 9001 on the firewall it does not crash, but obviously not work also. :)
Trace of the startup included below, with level info and level debug at the final stage.
I do not get a core dumped.
#ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 10
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14117
virtual memory (kbytes, -v) unlimited
Tried to increase open files to 1024 with no difference.
Any help is greatly appreciated.
Thanks,
Jan
Feb 09 11:24:46.399 [notice] Tor v0.1.2.19. This is experimental software. Do not rely on it for strong anonymity.
Feb 09 11:24:46.404 [warn] You specified a public address '0.0.0.0' for a SOCKS proxy. Other people on the Internet might find your computer and use it as an open SOCKS proxy. Please don't allow this unless you have a good reason.
Feb 09 11:24:46.405 [notice] Choosing default nickname 'tor'
Feb 09 11:24:46.406 [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.
Feb 09 11:24:46.410 [notice] Initialized libevent version 1.3e using method event ports. Good.
Feb 09 11:24:46.412 [notice] Opening OR listener on 0.0.0.0:9001
Feb 09 11:24:46.413 [notice] Opening Socks listener on 0.0.0.0:9050
Feb 09 11:24:46.413 [notice] Opening Control listener on 0.0.0.0:9051
Feb 09 11:24:46.418 [info] or_state_load(): Loaded state from "/usr/local/tor/var/state"
Feb 09 11:24:46.437 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
Feb 09 11:24:46.439 [info] configure_nameservers(): Parsing resolver configuration in '/etc/resolv.conf'
Feb 09 11:24:46.439 [info] eventdns: Parsing resolv.conf file /etc/resolv.conf
Feb 09 11:24:46.441 [info] eventdns: Added nameserver xxxxxxx
Feb 09 11:24:46.442 [info] eventdns: Added nameserver xxxxxxx
Feb 09 11:24:46.442 [info] eventdns: Setting maximum allowed timeouts to 3
Feb 09 11:24:46.443 [info] eventdns: Setting timeout to 5
Feb 09 11:24:46.444 [info] init_keys(): Reading/making identity key "/usr/local/tor/var/keys/secret_id_key"...
Feb 09 11:24:46.620 [info] init_keys(): Reading/making onion key "/usr/local/tor/var/keys/secret_onion_key"...
platform Tor 0.1.2.19 on SunOS sun4u
published 2008-02-09 10:24:50
opt fingerprint xxxx xxxx xxxx xxxx
uptime 0
bandwidth 3145728 6291456 0
onion-key
-----BEGIN RSA PUBLIC KEY-----
[...]
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
[...]
-----END RSA PUBLIC KEY-----
opt write-history 2008-02-09 10:24:46 (900 s)
opt read-history 2008-02-09 10:24:46 (900 s)
[...]
Feb 09 11:24:50.620 [info] init_keys(): Dumping fingerprint to "/usr/local/tor/var/fingerprint"...
Feb 09 11:24:50.622 [notice] Your Tor server's identity key fingerprint is 'xxxx xxxx xxxx'
Feb 09 11:24:55.294 [info] router_load_routers_from_string(): 1690 elements to add
Feb 09 11:24:56.435 [info] router_load_routers_from_string(): 365 elements to add
[...]
Feb 09 11:24:56.806 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02)
Feb 09 11:24:56.806 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02) is now "recent"
Feb 09 11:24:57.017 [debug] check_directory_signature(): Signed directory hash starts 4529A66E
Feb 09 11:24:57.021 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01)
Feb 09 11:24:57.021 [info] networkstatus_list_update_recent(): Networkstatus from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01) is now "recent"
Feb 09 11:24:57.244 [debug] check_directory_signature(): Signed directory hash starts DE69E0AF
Feb 09 11:24:57.247 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "dizum" at 194.109.206.212:80 (published 2008-02-08 22:35:27)
Feb 09 11:24:57.248 [info] networkstatus_list_update_recent(): Networkstatus from directory server "dizum" at 194.109.206.212:80 (published 2008-02-08 22:35:27) is now "recent"
Feb 09 11:24:57.458 [debug] check_directory_signature(): Signed directory hash starts FFF46957
Feb 09 11:24:57.462 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41)
Feb 09 11:24:57.462 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41) is now "recent"
Feb 09 11:24:57.463 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02) is no longer "recent"
Feb 09 11:24:57.669 [debug] check_directory_signature(): Signed directory hash starts BB7A2DAC
Feb 09 11:24:57.672 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-08 22:09:03)
Feb 09 11:24:57.673 [info] networkstatus_list_update_recent(): Networkstatus from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-08 22:09:03) is now "recent"
Feb 09 11:24:57.673 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41) is no longer "recent"
Feb 09 11:24:57.674 [info] routerstatus_list_update_from_networkstatus(): Rebuilding router status list.
Feb 09 11:24:57.692 [info] routerstatus_list_update_from_networkstatus(): Naming authorities disagree about which key goes with joestorserver. ($86D83F4F853EDFEEAD1EF3B17CE2034F8397A8F6 vs $0731DD94CD90068DAFE31DBC449F1BA36C6DF277)
[...]
Feb 09 11:24:58.637 [debug] routerstatus_list_update_from_networkstatus(): Router 'FightFascism' is listed by 5/5 directories, named by 2/3, validated by 5/5, and 3/3 recent directories think it's running.
Feb 09 11:24:58.638 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
[...]
Feb 09 11:24:59.353 [info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Feb 09 11:24:59.358 [info] choose_good_exit_server_general(): Found 628 servers that might support 0/0 pending connections.
Feb 09 11:24:59.363 [info] choose_good_exit_server_general(): Chose exit server 'superbad'
[...]
Feb 09 11:24:59.670 [info] connection_dir_client_reached_eof(): Received server info (size 3265) from server '87.106.188.238:80'
Feb 09 11:24:59.674 [info] router_load_routers_from_string(): 1 elements to add
Feb 09 11:24:59.736 [info] connection_dir_client_reached_eof(): Received 1/1 routers requested from 87.106.188.238:80
[...]
Feb 09 11:24:59.846 [info] connection_dir_client_reached_eof(): Received networkstatus objects (size 382650) from server '91.121.7.211:80'
Feb 09 11:25:00.063 [info] router_set_networkstatus(): Setting networkstatus downloaded from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-09 09:58:14)
Feb 09 11:25:00.079 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-09 09:58:14) is now "recent"
Feb 09 11:25:00.080 [info] networkstatus_list_update_recent(): Networkstatus from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01) is no longer "recent"
Feb 09 11:25:00.081 [info] routerstatus_list_update_from_networkstatus(): Rebuilding router status list.
Feb 09 11:25:00.108 [info] routerstatus_list_update_from_networkstatus(): Naming authorities disagree about which key goes with JoesTorServer. ($0731DD94CD90068DAFE31DBC449F1BA36C6DF277 vs $86D83F4F853EDFEEAD1EF3B17CE2034F8397A8F6)
[...]
Feb 09 11:25:01.589 [info] entry_guards_compute_status(): Summary: Entry 'rfc1149' is reachable, usable and live.
Feb 09 11:25:01.589 [info] entry_guards_compute_status(): Summary: Entry 'Bellum' is reachable, unusable and not live.
Feb 09 11:25:01.590 [info] entry_guards_compute_status(): Summary: Entry 'SuperDuperLative' is reachable, usable and live.
Feb 09 11:25:01.590 [info] entry_guards_compute_status(): Summary: Entry 'lolnode' is reachable, usable and live.
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.19,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.15-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.17,0.1.2.18,0.1.2.19,0.2.0.6-alpha,0.2.0.7-alpha,0.2.0.8-alpha,0.2.0.9-alpha,0.2.0.10-alpha,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.13-alpha,0.2.0.14-alpha,0.2.0.15-alpha,0.2.0.16-alpha,0.2.0.17-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.19,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.15-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.591 [info] routers_update_all_from_networkstatus(): 3/3 statements from version-listing directory authorities say my version is ok.
Feb 09 11:25:01.643 [debug] conn_close_if_marked(): Cleaning up connection (fd 14).
Feb 09 11:25:01.643 [debug] connection_remove(): removing socket 14 (type Directory), n_conns now 5
Feb 09 11:25:01.644 [debug] _connection_free(): closing fd 14.
Feb 09 11:25:01.644 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:01.891 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:01.892 [debug] global_read_bucket now 6291456.
Feb 09 11:25:01.892 [debug] global_write_bucket now 6291456.
Feb 09 11:25:01.893 [debug] circuit_remove_handled_ports(): Port 80 is not handled.
Feb 09 11:25:01.893 [info] circuit_predict_and_launch_new(): Have 1 clean circs (0 internal), need another exit circ.
Feb 09 11:25:01.894 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:01.898 [info] choose_good_exit_server_general(): Found 616 servers that might support 0/0 pending connections.
Feb 09 11:25:01.899 [debug] circuit_remove_handled_ports(): Port 80 is not handled.
Feb 09 11:25:01.902 [info] choose_good_exit_server_general(): Chose exit server 'almostunknown'
Feb 09 11:25:02.319 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'SuperDuperLative'
Feb 09 11:25:02.362 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:02.473 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:02.473 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(closed) almostunknown(closed)
Feb 09 11:25:02.474 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:02.474 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:02.509 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:02.510 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:02.510 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.511 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:02.511 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:02.512 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:02.513 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:02.513 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:02.596 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:02.597 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:02.597 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:02.597 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:02.598 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:02.599 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:02.599 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:02.600 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:02.600 [debug] connection_edge_process_relay_cell(): Now seen 1 relay cells here.
Feb 09 11:25:02.601 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:02.633 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:02.634 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(open) almostunknown(closed)
Feb 09 11:25:02.634 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:02.669 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:02.670 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:02.670 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.671 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.671 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:02.672 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:02.672 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:02.673 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:02.673 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:02.920 [debug] global_read_bucket now 6291456.
Feb 09 11:25:02.920 [debug] global_write_bucket now 6291456.
Feb 09 11:25:02.971 [info] circuit_predict_and_launch_new(): Have 2 clean circs (0 uptime-internal, 0 internal), need another hidserv circ.
Feb 09 11:25:02.972 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:02.974 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:02.975 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is aim1loxal1net)
Feb 09 11:25:02.975 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:02.976 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:02.979 [debug] onion_extend_cpath(): Chose router petspaper for hop 2 (exit is aim1loxal1net)
Feb 09 11:25:02.979 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:02.980 [debug] onion_extend_cpath(): Chose router aim1loxal1net for hop 3 (exit is aim1loxal1net)
Feb 09 11:25:02.980 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:02.981 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:02.981 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:02.982 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:03.018 [debug] circuit_deliver_create_cell(): Chosen circID 23586.
Feb 09 11:25:03.019 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.019 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:03.020 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.022 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.022 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:03.086 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:03.086 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:03.087 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.087 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.088 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:03.088 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:03.089 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:03.089 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:03.122 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:03.122 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(closed) aim1loxal1net(closed)
Feb 09 11:25:03.123 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:03.123 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:03.158 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:03.159 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:03.159 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.160 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.160 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:03.161 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.161 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.162 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:03.346 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:03.346 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:03.347 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.347 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.348 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:03.348 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:03.349 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:03.349 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:03.350 [debug] connection_edge_process_relay_cell(): Now seen 2 relay cells here.
Feb 09 11:25:03.350 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:03.383 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:03.384 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(open) aim1loxal1net(closed)
Feb 09 11:25:03.384 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:03.419 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:03.419 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:03.420 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.421 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.421 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.421 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:03.422 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.423 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.423 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.020 [debug] global_read_bucket now 6291456.
Feb 09 11:25:04.021 [debug] global_write_bucket now 6291456.
Feb 09 11:25:04.021 [info] circuit_predict_and_launch_new(): Have 3 clean circs (1 uptime-internal, 1 internal), need another hidserv circ.
Feb 09 11:25:04.022 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:04.023 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:04.024 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is ArnoldBros1905)
Feb 09 11:25:04.025 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:04.025 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:04.028 [debug] onion_extend_cpath(): Chose router wiredwings for hop 2 (exit is ArnoldBros1905)
Feb 09 11:25:04.029 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:04.029 [debug] onion_extend_cpath(): Chose router ArnoldBros1905 for hop 3 (exit is ArnoldBros1905)
Feb 09 11:25:04.030 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:04.030 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:04.031 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:04.031 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:04.066 [debug] circuit_deliver_create_cell(): Chosen circID 23587.
Feb 09 11:25:04.066 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.067 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:04.067 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.068 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.069 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.146 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.147 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.147 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.147 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.148 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.149 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.149 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.149 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.183 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.184 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(closed) ArnoldBros1905(closed)
Feb 09 11:25:04.184 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.184 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.219 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.220 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.220 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.224 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.225 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.225 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.226 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.227 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.301 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.302 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.302 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.302 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.303 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.304 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.304 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.304 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:04.305 [debug] connection_edge_process_relay_cell(): Now seen 3 relay cells here.
Feb 09 11:25:04.305 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:04.340 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.341 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(open) ArnoldBros1905(closed)
Feb 09 11:25:04.341 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.376 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.377 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.377 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.378 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.378 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.380 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.381 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.382 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.382 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.544 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:04.545 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.545 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.546 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.546 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.547 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.547 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.548 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.580 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.581 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(closed) superbad(closed)
Feb 09 11:25:04.582 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.582 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.617 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.617 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.618 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.618 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.619 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.619 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.620 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.620 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.621 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.621 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.622 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.622 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.623 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:04.623 [debug] connection_edge_process_relay_cell(): Now seen 4 relay cells here.
Feb 09 11:25:04.624 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:04.656 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.657 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(open) ArnoldBros1905(open)
Feb 09 11:25:04.657 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.657 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:04.658 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Feb 09 11:25:04.659 [notice] Now checking whether ORPort x.x.x.x:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 09 11:25:04.661 [info] consider_testing_reachability(): Testing reachability of my ORPort: x.x.x.x:9001.
Feb 09 11:25:04.661 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:04.662 [info] onion_pick_cpath_exit(): Using requested exit node 'tor'
Feb 09 11:25:04.663 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:04.664 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is tor)
Feb 09 11:25:04.664 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:04.664 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:04.683 [info] compute_preferred_testing_list(): Looking for middle server that doesn't have the reachability bug, and chose 'Gollum'. Great.
Feb 09 11:25:04.684 [debug] onion_extend_cpath(): Chose router Gollum for hop 2 (exit is tor)
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Chose router tor for hop 3 (exit is tor)
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:04.686 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:04.686 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:04.687 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:04.722 [debug] circuit_deliver_create_cell(): Chosen circID 23588.
Feb 09 11:25:04.722 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.723 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:04.723 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.724 [debug] conn_write_callback(): socket 16 wants to write.
Feb 09 11:25:04.725 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.725 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.726 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.726 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.727 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.795 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.796 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.796 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.797 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.797 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.798 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.798 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.799 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.831 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.832 [info] internal circ (length 3, exit tor): rfc1149(open) $BF39AFADE1ECAB0373459236D31C6A0E3B59CB82(closed) $795EC4D74109C3B4CD7ECB2B652AEF51F99CA5FB(closed)
Feb 09 11:25:04.833 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.833 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.868 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.868 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.869 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.869 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.870 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.870 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.871 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.872 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:05.070 [debug] global_read_bucket now 6291456.
Feb 09 11:25:05.071 [debug] global_write_bucket now 6291456.
Feb 09 11:25:05.738 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:05.738 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:05.739 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:05.739 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:05.740 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:05.740 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:05.741 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:05.741 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:05.742 [debug] connection_edge_process_relay_cell(): Now seen 5 relay cells here.
Feb 09 11:25:05.742 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:05.775 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:05.775 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(open) almostunknown(open)
Feb 09 11:25:05.776 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:05.776 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:05.776 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.080 [debug] global_read_bucket now 6291456.
Feb 09 11:25:06.452 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:06.452 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.452 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.452 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.453 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.453 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.453 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.453 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.453 [debug] connection_edge_process_relay_cell(): Now seen 6 relay cells here.
Feb 09 11:25:06.453 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.486 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.487 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(open) aim1loxal1net(open)
Feb 09 11:25:06.487 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.488 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:06.488 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.553 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:06.554 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.554 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.554 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.555 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.556 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.556 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.557 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.557 [debug] connection_edge_process_relay_cell(): Now seen 7 relay cells here.
Feb 09 11:25:06.557 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.590 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.590 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(open) superbad(closed)
Feb 09 11:25:06.591 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.628 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:06.629 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:06.629 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.630 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.630 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:06.631 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.631 [debug] conn_write_callback(): socket 16 wants to write.
Feb 09 11:25:06.632 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:06.632 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:06.685 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:06.686 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.686 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.687 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.688 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.688 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.688 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.689 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.689 [debug] connection_edge_process_relay_cell(): Now seen 8 relay cells here.
Feb 09 11:25:06.690 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.723 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.723 [info] internal circ (length 3, exit tor): rfc1149(open) $BF39AFADE1ECAB0373459236D31C6A0E3B59CB82(open) $795EC4D74109C3B4CD7ECB2B652AEF51F99CA5FB(closed)
Feb 09 11:25:06.724 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.759 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:06.759 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:06.760 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.760 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.761 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:06.761 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.762 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:06.763 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:06.763 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:07.091 [debug] global_read_bucket now 6291456.
Feb 09 11:25:07.092 [debug] global_write_bucket now 6291456.
Feb 09 11:25:07.719 [debug] conn_read_callback(): socket 5 wants to read.
Feb 09 11:25:07.720 [debug] connection_handle_listener_read(): Connection accepted on socket 14 (child of fd 5).
Feb 09 11:25:07.721 [debug] connection_add(): new conn type OR, socket 14, n_conns 7.
Feb 09 11:25:07.721 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 14
Feb 09 11:25:07.722 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:07.732 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:07.798 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:08.033 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:08.076 [debug] connection_tls_finish_handshake(): tls handshake done. verifying.
Feb 09 11:25:08.078 [debug] connection_or_check_valid_handshake(): The certificate seems to be valid on incoming connection with [scrubbed]:6169
Feb 09 11:25:08.079 [debug] circuit_n_conn_done(): or_conn to Gollum, status=1
Feb 09 11:25:08.080 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.541 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:08.542 [debug] connection_read_to_buf(): 14: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:08.543 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.543 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.544 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:08.544 [debug] connection_read_to_buf(): After TLS read of 512: 1908 read, 1450 written
Feb 09 11:25:08.544 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:08.545 [debug] write_to_buf(): added 1 bytes to buf (now 1 total).
Feb 09 11:25:08.545 [debug] write_to_buf(): added 8 bytes to buf (now 9 total).
Feb 09 11:25:08.546 [debug] write_to_buf(): added 186 bytes to buf (now 195 total).
Feb 09 11:25:08.546 [debug] command_process_create_cell(): success: handed off onionskin.
Feb 09 11:25:08.546 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.547 [debug] conn_write_callback(): socket 15 wants to write.
Feb 09 11:25:08.570 [debug] flush_buf(): 15: flushed 195 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:08.571 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:08.572 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:08.572 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.572 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.573 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:08.573 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:08.574 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:08.574 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:08.575 [debug] connection_edge_process_relay_cell(): Now seen 9 relay cells here.
Feb 09 11:25:08.575 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:08.648 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:08.648 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(open) superbad(open)
Feb 09 11:25:08.649 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:08.649 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:08.650 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.692 [debug] cpuworker_main(): onion_skin_server_handshake succeeded.
Feb 09 11:25:08.693 [debug] cpuworker_main(): finished writing response.
Feb 09 11:25:08.694 [debug] conn_read_callback(): socket 15 wants to read.
Feb 09 11:25:08.694 [debug] read_to_buf_impl(): Read 229 bytes. 229 on inbuf.
Bus Error
# Feb 09 11:25:08.712 [info] cpuworker_main(): CPU worker exiting because Tor process closed connection (either rotated keys or died).
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: jabahttps://gitlab.torproject.org/legacy/trac/-/issues/605unit tests problem on open/net bsd2020-06-13T13:59:20ZRoger Dingledineunit tests problem on open/net bsdRunning Tor unit tests on OpenBSD i386
============================== buffers
.................................................................................................................................................................Running Tor unit tests on OpenBSD i386
============================== buffers
..................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== crypto
.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== util
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== onion_handshake
.....
============================== dir_format
.....................................test: (0xcf7f7c2c)
test in free(): error: ifree: junk pointer, too high to make sense
Abort trap (core dumped)
(gdb) bt
#0 0x0ca54a25 in kill () from /usr/lib/libc.so.39.3
#1 0x0ca8d353 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#2 0x0ca746d9 in wrterror (p=0x2ca23400 "ifree: junk pointer, too high to make sense")
at /usr/src/lib/libc/stdlib/malloc.c:434
#3 0x0ca7479b in wrtwarning (p=0x2ca23400 "ifree: junk pointer, too high to make sense")
at /usr/src/lib/libc/stdlib/malloc.c:444
#4 0x0ca7572e in ifree (ptr=0xcf7f7c2c) at /usr/src/lib/libc/stdlib/malloc.c:1750
#5 0x0ca75961 in free (ptr=0xcf7f7c2c) at /usr/src/lib/libc/stdlib/malloc.c:1838
#6 0x1c055781 in addr_policy_free (p=0xcf7f7c2c) at policies.c:899
#7 0x1c0556be in addr_policy_list_free (lst=0x83c385f0) at policies.c:881
#8 0x1c06b0d7 in routerinfo_free (router=0x80cfd300) at routerlist.c:2145
#9 0x1c08f85b in test_dir_format () at test.c:2358
#10 0x1c097ed7 in main (c=1006961088, v=0xcf7fbe7c) at test.c:3599
This is why r13450 is there. We should fix it better, sometime, too.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/606v3 authorities forgetting certs at restart2020-06-13T13:59:21ZRoger Dingledinev3 authorities forgetting certs at restartmoria1 (running r13476) forgets all its certs every time it restarts.
-rw------- 1 tord tord 9804 2008-02-11 23:45 cached-certs
...
Feb 12 15:27:55.253 [info] init_keys(): adding my own v3 cert
Feb 12 15:27:55.253 [info] trusted_di...moria1 (running r13476) forgets all its certs every time it restarts.
-rw------- 1 tord tord 9804 2008-02-11 23:45 cached-certs
...
Feb 12 15:27:55.253 [info] init_keys(): adding my own v3 cert
Feb 12 15:27:55.253 [info] trusted_dirs_load_certs_from_string(): Adding downloa
ded certificate for directory authority moria1 with signing key CCB7170F6B270B44
301712DD7BC04BF9515AF374
Feb 12 15:27:55.254 [debug] mp_pool_new(): Capacity is 992, item size is 528, al
loc size is 523776
Feb 12 15:27:55.254 [debug] authority_cert_parse_from_string(): We already check
ed the signature on this certificate; no need to do so again.
Feb 12 15:27:55.254 [info] trusted_dirs_load_certs_from_string(): Skipping cache
d certificate for moria1 that we already have.
Feb 12 15:27:55.288 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-12
20:26:30)
Feb 12 15:27:55.398 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "tor26" at 86.59.21.38:80 (published 2008-02-12 20:
20:21)
Feb 12 15:27:55.482 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-12
20:20:08)
Feb 12 15:27:55.568 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "dizum" at 194.109.206.212:80 (published 2008-02-12
20:20:01)
Feb 12 15:27:55.653 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-12
20:22:06)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'lefkada' at 140.247.60.64
:80 (contact 1024D/0E606699 Geoff Goodell <goodell@eecs.harvard.edu>; identity 0
D95B91896E6089AB9A3C6CB56E724CAF898C43F)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'ides' at 216.224.124.114:
9030 (contact Mike Perry <mikeperryTAfsckedTODorg>; identity 27B6B5996C426270A5C
95488AA5BCEB6BCC86956)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'dannenberg' at dannenberg
.ccc.de:80 (contact J. Random Hacker <anonymizer@ccc.de>; identity 585769C78764D
58426B8B52B6651A5A71137189A)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'tor26' at 86.59.21.38:80
(contact Peter Palfrader <peter@palfrader.org> (PGP Key: 0x94C09C7F; Key fingerp
rint: 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F); identity A9AC67E64B20
0BBF2FA26DF194AC0469E2A948C6)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'gabelmoo' at 88.198.7.215
:80 (contact 1024D/F7C11265 Karsten Loesing <karsten dot loesing AT gmx dot net>
; identity EAA879B5C75032E462CB018630D2D0DF46EBA606)
Feb 12 15:27:55.742 [warn] 0 unknown, 5 missing key, 1 good, 0 bad, 0 no signatu
re, 4 required
Feb 12 15:27:55.742 [notice] Not enough certificates to check networkstatus cons
ensus
Feb 12 15:27:55.742 [info] read_file_to_str(): Could not open "moria1/unverified
-consensus": No such file or directory
Feb 12 15:27:55.743 [info] read_file_to_str(): Could not open "/usr/local/share/
tor/fallback-consensus": No such file or directory
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 783A368067E26CDD64205EFCF1C5066B5F55EDCB: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key F0A23AD304A0CFF4C27B3D0AE23468FBDD4E88F0: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key DAB9DC29E8CFEEEAF8F47F1DE144E2A2F89C4128: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 2A9EABF158D0D4BFFA6C4A8EDC84A4F6487FCE9B: launching request.
Feb 12 15:27:55.743 [info] router_pick_directory_server(): No reachable router e
ntries for dirservers. Trying them all again.
...
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/607INFO logging is a bit noisy.2020-06-13T13:59:21ZNick 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/legacy/trac/-/issues/608Clients flip out when two routers use the same identity key2020-06-13T13:59:22ZNick MathewsonClients flip out when two routers use the same identity keyIf two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses
clients. Instead, authorities should only allow one server per key.
[Automatically added by flyspray2trac: Operating Syste...If two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses
clients. Instead, authorities should only allow one server per key.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/609Servers no longer learn IP from authorities2020-06-13T13:59:22ZNick MathewsonServers no longer learn IP from authoritiesAccording to arma, the new code that keeps non-cache serves from using the authorities to download directory information
means that many hosts won't talk to the authorities, and therefore won't learn their IP addresses from the
X-Your-IP...According to arma, the new code that keeps non-cache serves from using the authorities to download directory information
means that many hosts won't talk to the authorities, and therefore won't learn their IP addresses from the
X-Your-IP-Is header.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/610automake complains on debian etch2020-06-13T13:59:22ZRoger Dingledineautomake complains on debian etcharma@last-request:~/torsvn/trunk$ automake --add-missing --copy
src/common/Makefile.am:6: libor_a_SOURCES was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
#CFLAGS = -Wall -Wpointer-arith -...arma@last-request:~/torsvn/trunk$ automake --add-missing --copy
src/common/Makefile.am:6: libor_a_SOURCES was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
#CFLAGS = -Wall -Wpointer-arith -O2
libor_a_SOURCES (User, where = src/common/Makefile.am:6) +=
{
TRUE => log.c util.c compat.c container.c mempool.c
}
src/common/Makefile.am:6: warning: automake does not support conditional definition of libor_a_SOURCES in libor_a_SOURCES
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450.
: am_libor_a_OBJECTS was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
am_libor_a_OBJECTS (Automake, where = undefined) =
{
TRUE => log.$(OBJEXT) util.$(OBJEXT) compat.$(OBJEXT) container.$(OBJEXT) mempool.$(OBJEXT)
}
It looks like it worked anyway -- I can still build. But this is probably
something we should fix.
$ automake --version
automake (GNU automake) 1.6.3
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/611Apparently, we can use more than 15000 connections2020-06-13T13:59:23ZNick MathewsonApparently, we can use more than 15000 connectionsOn or-talk, Olaf Selke reports:
debugging the "[warn] Error creating network socket: Too
many open files" messages I just found the max number of
file descriptors apparently being ha...On or-talk, Olaf Selke reports:
debugging the "[warn] Error creating network socket: Too
many open files" messages I just found the max number of
file descriptors apparently being hard coded in or.h to a
value of 15.000. Raising the number using ulimit -n thus
shows no effect.
The 15000 cap once made sense when we had a static array of connections, but now that the list is unlimited, there
is no need to have it be an upper bound. Let's change it from an upper bound into a default.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/612tor needs to perform a dir request whenever starting as a server?2020-06-13T13:59:23ZRobert 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/legacy/trac/-/issues/614Tor crash on 0.2.20-rc2020-06-13T13:59:24ZTracTor crash on 0.2.20-rcHere is the logs :
Feb 25 21:28:23.074 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 05:40:15.124 [warn] TLS error while renegotiating handshake wi...Here is the logs :
Feb 25 21:28:23.074 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 05:40:15.124 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 07:51:54.217 [warn] No ciphers on session
Feb 26 07:51:54.221 [err] Bug: connection.c:1580: connection_buckets_decrement: Assertion num_written < INT_MAX failed; aborting.
Sorry, I don't have a core file.
I've relaunch the same version to see if it happen again.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Fredzupy0.2.0.22-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/615PROTOCOLINFO returns incorrect auth methods when HashedControlPassword is use...2020-06-13T13:59:24ZedmanmPROTOCOLINFO returns incorrect auth methods when HashedControlPassword is used on command lineTor 0.2.0.20-rc's response to a PROCOLINFO command fails to include the HASHEDPASSWORD method when a
HashedControlPassword is used on the command line. This can be reproduced by starting Tor with the following
command:
tor ControlPo...Tor 0.2.0.20-rc's response to a PROCOLINFO command fails to include the HASHEDPASSWORD method when a
HashedControlPassword is used on the command line. This can be reproduced by starting Tor with the following
command:
tor ControlPort 9051 HashedControlPassword 16:09724E2AACEF0B4C60BD49793E3B2F84912034369B6528CCE2815BBE70
The PROTOCOLINFO command then returns the following results:
edmanm@lysithea:~$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
protocolinfo
250-PROTOCOLINFO 1
250-AUTH METHODS=NULL
250-VERSION Tor="0.2.0.20-rc"
250 OK
Note that the PROTOCOLINFO response claims Tor does not require any authentication, even though the
HASHEDPASSWORD method should be included in the AUTH METHODS list.
The following patch fixes the problem:
Index: src/or/control.c
===================================================================
--- src/or/control.c (revision 13776)
+++ src/or/control.c (working copy)
@@ -2541,7 +2541,8 @@
char *esc_cfile = esc_for_log(cfile);
char *methods;
{
- int passwd = (options->HashedControlPassword != NULL);
+ int passwd = (options->HashedControlPassword != NULL ||
+ options->HashedControlSessionPassword != NULL);
smartlist_t *mlist = smartlist_create();
if (cookies)
smartlist_add(mlist, (char*)"COOKIE");
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/6160.2.1.0-alpha-dev does not compile on Dapper amd642020-06-13T13:59:24ZKarsten Loesing0.2.1.0-alpha-dev does not compile on Dapper amd64Compiling 0.2.1.0-alpha-dev (r13786) exits with the following error:
tortls.c: In function ‘tor_tls_new’:
tortls.c:738: error: ‘TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA’ undeclared (first use in this function)
This happens only on Dap...Compiling 0.2.1.0-alpha-dev (r13786) exits with the following error:
tortls.c: In function ‘tor_tls_new’:
tortls.c:738: error: ‘TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA’ undeclared (first use in this function)
This happens only on Dapper amd64 while compiling on Dapper x86 and Gutsy x86 works fine.
On both machines, openssl version and ciphers are as follows:
/usr/local/ssl/bin/openssl version
OpenSSL 0.9.8g 19 Oct 2007
/usr/local/ssl/bin/openssl ciphers (manually inserted line breaks)
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:
EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:AES128-SHA:IDEA-CBC-SHA:IDEA-CBC-MD5:RC2-CBC-MD5:
RC4-SHA:RC4-MD5:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:
DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:
EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5
The libevent version is in both cases 1.3e.
Configuration is done with:
./configure --with-libevent-dir=/usr/local/lib/ --with-openssl-dir=/usr/local/ssl/lib/
After commenting out the following ciphers from CLIENT_CIPHER_LIST in tortls.c, compilation works again:
TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS1_TXT_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS1_TXT_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS1_TXT_ECDHE_RSA_WITH_RC4_128_SHA
TLS1_TXT_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA
TLS1_TXT_ECDHE_RSA_WITH_DES_192_CBC3_SHA
[Automatically added by flyspray2trac: Operating System: Other Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/617DNS bug: duplicate call to connection_mark_for_close at connection_edge.c2020-06-13T13:59:25ZTracDNS bug: duplicate call to connection_mark_for_close at connection_edge.cActually, I'm running 0.2.0.21-rc, not 0.2.0.20-rc
This occurs when tor is running and the modem connects to the ISP
In order to ensure dns requests aren't leaked, my resolv.conf is just
127.0.0.1
127.0.0.1
127.0.0.1
and named is set...Actually, I'm running 0.2.0.21-rc, not 0.2.0.20-rc
This occurs when tor is running and the modem connects to the ISP
In order to ensure dns requests aren't leaked, my resolv.conf is just
127.0.0.1
127.0.0.1
127.0.0.1
and named is set to forward any non-cached queries to port 9999, which tor is listening on for DNS queries.
Here's the debug output:
Mar 05 22:15:01.887 [info] evdns_server_callback(): Got a new DNS request!
Mar 05 22:15:01.887 [debug] connection_add(): new conn type Socks, socket -1, n_conns 23.
Mar 05 22:15:01.887 [info] evdns_server_callback(): Passing request for [scrubbed] to rewrite_and_attach.
Mar 05 22:15:01.887 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for [scrubbed]:0
Mar 05 22:15:01.887 [warn] Malformed IP "lb._dns-sd._udp.0.0.0.10.in-addr.arpa" in address pattern; rejecting.
Mar 05 22:15:01.887 [debug] connection_ap_handshake_attach_circuit(): Attaching apconn to circ 32257 (stream 0 sec old).
Mar 05 22:15:01.887 [info] exit (high-uptime) circ (length 3): GuyMontag(open) $4539E403341C5B7D7A7494127C12F7DFAEEB5952(open) croeso(open)
Mar 05 22:15:01.887 [debug] link_apconn_to_circ(): attaching new conn to circ. n_circ_id 32257.
Mar 05 22:15:01.887 [warn] Bug: Duplicate call to connection_mark_for_close at connection_edge.c:1504 (first at connection_edge.c:2015)
Mar 05 22:15:01.887 [info] evdns_server_callback(): Passed request for [scrubbed] to rewrite_and_attach.
Mar 05 22:15:01.887 [debug] conn_write_callback(): socket 18 wants to write.
Mar 05 22:15:01.887 [debug] conn_close_if_marked(): Cleaning up connection (fd -1).
Mar 05 22:15:01.887 [debug] connection_remove(): removing socket -1 (type Socks), n_conns now 23
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandude0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/619exit-policy-reject-star relays should refuse dns?2020-06-13T13:59:25ZRoger 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/legacy/trac/-/issues/621Authentical/Password Request Bug - Vidalia Startup2020-06-13T13:59:26ZTracAuthentical/Password Request Bug - Vidalia StartupRandomly, upon startup, Vidalia will ask for a control password when none has been intentionally set by myself.
Everything will work fine for the first couple start-ups and then I will be hit with the control password request when Vidal...Randomly, upon startup, Vidalia will ask for a control password when none has been intentionally set by myself.
Everything will work fine for the first couple start-ups and then I will be hit with the control password request when Vidalia attempts to load.
I have "Googled" and tried various suggested workarounds to no avail. The only resolution is uninstalling/reinstalling the bundle each time.
I am using the current stable version 0.1.2.19. The unstable version will not run at all as Vidalia will cause an error in an SSL dll.
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: MikeDChttps://gitlab.torproject.org/legacy/trac/-/issues/622Tor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket ...2020-06-13T13:59:27ZTracTor 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/legacy/trac/-/issues/625'SIZE_MAX' undeclared2020-06-13T13:59:27Zweasel (Peter Palfrader)'SIZE_MAX' undeclaredOpenBSD_malloc_Linux.c: In function 'calloc':
OpenBSD_malloc_Linux.c:1941: error: 'SIZE_MAX' undeclared (first use in this function)
OpenBSD_malloc_Linux.c:1941: error: (Each undeclared identifier is reported only once
OpenBSD_malloc_Lin...OpenBSD_malloc_Linux.c: In function 'calloc':
OpenBSD_malloc_Linux.c:1941: error: 'SIZE_MAX' undeclared (first use in this function)
OpenBSD_malloc_Linux.c:1941: error: (Each undeclared identifier is reported only once
OpenBSD_malloc_Linux.c:1941: error: for each function it appears in.)
[on alpha]
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/626Tor v0.2.1.0-alpha-dev r13924, r14010 SIGUSR2+SIGHUP results into invalid free()2020-06-13T13:59:30ZTracTor v0.2.1.0-alpha-dev r13924, r14010 SIGUSR2+SIGHUP results into invalid free()This happens with at least r13924 and r14010.
Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
SIGUSR2 does not print anything into logs. After I give SIGHUP after SIGUSR2, I get abort() from glibc.
I config file I have:...This happens with at least r13924 and r14010.
Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
SIGUSR2 does not print anything into logs. After I give SIGHUP after SIGUSR2, I get abort() from glibc.
I config file I have:
Log notice stderr
2008-03-13 23:03:55.563861070 [notice] Received reload signal (hup). Reloading config.
2008-03-13 23:03:55.569223290 *** glibc detected *** /usr/bin/tor: free(): invalid next size (fast): 0x00005555571dcf60 ***
2008-03-13 23:03:55.569225572 ======= Backtrace: =========
2008-03-13 23:03:55.569226102 /lib64/libc.so.6[0x2af1432a7748]
2008-03-13 23:03:55.569226645 /lib64/libc.so.6(cfree+0x76)[0x2af1432a9d86]
2008-03-13 23:03:55.569227269 /usr/bin/tor[0x5555555edec2]
2008-03-13 23:03:55.569227712 /usr/bin/tor[0x5555555ee6a7]
2008-03-13 23:03:55.569228142 /usr/bin/tor[0x55555557bba1]
2008-03-13 23:03:55.569228582 /usr/bin/tor[0x55555557c07a]
2008-03-13 23:03:55.569243287 /usr/bin/tor[0x55555557d3af]
2008-03-13 23:03:55.569243891 /usr/bin/tor[0x55555557d782]
2008-03-13 23:03:55.569244346 /usr/bin/tor[0x5555555b622e]
2008-03-13 23:03:55.569244791 /usr/lib64/libevent-1.3d.so.1(event_base_loop+0x229)[0x2af1423ec659]
2008-03-13 23:03:55.569245497 /usr/bin/tor[0x5555555b96be]
2008-03-13 23:03:55.569245938 /usr/bin/tor[0x5555555b991d]
2008-03-13 23:03:55.569246378 /lib64/libc.so.6(__libc_start_main+0xfa)[0x2af14324c36a]
2008-03-13 23:03:55.569247011 /usr/bin/tor[0x555555561169]
2008-03-13 23:03:55.569251150 ======= Memory map: ========
2008-03-13 23:03:55.569251729 40000000-40001000 ---p 40000000 00:00 0
2008-03-13 23:03:55.569252257 40001000-40801000 rw-p 40001000 00:00 0
2008-03-13 23:03:55.569252770 40801000-40802000 ---p 40801000 00:00 0
2008-03-13 23:03:55.569253305 40802000-41002000 rw-p 40802000 00:00 0
2008-03-13 23:03:55.569253826 3000000000-300001f000 r-xp 00000000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569254692 300021e000-300021f000 r--p 0001e000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569259036 300021f000-3000220000 rw-p 0001f000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569268961 2aaaaab0b000-2aaaaab21000 r-xp 00000000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569269977 2aaaaab21000-2aaaaad20000 ---p 00016000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569270953 2aaaaad20000-2aaaaad21000 rw-p 00015000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569296484 2aaaac000000-2aaaac021000 rw-p 2aaaac000000 00:00 0
2008-03-13 23:03:55.569297338 2aaaac021000-2aaab0000000 ---p 2aaaac021000 00:00 0
2008-03-13 23:03:55.569297996 2af142174000-2af142198000 rw-p 2af142174000 00:00 0
2008-03-13 23:03:55.569298689 2af1421d2000-2af1421e6000 r-xp 00000000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569299557 2af1421e6000-2af1423e5000 ---p 00014000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569304663 2af1423e5000-2af1423e6000 rw-p 00013000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569305639 2af1423e6000-2af1423fc000 r-xp 00000000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569306609 2af1423fc000-2af1425fc000 ---p 00016000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569316445 2af1425fc000-2af1425fd000 rw-p 00016000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569317688 2af1425fd000-2af1425ff000 rw-p 2af1425fd000 00:00 0
2008-03-13 23:03:55.569318376 2af1425ff000-2af14264a000 r-xp 00000000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569319413 2af14264a000-2af142849000 ---p 0004b000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569324170 2af142849000-2af142851000 rw-p 0004a000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569325309 2af142851000-2af142852000 rw-p 2af142851000 00:00 0
2008-03-13 23:03:55.569326014 2af142852000-2af1429e3000 r-xp 00000000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569327080 2af1429e3000-2af142be3000 ---p 00191000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569331570 2af142be3000-2af142c06000 rw-p 00191000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569332704 2af142c06000-2af142c0a000 rw-p 2af142c06000 00:00 0
2008-03-13 23:03:55.569333409 2af142c0a000-2af142c0d000 r-xp 00000000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569334433 2af142c0d000-2af142e0c000 ---p 00003000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569344033 2af142e0c000-2af142e0d000 rw-p 00002000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569344961 2af142e0d000-2af142e24000 r-xp 00000000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569345872 2af142e24000-2af143023000 ---p 00017000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569346803 2af143023000-2af143024000 r--p 00016000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569351250 2af143024000-2af143025000 rw-p 00017000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569352261 2af143025000-2af14302a000 rw-p 2af143025000 00:00 0
2008-03-13 23:03:55.569352869 2af14302a000-2af14302c000 r-xp 00000000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569353763 2af14302c000-2af14322c000 ---p 00002000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569358212 2af14322c000-2af14322d000 r--p 00002000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569359156 2af14322d000-2af14322e000 rw-p 00003000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569360079 2af14322e000-2af143395000 r-xp 00000000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569368855 2af143395000-2af143594000 ---p 00167000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569369839 2af143594000-2af143598000 r--p 00166000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569370710 2af143598000-2af143599000 rw-p 0016a000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569371588 2af143599000-2af14359e000 rw-p 2af143599000 00:00 0
2008-03-13 23:03:55.569384967 2af14359e000-2af1435a6000 r-xp 00000000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569386236 2af1435a6000-2af1437a5000 ---p 00008000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569387114 2af1437a5000-2af1437a6000 r--p 00007000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569388032 2af1437a6000-2af1437a7000 rw-p 00008000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569393073 2af1437a7000-2af1437a8000 rw-p 2af1437a7000 00:00 0
2008-03-13 23:03:55.569393741 2af1437a8000-2af1437ba000 r-xp 00000000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569394672 2af1437ba000-2af1439b9000 ---p 00012000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569395590 2af1439b9000-2af1439ba000 r--p 00011000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569405152 2af1439ba000-2af1439bb000 rw-p 00012000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569406186 2af1439bb000-2af1439bf000 rw-p 2af1439bb000 00:00 0
2008-03-13 23:03:55.569406782 2af143a1b000-2af143a26000 r-xp 00000000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569407715 2af143a26000-2af143c25000 ---p 0000b000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569412290 2af143c25000-2af143c26000 r--p 0000a000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569413351 2af143c26000-2af143c27000 rw-p 0000b000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569414292 2af143c27000-2af143c29000 r-xp 00000000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569418426 2af143c29000-2af143e28000 ---p 00002000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569419444 2af143e28000-2af143e29000 rw-p 00001000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569420393 2af143e29000-2af143e2d000 r-xp 00000000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569429222 2af143e2d000-2af14402d000 ---p 00004000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569430178 2af14402d000-2af14402e000 r--p 00004000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569431096 2af14402e000-2af14402f000 rw-p 00005000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569432027 2af1440b3000-2af1462b4000 r--p 00000000 08:07 8601139 /var/lib/tor/cached-descriptors
2008-03-13 23:03:55.569436254 2af146915000-2af146976000 rw-p 2af146915000 00:00 0
2008-03-13 23:03:55.569436932 555555554000-55555564b000 r-xp 00000000 08:08 137853895 /usr/bin/tor-0.2.1.0-r14010
2008-03-13 23:03:55.569445856 55555584a000-555555851000 rw-p 000f6000 08:08 137853895 /usr/bin/tor-0.2.1.0-r14010
2008-03-13 23:03:55.569447013 555555851000-555555852000 rw-p 555555851000 00:00 0
2008-03-13 23:03:55.569452180 5555571da000-555559d19000 rw-p 5555571da000 00:00 0 [heap]
2008-03-13 23:03:55.569453021 7fff63cab000-7fff63cc0000 rw-p 7ffffffea000 00:00 0 [stack]
2008-03-13 23:03:55.569453800 7fff63dfe000-7fff63e00000 r-xp 7fff63dfe000 00:00 0 [vdso]
2008-03-13 23:03:55.569454588 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safarihttps://gitlab.torproject.org/legacy/trac/-/issues/629Allow diretory mirror only.2020-06-13T13:59:30ZTracAllow diretory mirror only.Currently, in order to mirror the directory, you must relay traffic. Please enable the server to mirror the
directory without having to relay traffic. Sometimes we have more upload than download available, tihs will
ensure we can co...Currently, in order to mirror the directory, you must relay traffic. Please enable the server to mirror the
directory without having to relay traffic. Sometimes we have more upload than download available, tihs will
ensure we can contribute also. Thank you.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: screampost 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/630windows compile warning2020-06-13T13:59:31ZRoger Dingledinewindows compile warningphobos> windows says
phobos> compat.c: In function `set_max_file_descriptors':
phobos> compat.c:781: warning: long unsigned int format, int arg (arg 5)
I can only assume the cygwin, iphone, etc lines will have similar issues.
I'm not su...phobos> windows says
phobos> compat.c: In function `set_max_file_descriptors':
phobos> compat.c:781: warning: long unsigned int format, int arg (arg 5)
I can only assume the cygwin, iphone, etc lines will have similar issues.
I'm not sure if it's better to change the %lu to a %d, or cast the literal
(ugh), or what.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/6310.2.0.x svn fails two unit tests2020-06-13T13:59:31ZRoger Dingledine0.2.0.x svn fails two unit testsTry running src/or/test
File test.c: line 2280 (test_dir_format): assertion failed: (router_dump_router_to_string(buf, 2048, r1, pk2)>0)
(we make a test descriptor without any policy lines in it)
File test.c: line 3000 (test_policies):...Try running src/or/test
File test.c: line 2280 (test_dir_format): assertion failed: (router_dump_router_to_string(buf, 2048, r1, pk2)>0)
(we make a test descriptor without any policy lines in it)
File test.c: line 3000 (test_policies): assertion failed: (ADDR_POLICY_REJECTED == compare_addr_to_addr_policy(0x01020304u, 2, NULL))
[Automatically added by flyspray2trac: Operating System: All]0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/632Tor v0.2.1.0-alpha-dev (r14101): eventdns(?): Assertion conn->read_event failed2020-06-13T13:59:32ZTracTor v0.2.1.0-alpha-dev (r14101): eventdns(?): Assertion conn->read_event failedWith high concurrency, tor eventdns barfs up.
Trying to resolve 100 IP addresses with concurrency of 100+100 (for PTR->A and A->PTR) with command:
random-ip 100 64|DNSCACHEIP=127.0.0.69 dnsfilter -c 100 | DNSCACHEIP=127.0.0.69 dnsfilter ...With high concurrency, tor eventdns barfs up.
Trying to resolve 100 IP addresses with concurrency of 100+100 (for PTR->A and A->PTR) with command:
random-ip 100 64|DNSCACHEIP=127.0.0.69 dnsfilter -c 100 | DNSCACHEIP=127.0.0.69 dnsfilter -c 100 -p
Takes less than a minute till abort().
2008-03-18 19:14:58.980894879 [debug] connection_remove(): removing socket -1 (type Socks), n_conns now 897
2008-03-18 19:14:59.301429897 [debug] conn_write_callback(): socket 24 wants to write.
2008-03-18 19:14:59.301432330 [debug] flush_chunk_tls(): flushed 3901 bytes, 12483 ready to flush, 12483 remain.
2008-03-18 19:14:59.301433263 [debug] flush_chunk_tls(): flushed 4057 bytes, 8426 ready to flush, 8426 remain.
2008-03-18 19:14:59.301434092 [debug] flush_chunk_tls(): flushed 4057 bytes, 4369 ready to flush, 4369 remain.
2008-03-18 19:14:59.301434943 [debug] flush_chunk_tls(): flushed 4057 bytes, 312 ready to flush, 312 remain.
2008-03-18 19:14:59.301435738 [debug] flush_chunk_tls(): flushed 312 bytes, 0 ready to flush, 0 remain.
2008-03-18 19:14:59.301455409 [debug] connection_handle_write(): After TLS write of 16384: 0 read, 16722 written
2008-03-18 19:14:59.301456530 [err] Bug: main.c:300: connection_start_reading: Assertion conn->read_event failed; aborting.
2008-03-18 19:14:59.301457413 main.c:300 connection_start_reading: Assertion conn->read_event failed; aborting.
2008-03-18 19:15:00.340741083 [notice] Tor v0.2.1.0-alpha-dev (r14101). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64)
I have a big log file, but this should be easily reproducable.
Other notes about eventdns: (maybe this should go in a different bugreport)
- O(N) lookup for transactions IDs (this may or may not show up in the profiles, but is nevertheless not a very clever tactic)
- using malloc+memset instead of calloc
- ad-hoc handling of lists (e.g., would look more readable if you made static inline function list_add instead of doing
ns->next = server_head->next; ns->prev = server_head; server_head->next = ns; etc.)
- useless casts: resolv = (u8 *) malloc((size_t)st.st_size + 1);
- why is it doing CLEAR so often before free?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safari0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/633Tor retries download for unparseable descriptors2020-06-13T13:59:32ZNick MathewsonTor retries download for unparseable descriptors15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning...15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning message.
15:15 <@diseasearma> Mar 18 15:15:35.895 [info]
connection_dir_client_reached_eof(): Received server
15:15 <@diseasearma> info (size 2471) from server '194.109.206.212:80'
15:16 <@diseasearma> is what prefaces it.
15:16 < nickm> seeing that on peacetime too
15:16 <@diseasearma> looks like my relays are going to dizum to get a
descriptor they don't have,
15:16 <@diseasearma> and it's a descriptor they don't want,
15:16 <@diseasearma> but then they go back again and get it again.
15:17 <@diseasearma> they go back once a minute
15:17 < nickm> looks like they're counting it as a download failure.
15:17 < nickm> there should be some way to mark it as perma-failed.
15:18 * nickm restarts peacetime on the 0.2.0 branch.
15:19 <@diseasearma> ok. we're going to see this come up on or-talk shortly.
15:20 <@diseasearma> i guess i could preemptively post saying it's a known
problem and will be solved 'later'.
15:20 < nickm> s/later/soon/
15:20 < nickm> we can even add a flyspray entry.
15:20 < nickm> s/we/I/
In summary, when we download a descriptor and then can't parse it, we need to remember to never try to download
it again. Also, our log message could be better.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/634can not resolve A records for domains ending with *.in-addr.arpa2020-06-13T13:59:33ZTraccan not resolve A records for domains ending with *.in-addr.arpaLocal dnscache, no tor:
$ DNSCACHEIP=127.0.0.1 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
61 bytes, 1+1+0+0 records, response, noerror
query: 1 130.14.169.217.in-addr.arpa
answer: 130.14.169.217.in-addr.arpa 3285 ...Local dnscache, no tor:
$ DNSCACHEIP=127.0.0.1 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
61 bytes, 1+1+0+0 records, response, noerror
query: 1 130.14.169.217.in-addr.arpa
answer: 130.14.169.217.in-addr.arpa 3285 A 217.169.14.130
Local dnscache, forwarding queries to tor:
$ DNSCACHEIP=127.0.0.69 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
temporary failure
2008-03-18 21:22:17.921528231 [info] addressmap_register(): Temporary addressmap ('REVERSE[130.14.169.217.in-addr.arpa]' to '130.14.169.217.in-addr.arpa') not performed, since it's already mapped to '130.14.169.217.in-addr.arpa'
Tor version 0.2.1.0-alpha-dev (r14110).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SafariTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/635eventdns and caching of NXDOMAIN2020-06-13T13:59:33ZTraceventdns and caching of NXDOMAINLocal DNS proxy might not include the SOA record (in case of NXDOMAIN) when it is resolving for tor,
but faking a SOA record should be easy... maybe a config option or #define for the TTL of cached NXDOMAIN?
Now in case of NXDOMAIN, ev...Local DNS proxy might not include the SOA record (in case of NXDOMAIN) when it is resolving for tor,
but faking a SOA record should be easy... maybe a config option or #define for the TTL of cached NXDOMAIN?
Now in case of NXDOMAIN, eventdns does not include Authority RR with SOA record, so clients querying
tor can not cache the NXDOMAIN. They just keep on querying the same thing again and again.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SafariTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/641asking to exit from yourself launches many circuits2020-06-13T13:59:34ZRoger Dingledineasking to exit from yourself launches many circuitssebastian hahn reports that if you ask to exit via yourself, using the .exit
notation, it will launch dozens of circuits.
My guess is that it's noticing, each second, that it doesn't have any suitable
circuits for the .exit stream, so i...sebastian hahn reports that if you ask to exit via yourself, using the .exit
notation, it will launch dozens of circuits.
My guess is that it's noticing, each second, that it doesn't have any suitable
circuits for the .exit stream, so it launches a new one.
There's something wrong with recognizing that the in-progress circuits are
acceptable for the pending stream.
My guess is it has to do with not having our descriptor in the router list.
See connection_ap_can_use_exit() where we ask
if (router_get_by_nickname(conn->chosen_exit_name, 1) != exit)
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/642debug output: parameters reversed2020-06-13T13:59:34ZTracdebug output: parameters reversed--- tor-0.2.0.23-rc/src/common/tortls.c
+++ tor-0.2.0.23-rc/src/common/tortls.c
@@ -666,7 +666,7 @@
}
s = smartlist_join_strings(elts, ":", 0, NULL);
log_info(LD_NET, "Got a non-version-1 cipher list from %s. It is: '%s'"...--- tor-0.2.0.23-rc/src/common/tortls.c
+++ tor-0.2.0.23-rc/src/common/tortls.c
@@ -666,7 +666,7 @@
}
s = smartlist_join_strings(elts, ":", 0, NULL);
log_info(LD_NET, "Got a non-version-1 cipher list from %s. It is: '%s'",
- s, address);
+ address, s);
tor_free(s);
smartlist_free(elts);
}
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: bugmenothttps://gitlab.torproject.org/legacy/trac/-/issues/643tor shouldn't load the config file with --hash-password2020-06-13T13:59:34ZTractor shouldn't load the config file with --hash-passwordI noticed that tor uses the config file /etc/tor/torrc when I use --hash-password too: if I run
"tor --hash-password ..." from a unprivileged user I expect to simply receive the hashed password
but actually tor reads the system wide co...I noticed that tor uses the config file /etc/tor/torrc when I use --hash-password too: if I run
"tor --hash-password ..." from a unprivileged user I expect to simply receive the hashed password
but actually tor reads the system wide config file and fails because of user/group settings.
A simple workaround is to create a 'empty' config file and pass it to tor using the '-f' option.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mrfreehttps://gitlab.torproject.org/legacy/trac/-/issues/646miscellaneous stream event bugs for DNS requests2020-06-13T14:27:23ZRobert Hoganmiscellaneous stream event bugs for DNS requestsThe response to a reverse lookup from the controller looks like:
650 ADDRMAP REVERSE[64.4.33.7] lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
Except when the result is already cached. Then it looks like:
650...The response to a reverse lookup from the controller looks like:
650 ADDRMAP REVERSE[64.4.33.7] lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
Except when the result is already cached. Then it looks like:
650 ADDRMAP 64.4.33.7 lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
The 'REVERSE' is missing. Not sure which way is the 'correct' way - assume it's the non-cached response.
Also,
- There's currently no 'NEW' stream event for DNS requests. Add one.
- Cached reverse DNS requests get a 'CLOSE' event but no 'NEW' event. Just drop the 'CLOSE' event, since no conn is created.
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 14233)
+++ src/or/connection_edge.c (working copy)
@@ -1348,13 +1348,16 @@
&map_expires)) {
char *result = tor_strdup(socks->address);
/* remember _what_ is supposed to have been resolved. */
- strlcpy(socks->address, orig_address, sizeof(socks->address));
+ tor_snprintf(socks->address, sizeof(socks->address), "REVERSE[%s]",
+ orig_address);
connection_ap_handshake_socks_resolved(conn, RESOLVED_TYPE_HOSTNAME,
strlen(result), result, -1,
map_expires);
+ strlcpy(socks->address, orig_address, sizeof(socks->address));
connection_mark_unattached_ap(conn,
- END_STREAM_REASON_DONE |
- END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED);
+ END_STREAM_REASON_DONE |
+ END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED |
+ END_STREAM_REASON_FLAG_ALREADY_SENT_CLOSED);
return 0;
}
if (options->ClientDNSRejectInternalAddresses) {
@@ -2084,9 +2087,11 @@
string_addr, payload_len) < 0)
return -1; /* circuit is closed, don't continue */
+ ap_conn->_base.address = tor_strdup("(Tor_internal)");
ap_conn->_base.state = AP_CONN_STATE_RESOLVE_WAIT;
log_info(LD_APP,"Address sent for resolve, ap socket %d, n_circ_id %d",
ap_conn->_base.s, circ->_base.n_circ_id);
+ control_event_stream_status(ap_conn, STREAM_EVENT_NEW, 0);
control_event_stream_status(ap_conn, STREAM_EVENT_SENT_RESOLVE, 0);
return 0;
}
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/648No available nodes after network outage2020-06-13T13:59:36ZTracNo 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/legacy/trac/-/issues/649When installing the Tor Bundle on OS X, Torbutton will not be installed into ...2020-06-13T13:59:36ZSebastian 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/legacy/trac/-/issues/650Using the .exit notation does not work with trunk (currently r14296)2020-06-13T13:59:37ZSebastian HahnUsing the .exit notation does not work with trunk (currently r14296)I suspect r14281 to be the culprit.
What happens is the following: No matter which exit node I choose via the .exit-notation,
I get a message in a log that the destination could not be reached using that exit. To double-check, I
downg...I suspect r14281 to be the culprit.
What happens is the following: No matter which exit node I choose via the .exit-notation,
I get a message in a log that the destination could not be reached using that exit. To double-check, I
downgraded to 0.2.0.23-rc and used the exact same URL - and it worked as expected (except for using yourself as exit node, of course).
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/651assert in refetching v2 rend desc2020-06-13T13:59:37ZRoger 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/legacy/trac/-/issues/652Tor doesn't detect when the world cannot reach it anymore2020-06-13T14:07:28ZSebastian HahnTor doesn't detect when the world cannot reach it anymoreThis is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the p...This is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the pre-RC
versions, I haven't checked the previous RCs for that behaviour. Even after 6 hours,
Tor has nothing in the Notice-level log.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/653geoip_remove_old_clients() never gets called?2020-06-13T13:59:39ZRoger Dingledinegeoip_remove_old_clients() never gets called?We never call geoip_remove_old_clients(). This means bridge relays
just grow a larger and larger pile of client geoip entries.
I would fix suggest to fix it in the same way we clean up other
items:
=====================================...We never call geoip_remove_old_clients(). This means bridge relays
just grow a larger and larger pile of client geoip entries.
I would fix suggest to fix it in the same way we clean up other
items:
===================================================================
--- main.c (revision 14322)
+++ main.c (working copy)
@@ -988,6 +988,7 @@
/* Remove old information from rephist and the rend cache. */
if (time_to_clean_caches < now) {
rep_history_clean(now - options->RephistTrackTime);
+ geoip_remove_old_clients(now - options->RephistTrackTime);
rend_cache_clean();
rend_cache_clean_v2_descs_as_dir();
#define CLEAN_CACHES_INTERVAL (30*60)
===================================================================
--- geoip.c (revision 14322)
+++ geoip.c (working copy)
@@ -326,6 +326,7 @@
char *result = NULL;
if (!geoip_is_loaded())
return NULL;
+ geoip_remove_old_clients(now - get_options()->RephistTrackTime);
if (client_history_starts < (now - 12*60*60)) {
char buf[32];
smartlist_t *chunks = NULL;
But there's a problem. If we publish a descriptor very often, then the
difference between "the past 24 hours at point x" and "the past 24 hours
at point x+\delta" will give away what happened a day ago, to whatever
granularity we happen to have between the two descriptor updates.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/654Don't re-use entry point for testing circuits2020-06-13T14:57:10ZNick MathewsonDon't re-use entry point for testing circuitsMoving from TODO into a bug report, since this is a bug:
- we try to build 4 test circuits to break them over different
servers. but sometimes our entry node is the same for multiple
test circuits. this defeats the point.
[A...Moving from TODO into a bug report, since this is a bug:
- we try to build 4 test circuits to break them over different
servers. but sometimes our entry node is the same for multiple
test circuits. this defeats the point.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/655using all free CPU time in router_get_by_nickname2020-06-13T13:59:44ZTracusing all free CPU time in router_get_by_nicknameThis has happened with both Tor v0.2.1.0-alpha-dev r14297 and r14259.
Quite seldom, tor starts eating all CPU time, with nothing interesting logged with "Log debug stderr"
(debug output looks(?! ;) ) the same as when tor is not hogging a...This has happened with both Tor v0.2.1.0-alpha-dev r14297 and r14259.
Quite seldom, tor starts eating all CPU time, with nothing interesting logged with "Log debug stderr"
(debug output looks(?! ;) ) the same as when tor is not hogging all CPU).
I for now "worked around" this by using only hex digests in ExcludeNodes.
Thread 1 (Thread 0x2b5b3a251700 (LWP 17463)):
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#8 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#9 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#10 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#11 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#12 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#13 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#14 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#15 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#16 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#17 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#18 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#19 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#20 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
Thread 1 (Thread 0x2b5b3a251700 (LWP 17463)):
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#8 0x000055555557332d in circuit_build_needed_circs () from /proc/17463/exe
#9 0x00005555555b9706 in second_elapsed_callback () from /proc/17463/exe
#10 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#11 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#12 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#13 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#14 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#19 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555bb921 in router_get_consensus_status_by_nickname ()
#2 0x00005555555de685 in add_nickname_list_to_smartlist ()
#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#19 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safarihttps://gitlab.torproject.org/legacy/trac/-/issues/656Tor server crash in SSL_free with DH crypto error in logs2020-06-13T13:59:47ZMike 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
#2 0x4cfc6ab5 in SSL_free () from /lib/libssl.so.6
#3 0x080f335c in tor_tls_free (tls=0x40df1ac0) at tortls.c:831
#4 0x0806d2eb in _connection_free (conn=0x46229f00) at connection.c:328
#5 0x080a363c in connection_unlink (conn=0x46229f00) at main.c:212
#6 0x080a390e in close_closeable_connections () at main.c:603
#7 0x4cfe4125 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#8 0x4cfe4349 in event_loop () from /usr/lib/libevent-1.1a.so.1
#9 0x080a5149 in do_main_loop () at main.c:1446
#10 0x080a52fb in tor_main (argc=3, argv=0x59c9d5c4) at main.c:1986
#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
#2 0x4cd6d884 in _IO_new_file_write () from /lib/libc.so.6
#3 0x4cd6d545 in new_do_write () from /lib/libc.so.6
#4 0x4cd6d82f in _IO_new_do_write () from /lib/libc.so.6
#5 0x4cd6e006 in _IO_new_file_sync () from /lib/libc.so.6
#6 0x4cd62c3c in fflush () from /lib/libc.so.6
#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
#8 0x080dad0e in _log (severity=4, domain=2,
format=0x8124004 "crypto error while %s: %s (in %s:%s)") at log.c:314
#9 0x080eb1a7 in crypto_log_errors (severity=4,
doing=0x8123cb0 "generating DH key") at crypto.c:146
#10 0x080ec104 in crypto_dh_generate_public (dh=0x34be56e0) at crypto.c:1467
#11 0x080ec31b in crypto_dh_get_public (scrubbed) at crypto.c:1492
#12 0x080a9e7e in onion_skin_server_handshake (scrubbed)
at onion.c:267
#13 0x08083a70 in cpuworker_main (data=0x4c2f2090) at cpuworker.c:284
#14 0x080e11ed in tor_pthread_helper_fn (_data=0x4c2f20a0) at compat.c:1482
#15 0x4ce5745b in start_thread () from /lib/libpthread.so.0
#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/legacy/trac/-/issues/658Tor breaks DNS on Linksys router.2020-06-13T13:59:48ZTracTor breaks DNS on Linksys router.I tried Tor 0.1.2.19 for the first time to run it as a relay, but had to stop using it because I found that on 2
occasions TOR would cause my Linksys router to stop returning DNS requests for that machine. All DNS requests on
the machin...I tried Tor 0.1.2.19 for the first time to run it as a relay, but had to stop using it because I found that on 2
occasions TOR would cause my Linksys router to stop returning DNS requests for that machine. All DNS requests on
the machine failed even after a cold boot and my only option was to reset the router by cycling the power.
I tried to set the bandwidth settings to something less demanding, but I could never confirm if they were set
as intended because the controls reset back to "Cable/DSL" instead of the manual settings I specified, and yes
I saved the config after makign the changes.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Yonahhttps://gitlab.torproject.org/legacy/trac/-/issues/659When configuring OR/Dir Ports, Tor always processes OR Port change first2020-06-13T13:59:48ZTracWhen configuring OR/Dir Ports, Tor always processes OR Port change firstI wasn't exactly sure how to phrase the subject, so feel free to rename it.
Basically, when you change the OR or Directory Port Settings in Vidalia, Tor
will always try to configure the OR Port first.
This creates a problem if the user...I wasn't exactly sure how to phrase the subject, so feel free to rename it.
Basically, when you change the OR or Directory Port Settings in Vidalia, Tor
will always try to configure the OR Port first.
This creates a problem if the user tries to switch the OR Port and the Dir Port
(or just change the OR Port to the current Dir Port, and change the Dir Port to
anything else). In short, in such a scenario, Tor blocks itself.
For example:
Say a Tor Server was configured to use Dir Port 443 and OR Port 8080.
If the user tried to change it to use Dir Port 80 and OR Port 443, the following
error message would be presented:
[Warning] Could not bind to 0.0.0.0:443: Address already in use [WSAEADDRINUSE ].
Is Tor already running?
This error message would be presented because Tor first closes the OR Port, 8080.
It then tries to open Port 443, but it is already using Port 443 as the Dir Port.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HANtwisterTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/660swapped params in call to rep_hist_note_used_port2020-06-13T13:59:48ZTracswapped params in call to rep_hist_note_used_portversion: tor-0.2.0.23-rc
[tor/src/or/directory.c:directory_initiate_command:~722]
/* If it's an anonymized connection, remember the fact that we
* wanted it for later: maybe we'll want it again soon. */
if (anonymized_conn...version: tor-0.2.0.23-rc
[tor/src/or/directory.c:directory_initiate_command:~722]
/* If it's an anonymized connection, remember the fact that we
* wanted it for later: maybe we'll want it again soon. */
if (anonymized_connection && use_begindir)
rep_hist_note_used_internal(time(NULL), 0, 1);
else if (anonymized_connection && !use_begindir)
[ The parameters in the following call are swapped compared to the function declaration and
definintion. ]
rep_hist_note_used_port(time(NULL), conn->_base.port);
[tor/src/or.h:~3581]
void rep_hist_note_used_port(uint16_t port, time_t now);
[tor/src/or/rephist.c:~1426]
void
rep_hist_note_used_port(uint16_t port, time_t now)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovahttps://gitlab.torproject.org/legacy/trac/-/issues/661tor returns localized web pages2020-06-13T13:59:49ZTractor returns localized web pagesWhen Tors' action results in a 'foreign' IP address, Google (for example) returns the appropriately localized page!
Not a huge problem for Google, I suppose, but
http://www.torproject.org/download.html.de is a challenge for an English s...When Tors' action results in a 'foreign' IP address, Google (for example) returns the appropriately localized page!
Not a huge problem for Google, I suppose, but
http://www.torproject.org/download.html.de is a challenge for an English speaker.
Feature request: would it be possible to perform a reverse-localization lookup in order to stay within the language domain of the originating user?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: pinkylbh3https://gitlab.torproject.org/legacy/trac/-/issues/662wrong size for allocation2020-06-13T13:59:49ZTracwrong size for allocation[tor/src/or/dirvote.c:networkstatus_compute_consensus: ~644]
int *named_flag; /* Index of the flag "Named" for votes[j] */
int *unnamed_flag; /* Index of the flag "Unnamed" for votes[j] */
[...]
named_flag = tor_mallo...[tor/src/or/dirvote.c:networkstatus_compute_consensus: ~644]
int *named_flag; /* Index of the flag "Named" for votes[j] */
int *unnamed_flag; /* Index of the flag "Unnamed" for votes[j] */
[...]
named_flag = tor_malloc_zero(sizeof(int*) * smartlist_len(votes));
!^
|
[ This looks wrong, probably we should be using 'sizeof(int)' in the allocation. Probably only affects 64-bit systems. ]
[ Same problem on the next line too: ]
unnamed_flag = tor_malloc_zero(sizeof(int*) * smartlist_len(votes));
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovahttps://gitlab.torproject.org/legacy/trac/-/issues/663netinfo clock skew warn too loud2020-06-13T13:59:49ZRoger 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/legacy/trac/-/issues/669Clients don't realize that a server has a different identity than stated in c...2020-06-13T13:59:50ZKarsten 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/legacy/trac/-/issues/670Tor Server unable to create a circuit2020-06-13T13:59:50ZTracTor Server unable to create a circuitGreetings:
I've been off my machine for a few days; and when I logged on, I was unable to get Tor to generate a circuit.
I'm on a Fedora Core 9 machine. The following's the thread - thanks for your help.
Apr 22 04:55:06.695 [notice] ...Greetings:
I've been off my machine for a few days; and when I logged on, I was unable to get Tor to generate a circuit.
I'm on a Fedora Core 9 machine. The following's the thread - thanks for your help.
Apr 22 04:55:06.695 [notice] Tor v0.1.2.19. This is experimental software. Do not rely on it for strong anonymity.
Apr 22 04:55:06.701 [notice] Initialized libevent version 1.3e using method epoll. Good.
Apr 22 04:55:06.702 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 22 04:55:08.408 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:08.595 [warn] Unable to mmap new descriptor file at '/var/lib/tor/.tor/cached-routers'.
Apr 22 04:55:08.598 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.095 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.419 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.806 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.829 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:19.815 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:56:25.758 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:57:41.703 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Apr 22 04:58:27.336 [notice] I learned some more directory information, but not enough to build a circuit.
and so on...
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: robertgray86https://gitlab.torproject.org/legacy/trac/-/issues/671tor 0.2.0.24-rc: mutex initialization problem?2020-06-13T13:59:51ZTractor 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
#2 0x0810f835 in tor_mutex_new () at compat.c:1756
#3 0x08108b84 in init_logging () at log.c:498
#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
#2 0x080e9f45 in tor_mutex_new () at compat.c:1756
#3 0x080e3294 in init_logging () at log.c:498
#4 0x080aae7c in tor_main (argc=1 argv=0xbfbfeaa4) at min.c:1968
#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/legacy/trac/-/issues/672[warn] Still had some address policies cached at shutdown.2020-06-13T15:07:47ZRoger 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/legacy/trac/-/issues/674Functions not scrubbing IP addresses from log entries.2020-06-13T13:59:52ZTracFunctions not scrubbing IP addresses from log entries.A couple of functions aren't scrubbing IP addresses from log entries:
Apr 26 18:58:49.052 [Debug] circuit_handle_first_hop(): Looking for firsthop '194.109.206.212:443'
Apr 26 18:58:49.132 [Debug] connection_connect(): Connecting to [s...A couple of functions aren't scrubbing IP addresses from log entries:
Apr 26 18:58:49.052 [Debug] circuit_handle_first_hop(): Looking for firsthop '194.109.206.212:443'
Apr 26 18:58:49.132 [Debug] connection_connect(): Connecting to [scrubbed]:443.
[...]
Apr 26 18:58:54.345 [Debug] connection_or_finished_connecting(): OR connect() to router at 194.109.206.212:443 finished.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandudehttps://gitlab.torproject.org/legacy/trac/-/issues/675update_consensus_networkstatus_downloads() & router_pick_directory_server() r...2020-06-13T14:06:09ZTracupdate_consensus_networkstatus_downloads() & router_pick_directory_server() rarely calledPossible solution to #648
Machine was left on for several hours with TOR running but no dial up network, then dial up network was brought
back up. TOR spends half an hour in a loop where it can't find nodes. Throughout this time, using ...Possible solution to #648
Machine was left on for several hours with TOR running but no dial up network, then dial up network was brought
back up. TOR spends half an hour in a loop where it can't find nodes. Throughout this time, using TORbutton to
switch off proxies in Firefox allowed me to browse the web with no problems, so I know the network is working fine.
After waiting 30 minutes, killing and relaunching TOR seemed to fix the problem, though from the logs below it looks
like TOR had finally made some circuits just before I killed it.
Taking a closer look at the logs, I can see it wasn't able to make circuits for a whole 30 minutes until it called
update_consensus_networkstatus_downloads() and router_pick_directory_server() - then all of a sudden everything
started to work.
Are these functions rarely called because of bandwidth issues? Could some logic be added so that if we get
"[Warning] No available nodes when trying to choose node. Failing." then these functions get called?
Here are the log messages:
Apr 26 18:28:46.820 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:28:46.822 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:28:46.824 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Apr 26 18:28:46.825 [Info] choose_good_exit_server_general(): Found 74 servers that might support 11/12 pending connections.
Apr 26 18:28:46.828 [Info] choose_good_exit_server_general(): Chose exit server 'oemloi'
Apr 26 18:28:46.830 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.832 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.834 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.837 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.839 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.842 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.844 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.847 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.850 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.853 [Warning] Failed to find node for hop 0 of our path. Discarding this circuit.
Apr 26 18:28:46.856 [Info] onion_populate_cpath(): Generating cpath hop failed.
Apr 26 18:28:47.860 [Info] choose_good_exit_server_general(): Found 74 servers that might support 11/12 pending connections.
Apr 26 18:28:47.864 [Info] choose_good_exit_server_general(): Chose exit server 'gashmish'
Apr 26 18:28:47.899 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:47.903 [Warning] No available nodes when trying to choose node. Failing.
[... and so on for 30 minutes, still no nodes ...]
Apr 26 18:58:16.130 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:58:16.177 [Warning] Failed to find node for hop 0 of our path. Discarding this circuit.
Apr 26 18:58:16.219 [Info] onion_populate_cpath(): Generating cpath hop failed.
Apr 26 18:58:16.266 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
[... but suddenly ...]
Apr 26 18:58:43.588 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:43.994 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.Apr 26 18:58:44.258 [Info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 1782 present (0 of those were in old_routers); 0 would_reject; 391 wouldnt_use; 0 in progress.
Apr 26 18:58:44.329 [Info] routerlist_remove_old_routers(): We have 2211 live routers and 0 old router descriptors. At most 2173 must be retained because of networkstatuses.
Apr 26 18:58:44.398 [Info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
Apr 26 18:58:44.467 [Info] router_pick_directory_server(): No reachable router entries for dirservers. Trying them all again.
Apr 26 18:58:44.567 [Debug] directory_initiate_command(): anonymized 0, use_begindir 1.
Apr 26 18:58:44.640 [Debug] directory_initiate_command(): Initiating consensus network-status fetch
Apr 26 18:58:44.709 [Info] connection_ap_make_link(): Making internal anonymized tunnel to [scrubbed]:443 ...
Apr 26 18:58:44.778 [Debug] connection_add(): new conn type Socks, socket -1, n_conns 11.
Apr 26 18:58:44.847 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:44.916 [Info] connection_ap_make_link(): ... application connection created and linked.
Apr 26 18:58:44.985 [Debug] connection_add(): new conn type Directory, socket -1, n_conns 12.
Apr 26 18:58:45.054 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:45.124 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:45.893 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Apr 26 18:58:45.964 [Debug] new_route_len(): Chosen route length 3 (2211 routers available).
Apr 26 18:58:46.034 [Info] choose_good_exit_server_general(): Found 119 servers that might support 6/7 pending connections.
Apr 26 18:58:46.105 [Debug] smartlist_choose_by_bandwidth(): Total weighted bw = 17053612, exit bw = 23966189, nonexit bw = 1614269, exit
weight = 1.000000 (for exit == 1), guard bw = 19886442, nonguard bw = 5694016, guard weight = 0.571224 (for guard == 0)Apr 26 18:58:46.176 [Info] choose_good_exit_server_general(): Chose exit server 'dotplex1'
Apr 26 18:58:46.247 [Debug] onion_extend_cpath(): Path is 0 long; we want 3
Apr 26 18:58:46.320 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.Apr 26 18:58:46.391 [Info] add_an_entry_guard(): Chose 'dannenberg' as new entry guard.
Apr 26 18:58:46.462 [Info] log_entry_guards(): BrainwashEducation (up made-contact),GuyMontag (up made-contact) [...]
Apr 26 18:58:46.540 [Debug] onion_extend_cpath(): Chose router dannenberg for hop 1 (exit is dotplex1)
Apr 26 18:58:46.621 [Debug] onion_extend_cpath(): Path is 1 long; we want 3
Apr 26 18:58:46.698 [Debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Apr 26 18:58:46.774 [Debug] smartlist_choose_by_bandwidth(): Total weighted bw = 70934573, exit bw = 23971981, nonexit bw = 107505582, ex
it weight = 0.000000 (for exit == 0), guard bw = 114082699, nonguard bw = 17394864, guard weight = 0.615841 (for guard == 0)
Apr 26 18:58:46.851 [Debug] onion_extend_cpath(): Chose router RentalSponge for hop 2 (exit is dotplex1)
Apr 26 18:58:46.928 [Debug] onion_extend_cpath(): Path is 2 long; we want 3
Apr 26 18:58:47.006 [Debug] onion_extend_cpath(): Chose router dotplex1 for hop 3 (exit is dotplex1)
Apr 26 18:58:47.084 [Debug] onion_extend_cpath(): Path is complete: 3 steps long
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandudeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/678man page entries for RejectPlaintextPorts and WarnPlaintextPorts2020-06-13T13:59:54ZRoger 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/legacy/trac/-/issues/681encrypted dir conns confuse LeaveStreamsUnattached2020-06-13T13:59:55ZRoger 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 #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/legacy/trac/-/issues/682very slow in web browsing and cannot upload pictures to my web site2020-06-13T13:59:55ZTracvery slow in web browsing and cannot upload pictures to my web siteSince I downloaded mozilla firefox for this Tor, my web browsing is extremely slow and I cannot upload pictures to my web site that I sell on. Am I doing something wrong? I do want to stay anonymous and not have anyone knowing my ip addr...Since I downloaded mozilla firefox for this Tor, my web browsing is extremely slow and I cannot upload pictures to my web site that I sell on. Am I doing something wrong? I do want to stay anonymous and not have anyone knowing my ip address. I am tired of the spys out there. Please Help- Thank you
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: rockpapermarshttps://gitlab.torproject.org/legacy/trac/-/issues/684Recover from Config Parse Errors on HUP2020-06-13T13:59:56ZTracRecover from Config Parse Errors on HUPCurrently, if there's an error in the config, sending HUP to tor will cause it to exit. It should, instead, revert back to its previous configuration.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
*...Currently, if there's an error in the config, sending HUP to tor will cause it to exit. It should, instead, revert back to its previous configuration.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: BarkerJrhttps://gitlab.torproject.org/legacy/trac/-/issues/685Vidalia crashes every time it startet Tor 0.2.0.26rc2020-06-13T13:59:56ZTracVidalia crashes every time it startet Tor 0.2.0.26rcThe new version abort within the first minute of the starting process. I use the new vidalia bundle with the version 1.2
(the version 1.1 also chrashes when I start Tor).
[Automatically added by flyspray2trac: Operating System: Window...The new version abort within the first minute of the starting process. I use the new vidalia bundle with the version 1.2
(the version 1.1 also chrashes when I start Tor).
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Tokrahttps://gitlab.torproject.org/legacy/trac/-/issues/687Application Crash When BitTorrent Client Launched2020-06-13T13:59:56ZTracApplication Crash When BitTorrent Client LaunchedPlease Note: This is in regards to 0.2.0.26-rc.
Immediately after launching a BitTorrent Client configured to forward tracker information (ONLY!) through Tor
(file transfer connections were not forwarded through Tor; only tracker inform...Please Note: This is in regards to 0.2.0.26-rc.
Immediately after launching a BitTorrent Client configured to forward tracker information (ONLY!) through Tor
(file transfer connections were not forwarded through Tor; only tracker information), Tor crashed as follows:
szAppName: tor.exe
szModName: tor.exe
offset: 000be2c1
Tor was configured to run as a Service, and was running as a relay. The computer was Windows XP Home Edition.
I'll attempt to attach the crash dump. Note that this isn't always reproducible.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HANtwisterAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/688Change on Band inside torrc aren't published on reload2020-06-13T13:59:57ZTracChange on Band inside torrc aren't published on reloadin 0.2.0.26rc
Process
modify one of this line:
RelayBandwidthRate 1000 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB/s (1600Kbps)
MaxAdvertisedBandwidth 50 KBytes
Then d...in 0.2.0.26rc
Process
modify one of this line:
RelayBandwidthRate 1000 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB/s (1600Kbps)
MaxAdvertisedBandwidth 50 KBytes
Then do a reload of tor /etc/init.d/tor reload
Change above aren't published in the directories.
Tor restart seems to be needed for publishing changes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amisRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/689Add Bogon network to the default reject policy2020-06-13T13:59:57ZTracAdd Bogon network to the default reject policyIP from the bogon list could be found in the current directory:
1.1.1.1 1.1.1.2 39.x.x.X
Add the bogon network list in the default reject policy could be good.
If i don't think there is, an accept policy most of these IP could be added...IP from the bogon list could be found in the current directory:
1.1.1.1 1.1.1.2 39.x.x.X
Add the bogon network list in the default reject policy could be good.
If i don't think there is, an accept policy most of these IP could be added.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amis