Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:43Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/401up-to-date check on dirinfo doesn't consider networkstatus freshness2020-06-27T14:10:43ZNick Mathewsonup-to-date check on dirinfo doesn't consider networkstatus freshnessDeferred from 0.1.2.x:
? - Bug: combination of things:
When we've been idle a long time, we stop fetching server
descriptors. When we then get a socks request, we build circuits
immediately using whatever descriptors we have...Deferred from 0.1.2.x:
? - Bug: combination of things:
When we've been idle a long time, we stop fetching server
descriptors. When we then get a socks request, we build circuits
immediately using whatever descriptors we have, rather than waiting
until we've fetched correct ones.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/400Tor built with mingw cannot handle large values for MaxAdvertisedBandwidth2020-06-27T14:10:43ZedmanmTor built with mingw cannot handle large values for MaxAdvertisedBandwidthTor built with mingw on Windows cannot handle values larger than an unsigned int
for MaxAdvertisedBandwidth, which causes a problem since the default value for
MaxAdvertisedBandwidth is 128 TB.
getinfo version
250-version=0.1.2.8-beta
...Tor built with mingw on Windows cannot handle values larger than an unsigned int
for MaxAdvertisedBandwidth, which causes a problem since the default value for
MaxAdvertisedBandwidth is 128 TB.
getinfo version
250-version=0.1.2.8-beta
250 OK
getconf maxadvertisedbandwidth
250 MaxAdvertisedBandwidth=0
setconf maxadvertisedbandwidth=4294967295
250 OK
getconf maxadvertisedbandwidth
250 MaxAdvertisedBandwidth=4294967295
setconf maxadvertisedbandwidth=4294967296
250 OK
getconf maxadvertisedbandwidth
250 MaxAdvertisedBandwidth=0
A side-effect of this problem is that Win32 users of Tor 0.1.2.8-beta are unable to start a
Tor server with Vidalia, unless they manually set a value for
MaxAdvertisedBandwidth to something greater than or equal to 10000 and less
than 2!^32.
This problem has existed in previous Tor releases built with mingw (confirmed with
the Tor 0.1.2.7-alpha Win32 binary), but most likely went unnoticed until nickm added a
lower-bound on MaxAdvertisedBandwidth in r9652. The limitation does not
occur if I build my own tor.exe using Microsoft's compiler.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/399OP sometimes does not fetch hidden service descriptor2020-06-27T14:10:43ZKarsten LoesingOP sometimes does not fetch hidden service descriptorWhen the onion proxy receives a hidden service request from the client and has no up-to-date hidden service descriptor,
it should make a request to the directory. However, this is only done when Tor does not already have a connection to ...When the onion proxy receives a hidden service request from the client and has no up-to-date hidden service descriptor,
it should make a request to the directory. However, this is only done when Tor does not already have a connection to the
directory, yet. So, from time to time, Tor thinks that there is already a connection to the Dir running and aborts the
hidden service descriptor request. But---and here comes the problem---the request is simply dropped and the descriptor
is NOT requested later. Only a subsequent request from the client application leads to another consideration to fetch
the descriptor from the directory (possibly with the same result: dropped).
Should the request be added to some "request queue" and be performed during a periodic maintenance tasks?
I added my log file (with some additional log statements) that shows the affected methods.
1172409375015 Tor Client Feb 25 14:16:15.015 [info] connection_ap_handshake_process_socks(): method invoked: 67
1172409375015 Tor Client Feb 25 14:16:15.015 [info] connection_ap_handshake_process_socks(): method invoked: 67
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_ap_handshake_process_socks(): method invoked: 67
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_ap_handshake_rewrite_and_attach(): event fired: C01
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_ap_handshake_rewrite_and_attach(): method invoked: 45
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'scxfcfgpypn33tjt'
1172409375031 Tor Client Feb 25 14:16:15.031 [info] rend_cache_lookup_entry(): method invoked: 03
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor scxfcfgpypn33tjt. Fetching.
1172409375031 Tor Client Feb 25 14:16:15.031 [info] rend_client_refetch_renddesc(): event fired: C03
1172409375031 Tor Client Feb 25 14:16:15.031 [info] rend_client_refetch_renddesc(): method invoked: 35
1172409375031 Tor Client Feb 25 14:16:15.031 [info] connection_get_by_type_state_rendquery(): method invoked: 62
1172409375031 Tor Client Feb 25 14:16:15.031 [info] rend_cmp_service_ids(): Comparing two strings scxfcfgpypn33tjt and with result 1
1172409375046 Tor Client Feb 25 14:16:15.031 [info] connection_get_by_type_state_rendquery(): This method says we already have a connection running: scxfcfgpypn33tjt,
1172409375046 Tor Client Feb 25 14:16:15.031 [info] rend_client_refetch_renddesc(): Would fetch a new renddesc here (for "scxfcfgpypn33tjt"), but one is already in progress.
1172409375046 Tor Client Feb 25 14:16:15.046 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for rendezvous desc' state. Leaving it on buffer.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]https://gitlab.torproject.org/tpo/core/tor/-/issues/398Hidden Services not reachable with DirPort 802020-06-27T14:10:44ZTracHidden Services not reachable with DirPort 80My system is a Windows XP SP2 Pro with german localisation. I'm currently using Tor 1.2.7-alpha and Vidalia 0.0.11.
I'm runnning a Tor server for quite a while and was always able to connect to Hidden Services (.onion sites).
Because o...My system is a Windows XP SP2 Pro with german localisation. I'm currently using Tor 1.2.7-alpha and Vidalia 0.0.11.
I'm runnning a Tor server for quite a while and was always able to connect to Hidden Services (.onion sites).
Because of a new ADSL line, I could adjust my Bandwith to 100 Kb/s which enabled my preconfigured DirPort on Port 80.
(Remember, a Server with less than 50 KB/s is not used as a DirCache!).
After my computer acted as an DirectoryCache I wasn't able to connect to ANY .onion site at ANY time (I've tried it quite often).
Deinstalling tor and installing 1.2.6-alpha DID NOT solve the problem. Installinge Vidalia 0.0.10 DID NOT solve the problem.
I have also cross-checked Vidalia 0.0.10 with tor 1.2.7-alpha and vice versa. I have always performed a CLEAN installation.
After DISABLING the DirPort and restarting my tor, ALL (known) hidden services where instantly reachable for me.
Any idea?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: knappo0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/397bandwidthrate unreadable ?2020-06-27T14:10:44ZTracbandwidthrate unreadable ?Hello,
I'm a new Tor user and I tried to set up server mode. However, I always get these warnings (they come 1 time / min, approx.)
févr. 24 14:29:34:078 [Warning] bandwidthrate unreadable or 0. Failing.
févr. 24 14:29:34:250 [Warning...Hello,
I'm a new Tor user and I tried to set up server mode. However, I always get these warnings (they come 1 time / min, approx.)
févr. 24 14:29:34:078 [Warning] bandwidthrate unreadable or 0. Failing.
févr. 24 14:29:34:250 [Warning] router_rebuild_descriptor(): Couldn't allocate string for descriptor.
Does it means my server is KO ? I don't know if it's a problem in my configuration or a bug.
Thanks for your help
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: zambetti0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/396r9628 crashing when trying to test if 387 was fixed2020-06-27T14:10:44Zseeessr9628 crashing when trying to test if 387 was fixedtested r9628, two different crashes, probably related but one threw an assert
getting these filed in flyspray cause nickm requested it, tomorrow i'll to more testing,
see if newer revisions helped or if older ones dont crash
from log
F...tested r9628, two different crashes, probably related but one threw an assert
getting these filed in flyspray cause nickm requested it, tomorrow i'll to more testing,
see if newer revisions helped or if older ones dont crash
from log
Feb 23 21:46:34.236 [info] connection_dir_client_reached_eof(): Received directory (size 17626) from server '129.21.x.x:9030'
Feb 23 21:46:37.756 [info] connection_edge_reached_eof(): conn (fd 27) reached eof. Closing.
Feb 23 21:46:37.757 [info] connection_edge_reached_eof(): conn (fd 25) reached eof. Closing.
Feb 23 21:46:37.770 [info] connection_edge_process_relay_cell(): 28: end cell (closed normally) for stream 12893. Removing stream.
Feb 23 21:46:37.771 [info] connection_edge_process_relay_cell(): 26: end cell (closed normally) for stream 12892. Removing stream.
Feb 23 21:46:55.367 [info] consider_testing_reachability(): Testing reachability of my ORPort: 129.21.x.x:9001.
Feb 23 21:46:55.368 [info] onion_pick_cpath_exit(): Using requested exit node 'tehonionrouter'
Feb 23 21:46:55.368 [info] compute_preferred_testing_list(): Looking for middle server that doesn't have the reachability bug, and chose 'hppie'. Great.
Feb 23 21:46:55.381 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'fuckchop'
(gdb) bt
#0 0xb7f55410 in ?? ()
#1 0xbf847868 in ?? ()
legacy/trac#2 0x00000006 in ?? ()
legacy/trac#3 0x00003175 in ?? ()
legacy/trac#4 0xb7cb4651 in raise () from /lib/libc.so.6
legacy/trac#5 0xb7cb5ca9 in abort () from /lib/libc.so.6
legacy/trac#6 0xb7ce93ab in __fsetlocking () from /lib/libc.so.6
legacy/trac#7 0xb7ceeda0 in malloc_usable_size () from /lib/libc.so.6
legacy/trac#8 0xb7cf03e4 in free () from /lib/libc.so.6
legacy/trac#9 0x08085f67 in clear_cached_dir (d=0xb7da5ff4) at dirserv.c:1018
legacy/trac#10 0x08085fd7 in cached_dir_decref (d=0x82ef710) at dirserv.c:993
legacy/trac#11 0x08086038 in dirserv_clear_old_v1_info (now=1172285215) at dirserv.c:1155
legacy/trac#12 0x0809493d in second_elapsed_callback (fd=-1, event=1, args=0x0)
at main.c:887
legacy/trac#13 0xb7dae332 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#14 0xb7dae549 in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#15 0xb7dae56e in event_dispatch () from /usr/lib/libevent-1.1a.so.1
legacy/trac#16 0x08095537 in tor_main (argc=3, argv=0xbf8485a4) at main.c:1261
legacy/trac#17 0x080b8c22 in main (argc=Cannot access memory at address 0x3175
) at tor_main.c:22
===========================================================================
from log
Feb 23 21:52:34.166 [info] connection_edge_reached_eof(): conn (fd 27) reached eof. Closing.
Feb 23 21:52:34.177 [info] connection_edge_process_relay_cell(): 26: end cell (closed normally) for stream 23297. Removing stream.
Feb 23 21:52:35.617 [info] consider_testing_reachability(): Testing reachability of my ORPort: 129.21.x.x:9001.
Feb 23 21:52:35.617 [info] onion_pick_cpath_exit(): Using requested exit node 'tehonionrouter'
Feb 23 21:52:35.618 [info] compute_preferred_testing_list(): Looking for middle server that doesn't have the reachability bug, and chose 'hppie'. Great.
Feb 23 21:52:35.631 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'MrServer'
Feb 23 21:52:35.631 [info] routerstatus_list_update_from_networkstatus(): Rebuilding router status list.
Feb 23 21:52:35.634 [err] buffers.c:1441: assert_buf_ok: Assertion u32 == END_MAGIC failed; aborting.
#0 0xb7f9b410 in ?? ()
#1 0xbfe186dc in ?? ()
legacy/trac#2 0x00000006 in ?? ()
legacy/trac#3 0x00003209 in ?? ()
legacy/trac#4 0xb7cfa651 in raise () from /lib/libc.so.6
legacy/trac#5 0xb7cfbca9 in abort () from /lib/libc.so.6
legacy/trac#6 0x0804c9d1 in assert_buf_ok (buf=0x82d8d80) at buffers.c:1432
legacy/trac#7 0x080677d7 in assert_connection_ok (conn=0x81653c8, now=1172285555)
at connection.c:2403
legacy/trac#8 0x080957ef in conn_write_callback (fd=30, events=4, _conn=0x81653c8)
at main.c:453
legacy/trac#9 0xb7df4332 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#10 0xb7df4549 in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#11 0xb7df456e in event_dispatch () from /usr/lib/libevent-1.1a.so.1
legacy/trac#12 0x08095537 in tor_main (argc=3, argv=0xbfe18b64) at main.c:1261
legacy/trac#13 0x080b8c22 in main (argc=Cannot access memory at address 0x3209
) at tor_main.c:22
[Automatically added by flyspray2trac: Operating System: Other Linux]0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/395TorExample.py parameters do not work as advertised2020-06-27T14:10:44ZSteven MurdochTorExample.py parameters do not work as advertisedThe documentation for TorExample.py (in https://tor-svn.freehaven.net/svn/torctl/trunk/python) includes the help text:
"TorExample.py <parameters> <command list>" but it actually expects "TorExample.py <command>", where each command
is o...The documentation for TorExample.py (in https://tor-svn.freehaven.net/svn/torctl/trunk/python) includes the help text:
"TorExample.py <parameters> <command list>" but it actually expects "TorExample.py <command>", where each command
is of the form <command name> <global parameters> <command parameters>".
For example:
$ python TorExample.py --host=localhost:9051 listen INFO
Unrecognized command: __host=localhost:9051
...
$ python TorExample.py listen --host localhost:9051 INFO
INFO circuit_predict_and_launch_new(): Have 5 clean circs (2 internal), need another exit circ.
...
Either the code should be made consistent with the document or vice versa.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/393hidden services resolve hosts only once2020-06-27T14:10:44Zweasel (Peter Palfrader)hidden services resolve hosts only onceI have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor ...I have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor resolves the hostname only once, when it configures
the hidden service, not everytime a user establishes a new connection. This
causes problems since by the time a client request comes the information Tor
has often is long obsolete.
Please resolve it on connects, and don't cache it in a broken way (caching it
for TTL is fine).
Thanks
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedRobert RansomRobert Ransomhttps://gitlab.torproject.org/tpo/core/tor/-/issues/392bug in memset call2020-06-27T14:10:45ZTracbug in memset callcommon/compat.c:283: memset(handle, sizeof(tor_mmap_t), 0);
Last two params are reversed.
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: fookoowacommon/compat.c:283: memset(handle, sizeof(tor_mmap_t), 0);
Last two params are reversed.
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: fookoowahttps://gitlab.torproject.org/tpo/core/tor/-/issues/391RedHat 5.0beta Enterprise2020-06-27T14:10:45ZAndrew LewmanRedHat 5.0beta EnterpriseThis hack does not quite work out:
%define _build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%{target_cpu}.rpm ...This hack does not quite work out:
%define _build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%{target_cpu}.rpm
I get:
error: Could not open /usr/src/redhat/RPMS/tor-0.1.1.26-tor.0.rh5_0.i386.rpm: Permission denied
I have /usr/src/redhat/RPMS/i386/ , for example,
where user "rpmbuild" can write to.
tor.spec is the first one to define _build_name_fmt.
Others don't define it and work.
But on the other hand, I don't have many src.rpms which try to
work with more than one distro.
[Automatically added by flyspray2trac: Operating System: Other Linux]Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/390Assertion !connection_is_on_closeable_list(conn) failed2020-06-27T14:10:45ZTracAssertion !connection_is_on_closeable_list(conn) failedUsing tor version 0.1.1.26-1~~sarge.1 on Debian Sarge:
# uname -a
Linux wormhole.ynfonatic.de 2.6.9-023stab033.1-smp #1 SMP Mon Oct 23 21:47:03 MSD 2006 i686 GNU/Linux
Tor crashes with a core-dump:
# gdb /usr/sbin/tor core.16144
(gdb...Using tor version 0.1.1.26-1~~sarge.1 on Debian Sarge:
# uname -a
Linux wormhole.ynfonatic.de 2.6.9-023stab033.1-smp #1 SMP Mon Oct 23 21:47:03 MSD 2006 i686 GNU/Linux
Tor crashes with a core-dump:
# gdb /usr/sbin/tor core.16144
(gdb) bt
#0 0xb7d7683b in raise () from /lib/tls/libc.so.6
#1 0xb7d77fa2 in abort () from /lib/tls/libc.so.6
legacy/trac#2 0x0806488e in connection_free (conn=0x80b7940) at connection.c:261
legacy/trac#3 0x08082b79 in dns_cancel_pending_resolve (
address=0x8fad7d8 "ðv|\tÀna\t\020") at dns.c:535
legacy/trac#4 0x080861e2 in connection_unlink (conn=0x827ed28, remove=1) at main.c:209
legacy/trac#5 0x0808714f in conn_close_if_marked (i=0) at main.c:523
legacy/trac#6 0x08086e14 in close_closeable_connections () at main.c:388
legacy/trac#7 0xb7e85c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0xb7e85f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0xb7e85dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#10 0xb7e85cb0 in event_dispatch () from /usr/lib/libevent-1.1a.so.1
legacy/trac#11 0x080884db in do_main_loop () at main.c:1183
legacy/trac#12 0x080894a5 in tor_main (argc=0, argv=0x0) at main.c:2158
legacy/trac#13 0x080a5b9b in main (argc=0, argv=0x0) at tor_main.c:22
legacy/trac#14 0xb7d63974 in __libc_start_main () from /lib/tls/libc.so.6
legacy/trac#15 0x0804c571 in _start () at ../sysdeps/i386/elf/start.S:102
Last lines in the logfile:
# tail -n 3 log
Feb 12 23:57:40.103 [warn] spawn_enough_dnsworkers(): 100 DNS workers are spawned; all are busy. Killing one.
Feb 12 23:57:40.103 [warn] spawn_enough_dnsworkers(): 100 DNS workers are spawned; all are busy. Killing one.
Feb 12 23:57:40.105 [err] connection.c:257: connection_free: Assertion !connection_is_on_closeable_list(conn) failed; aborting.
wormhole:/var/log/tor# /usr/sbin/tor --version
Feb 13 18:58:17.225 [notice] Tor v0.1.1.26. This is experimental software. Do not rely on it for strong anonymity.
Tor version 0.1.1.26.
If you need any further evidences, drop me a line.
Cheers, Alex.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: yallahttps://gitlab.torproject.org/tpo/core/tor/-/issues/389Tor not connecting after installing Tor & Privoxy & Vidalia bundle: 0.1.2.7-a...2020-06-27T14:10:45ZTracTor not connecting after installing Tor & Privoxy & Vidalia bundle: 0.1.2.7-alphaWindows 98SE 4.10 (Build 2222 A)
IBM Aptiva - GenuineIntel Pentium(R) 200 MHz xA3 & mxA3
Tor & Privoxy & Vidalia bundle: 0.1.2.7-alpha
Using Tor as *Client only*.
After a clean install of the bundle, downloaded from:
http://tor.eff.org...Windows 98SE 4.10 (Build 2222 A)
IBM Aptiva - GenuineIntel Pentium(R) 200 MHz xA3 & mxA3
Tor & Privoxy & Vidalia bundle: 0.1.2.7-alpha
Using Tor as *Client only*.
After a clean install of the bundle, downloaded from:
http://tor.eff.org/dist/vidalia-bundles/vidalia-bundle-0.1.2.7-alpha-0.0.10.exe
and verified, Vidalia will not start Tor - correct locations of the Tor exe and torrc files verified, but Vidalia
settings "save" is corrupting location info. Privoxy operating correctly. Uninstalled Vidalia. Started Tor, which ran
for a few seconds, then closed - no info available. Edited torrc to send info to debug.log, restarted Tor.
Results below:
Feb 11 17:08:28.070 [notice] Tor 0.1.2.7-alpha opening new log file.
Feb 11 17:08:28.130 [debug] parse_dir_server_line(): Trusted dirserver at 18.244.0.188:9031 (46DB)
Feb 11 17:08:28.130 [debug] parse_dir_server_line(): Trusted dirserver at 18.244.0.114:80 (E45D)
Feb 11 17:08:28.130 [debug] parse_dir_server_line(): Trusted dirserver at 86.59.21.38:80 (1F85)
Feb 11 17:08:28.130 [debug] parse_dir_server_line(): Trusted dirserver at 140.247.60.64:80 (F5FC)
Feb 11 17:08:28.130 [debug] parse_dir_server_line(): Trusted dirserver at 194.109.206.212:80 (EAD6)
Feb 11 17:08:28.180 [info] or_state_load(): Loaded state from "C:\WINDOWS\Application Data\tor/state"
Feb 11 17:08:32.080 [warn] Could not open "C:\WINDOWS\Application Data\tor/cached-routers.new".
Feb 11 17:08:32.080 [info] update_router_have_minimum_dir_info(): We have 0 of 5 network statuses, and we want more
than 2.
Feb 11 17:08:32.080 [notice] I learned some more directory information, but not enough to build a circuit.
Feb 11 17:08:32.080 [info] update_router_descriptor_client_downloads(): Not enough networkstatus documents to launch
requests.
Feb 11 17:08:32.080 [info] update_router_descriptor_client_downloads(): Not enough networkstatus documents to launch
requests.
Feb 11 17:08:32.080 [info] update_networkstatus_client_downloads(): For 5/5 running directory servers, we have 0 live
network-status documents. Downloading 5.
Feb 11 17:08:32.080 [info] router_pick_directory_server(): No reachable router entries for dirservers. Trying them all
again.
Feb 11 17:08:32.080 [info] router_pick_directory_server(): Still no reachable router entries. Reloading and trying
again.
Feb 11 17:08:32.080 [warn] Could not open "C:\WINDOWS\Application Data\tor/cached-routers.new".
Feb 11 17:08:32.080 [info] directory_get_from_dirserver(): No router found for network status; falling back to dirserver
list
Feb 11 17:08:32.080 [debug] directory_initiate_command(): private 0, want_to_tunnel 0.
Feb 11 17:08:32.080 [debug] directory_initiate_command(): initiating network-status fetch
Feb 11 17:08:32.080 [debug] connection_connect(): Connecting to [scrubbed]:80.
Feb 11 17:08:32.250 [debug] connection_connect(): Connection to [scrubbed]:80 in progress (sock 216).
Feb 11 17:08:32.250 [debug] connection_add(): new conn type Directory, socket 216, n_conns 3.
Feb 11 17:08:32.250 [debug] write_to_buf(): added 4 bytes to buf (now 4 total).
Feb 11 17:08:32.250 [debug] write_to_buf(): added 221 bytes to buf (now 225 total).
Feb 11 17:08:32.250 [debug] write_to_buf(): added 33 bytes to buf (now 258 total).
Feb 11 17:08:32.250 [info] update_router_have_minimum_dir_info(): We have 0 of 5 network statuses, and we want more
than 2.
Feb 11 17:08:32.580 [info] or_state_save(): Saved state to "C:\WINDOWS\Application Data\tor/state"
Feb 11 17:08:32.580 [err] nt_service_loadlibrary(): Couldn't find ChangeServiceConfig2A in advapi32.dll! We probably
got the name wrong.
Feb 11 17:08:32.740 [info] or_state_save(): Saved state to "C:\WINDOWS\Application Data\tor/state"
Feb 11 17:08:32.740 [debug] _connection_free(): closing fd 44.
Feb 11 17:08:32.740 [debug] _connection_free(): closing fd 48.
Feb 11 17:08:32.740 [debug] _connection_free(): closing fd 216.
Completely uninstalled everything, re-downloaded bundle, and did clean install, this time de-selecting Vidalia & just
installing Tor and Privoxy. Same results repeated. Searched entire drive for "cached-routers.new" - unable to locate.
Checked properties for "ADVAPI32.dll" - File version 4.80.1675, Win32 ADVAPI32 core component, Copyright (C) Microsoft
Corp. 1991-1998, File size 64Kb, installed 4/23/99 with original installation of Windows 98 OS, apparently *not* revised
during the upgrade to Windows 98SE. I have NEVER had Windows NT - which Tor seems to be wanting -
"[err] nt_service_loadlibrary():"
Here is my torrc file, which the bundle installed in C:\WINDOWS\Application Data\Tor (note the "Last updated 8 October
2006 for Tor 0.1.2.3-alpha.") :
## Configuration file for a typical Tor user
## Last updated 8 October 2006 for Tor 0.1.2.3-alpha.
## (May or may not work for older or newer versions of Tor.)
##
## Lines that begin with "## " try to explain what's going on. Lines
## that begin with just "#" are disabled commands: you can enable them
## by removing the "#" symbol.
##
## See the man page, or http://tor.eff.org/tor-manual-cvs.html, for more
## options you can use in this file.
##
## On Unix, Tor will look for this file in someplace like "~/.tor/torrc" or
## "/etc/torrc"
##
## On Windows, Tor will look for the configuration file in someplace like
## "Application Data\tor\torrc" or "Application Data\<username>\tor\torrc"
##
## With the default Mac OS X installer, Tor will look in ~/.tor/torrc or
## /Library/Tor/torrc
## Replace this with "SocksPort 0" if you plan to run Tor only as a
## server, and not make any local application connections yourself.
SocksPort 9050 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
#SocksListenAddress 192.168.0.1:9100 # listen on this IP:port also
## Entry policies to allow/deny SOCKS requests based on IP address.
## First entry that matches wins. If no SocksPolicy is set, we accept
## all (and only) requests from SocksListenAddress.
#SocksPolicy accept 192.168.0.0/16
#SocksPolicy reject *
## Logs go to stdout at level "notice" unless redirected by something
## else, like one of the below lines. You can have as many Log lines as
## you want.
##
## We advise using "notice" in most cases, since anything more verbose
## may provide sensitive information to an attacker who obtains the logs.
##
## Send all messages of level 'notice' or higher to C:\Documents and Settings\Application Data\Tor\notices.log
#Log notice file C:\Documents and Settings\Application Data\Tor\notices.log
## Send every possible message to C:\Documents and Settings\Application Data\Tor\debug.log
Log debug file C:\Program Files\Tor\debug.log
## Use the system log instead of Tor's logfiles
#Log notice syslog
## To send all messages to stderr:
#Log debug stderr
## Uncomment this to start the process in the background... or use
## --runasdaemon 1 on the command line. This is ignored on Windows;
## see the FAQ entry if you want Tor to run as an NT service.
#RunAsDaemon 1
## The directory for keeping all the keys/etc. By default, we store
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
#DataDirectory @LOCALSTATEDIR@/lib/tor
## The port on which Tor will listen for local connections from Tor
## controller applications, as documented in control-spec.txt.
ControlPort 9051
############### This section is just for location-hidden services ###
## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.
#HiddenServiceDir C:\Documents and Settings\Application Data\Tor\hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServiceDir C:\Documents and Settings\Application Data\Tor\other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22
################ This section is just for servers #####################
## NOTE: If you enable these, you should consider mailing the contents
## of the "fingerprint" file to the tor-ops, so nobody else can pick
## your nickname and use a different key. See
## http://tor.eff.org/docs/tor-doc-server.html for details.
## Required: A unique handle for your server.
#Nickname ididnteditheconfig
## The IP or FQDN for your server. Leave commented out and Tor will guess.
#Address noname.example.com
## Define these to limit your bandwidth usage. Note that BandwidthRate
## must be at least 20 KB.
#BandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps)
#BandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)
## Contact info to be published in the directory, so we can contact you
## if your server is misconfigured or something else goes wrong.
#ContactInfo Random Person <nobody AT example dot com>
## You might also include your PGP or GPG fingerprint if you have one:
#ContactInfo 1234D/FFFFFFFF Random Person <nobody AT example dot com>
## Required: what port to advertise for Tor connections.
#ORPort 9001
## If you want to listen on a port other than the one advertised
## in ORPort (e.g. to advertise 443 but bind to 9090), uncomment the
## line below too. You'll need to do ipchains or other port forwarding
## yourself to make this work.
#ORListenAddress 0.0.0.0:9090
## Uncomment this to mirror the directory for others. Please do
## if you have enough bandwidth: see the bottom of
## http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#LimitBandwidth
#DirPort 9030 # what port to advertise for directory connections
## If you want to listen on a port other than the one advertised
## in DirPort (e.g. to advertise 80 but bind to 9091), uncomment the line
## below too. You'll need to do ipchains or other port forwarding yourself
## to make this work.
#DirListenAddress 0.0.0.0:9091
## Uncomment this if you run more than one Tor server, and add the
## nickname of each Tor server you control, even if they're on different
## networks. You declare it here so Tor clients can avoid using more than
## one of your servers in a single circuit.
#MyFamily nickname1,nickname2,...
## A comma-separated list of exit policies. They're considered first
## to last, and the first match wins. If you want to _replace_
## the default exit policy, end this with either a reject *:* or an
## accept *:*. Otherwise, you're _augmenting_ (prepending to) the
## default exit policy. Leave commented to just use the default, which is
## available in the man page or at http://tor.eff.org/documentation.html
##
## Look at http://tor.eff.org/faq-abuse.html#TypicalAbuses
## for issues you might encounter if you use the default exit policy.
##
## If certain IPs and ports are blocked externally, e.g. by your firewall,
## you should update your exit policy to reflect this -- otherwise Tor
## users will be told that those destinations are down.
##
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more
#ExitPolicy accept *:119 # accept nntp as well as default exit policy
#ExitPolicy reject *:* # no exits allowed
What do I need to do to correct the "Could not open "C:\WINDOWS\Application Data\tor/cached-routers.new" and "Couldn't
find ChangeServiceConfig2A in advapi32.dll! We probably got the name wrong." problems??? Also, do I need to edit my
torrc file in some other way to operate correctly?
I previously ran an old Tor/TorCP/Privoxy bundle (don't remember the version #'s), which worked fine on my system, but
uninstalled everything and deleted the old bundle file before installing this new bundle, and now cannot find the older
bundle online. Any help would be appreciated.
kc9718
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: kc9718https://gitlab.torproject.org/tpo/core/tor/-/issues/388tor crashes after 6 hours2020-06-27T14:10:45ZTractor crashes after 6 hourstor crashes with this error after about 6 hours
using redhat 3.
Feb 07 19:45:06.358 [warn] connection_watch_events(): Error from libevent setting read event state for 1023 to watched: No such file or directory
Feb 07 19:45:06.373 [wa...tor crashes with this error after about 6 hours
using redhat 3.
Feb 07 19:45:06.358 [warn] connection_watch_events(): Error from libevent setting read event state for 1023 to watched: No such file or directory
Feb 07 19:45:06.373 [warn] connection_watch_events(): Error from libevent setting read event state for 1023 to watched: No such file or directory
Feb 07 19:45:13.787 [warn] connection_unregister(): Error removing read event for 1023
Feb 07 19:45:13.787 [warn] connection_unregister(): Error removing write event for 1023
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: mcncyoAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/386Assertion circ->state == CIRCUIT_STATE_OR_WAIT failed2020-06-27T14:10:45Zweasel (Peter Palfrader)Assertion circ->state == CIRCUIT_STATE_OR_WAIT failedFeb 04 21:06:56.621 [err] circuitbuild.c:461: circuit_n_conn_done: Assertion circ->state == CIRCUIT_STATE_OR_WAIT failed; aborting.
(gdb) bt
#0 0x7026f1d0 in kill () from /lib/libc.so.6
#1 0x701b430c in pthread_kill () from /lib/libpt...Feb 04 21:06:56.621 [err] circuitbuild.c:461: circuit_n_conn_done: Assertion circ->state == CIRCUIT_STATE_OR_WAIT failed; aborting.
(gdb) bt
#0 0x7026f1d0 in kill () from /lib/libc.so.6
#1 0x701b430c in pthread_kill () from /lib/libpthread.so.0
legacy/trac#2 0x701b465c in raise () from /lib/libpthread.so.0
legacy/trac#3 0x7026eeac in raise () from /lib/libc.so.6
legacy/trac#4 0x70270354 in abort () from /lib/libc.so.6
legacy/trac#5 0x00017a14 in circuit_n_conn_done (or_conn=0x4ddbb8, status=0) at circuitbuild.c:465
legacy/trac#6 0x0001fcdc in circuit_about_to_close_connection (conn=0x4ddbb8) at circuituse.c:522
legacy/trac#7 0x00049218 in connection_unlink (conn=0x0, remove=1) at main.c:208
legacy/trac#8 0x00049fa8 in conn_close_if_marked (i=1) at main.c:523
legacy/trac#9 0x00049cb4 in close_closeable_connections () at main.c:388
legacy/trac#10 0x0004af4c in second_elapsed_callback (fd=-1, args=0xbb000) at main.c:1024
legacy/trac#11 0x70226f84 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#12 0x70227240 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#13 0x0004b380 in do_main_loop () at main.c:1183
legacy/trac#14 0x0004c348 in tor_main (argc=774536, argv=0xeffffa74) at main.c:2158
legacy/trac#15 0x70258e44 in __libc_start_main () from /lib/libc.so.6
legacy/trac#16 0x00013af4 in _start () at ../sysdeps/sparc/sparc32/elf/start.S:56
legacy/trac#17 0x00013af4 in _start () at ../sysdeps/sparc/sparc32/elf/start.S:56
Previous frame identical to this frame (corrupt stack?)
legacy/trac#5 0x00017a14 in circuit_n_conn_done (or_conn=0x4ddbb8, status=0) at circuitbuild.c:465
(gdb) p *or_conn
$1 = {magic = 2084319310, type = 4 '\004', state = 5 '\005', purpose = 0 '\0', wants_to_read = 0,
wants_to_write = 0, hold_open_until_flushed = 1, has_sent_end = 0, control_events_are_extended = 0,
is_obsolete = 1, s = 15, poll_index = 6, read_event = 0x484de0, write_event = 0x56aec8, inbuf = 0xde310,
inbuf_reached_eof = 0, timestamp_lastread = 1170623215, outbuf = 0x372890, outbuf_flushlen = 0,
timestamp_lastwritten = 1170623216, timestamp_created = 1170621095, timestamp_lastempty = 1170623216,
addr = 2551048465, port = 9001, marked_for_close = 688, marked_for_close_file = 0x8b288 "main.c",
address = 0x5ed250 "152.13.233.17", identity_pkey = 0x730058,
identity_digest = "ùg!^|æµ\205ø\f\236\216§ÖÈJ\023Æ)»b", nickname = 0x23def0 "WeAreAHedge",
chosen_exit_name = 0x0, tls = 0x7f25f8, bandwidth = 1024000, receiver_bucket = 1024000,
circ_id_type = CIRC_ID_TYPE_HIGHER, n_circuits = 0, next_with_same_id = 0x8767e0, next_circ_id = 19039,
stream_id = 0, next_stream = 0x0, cpath_layer = 0x0, package_window = 0, deliver_window = 0,
requested_resource = 0x0, socks_request = 0x0, global_identifier = 250042, event_mask = 0,
incoming_cmd_len = 0, incoming_cmd_cur_len = 0, incoming_cmd = 0x0, on_circuit = 0x0,
rend_query = '\0' <repeats 16 times>, incoming_cmd_type = 0}
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/385assert errors on answering begin_dir2020-06-27T14:10:45ZRoger Dingledineassert errors on answering begin_dirI think this was SVN r9422.
moria1 and moria2 both died with:
Jan 30 20:44:41.536 [err] connection.c:2380: assert_connection_ok: Assertion con
nection_is_writing(conn) || conn->wants_to_write failed; aborting.
#0 0x0000002a95e43545 i...I think this was SVN r9422.
moria1 and moria2 both died with:
Jan 30 20:44:41.536 [err] connection.c:2380: assert_connection_ok: Assertion con
nection_is_writing(conn) || conn->wants_to_write failed; aborting.
#0 0x0000002a95e43545 in raise () from /lib/libc.so.6
#1 0x0000002a95e44cce in abort () from /lib/libc.so.6
legacy/trac#2 0x0000000000420834 in assert_connection_ok (conn=0x1819230, now=19842)
at connection.c:2524
legacy/trac#3 0x0000000000440e7b in conn_read_callback (fd=19842, event=19842, _conn=0x6)
at main.c:424
legacy/trac#4 0x0000002a95d0e82d in event_base_priority_init ()
from /usr/lib/libevent-1.1a.so.1
legacy/trac#5 0x0000002a95d0ea72 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#6 0x0000002a95d0e8e5 in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#7 0x0000002a95d0e84b in event_dispatch () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0x000000000044259b in do_main_loop () at main.c:1234
legacy/trac#9 0x000000000044323a in tor_main (argc=19842, argv=0x4d82) at main.c:2344
legacy/trac#10 0x0000002a95e31441 in __libc_start_main () from /lib/libc.so.6
legacy/trac#11 0x000000000040622a in _start () at ../sysdeps/x86_64/elf/start.S:96
$7 = {magic = 2575892462, type = 9 '\t', state = 6 '\006', purpose = 9 '\t',
wants_to_read = 0, wants_to_write = 0, hold_open_until_flushed = 0,
inbuf_reached_eof = 0, edge_has_sent_end = 0, or_is_obsolete = 0,
chosen_exit_optional = 0, s = 1503, conn_array_index = 1977,
read_event = 0x6b1feb0, write_event = 0x3230750, inbuf = 0x6a188a0,
outbuf = 0x14e3670, outbuf_flushlen = 141, timestamp_lastread = 1170207881,
timestamp_lastwritten = 1170207879, timestamp_created = 1170207879,
addr = <smudge>, port = 0, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x6f3880 "Tor network"}
Check out the "address" field -- I think that's our hint. Somewhere we're
making it stop writing but the assert doesn't take this into account.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/384don't retry immediately if a dirserver returns 4032020-06-27T14:10:46ZRoger Dingledinedon't retry immediately if a dirserver returns 403moria1 and moria2 are going nuts requesting stuff from lefkada, which is
misconfigured to return "403 forbidden" on each request. They're making a
request every couple of seconds, and they're not letting up.
[Automatically added by flys...moria1 and moria2 are going nuts requesting stuff from lefkada, which is
misconfigured to return "403 forbidden" on each request. They're making a
request every couple of seconds, and they're not letting up.
[Automatically added by flyspray2trac: Operating System: All]post 0.1.2.xNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/383Confusing "this version is not recommended" message2020-06-27T14:10:46ZNick MathewsonConfusing "this version is not recommended" messageI got three cached networkstatuses, with client-versions lines:
client-versions 0.1.1.26,0.1.2.4-alpha,0.1.2.5-alpha,0.1.2.6-alpha
client-versions 0.1.1.26,0.1.2.6-alpha,0.1.2.7-alpha
client-versions 0.1.1.26,0.1.2.4-alpha,0.1.2.5-alpha...I got three cached networkstatuses, with client-versions lines:
client-versions 0.1.1.26,0.1.2.4-alpha,0.1.2.5-alpha,0.1.2.6-alpha
client-versions 0.1.1.26,0.1.2.6-alpha,0.1.2.7-alpha
client-versions 0.1.1.26,0.1.2.4-alpha,0.1.2.5-alpha,0.1.2.6-alpha
The following message appeared on my console:
Jan 26 23:20:38.801 [warn] Please upgrade! This version of Tor (0.1.2.6-alpha-dev)
is not recommended, according to 3/3 network statuses. Versions recommended by at
least 1 authority are: 0.1.1.26, 0.1.2.4-alpha, 0.1.2.5-alpha, 0.1.2.6-alpha
The log message is plainly wrong; should it say "more than one authority"? Also,
if the consensus among authorities is that 0.1.2.6-alpha is the most recent, shouldn't
I get the "newer than recommended" message instead of the "not recommended" message?
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/382IPs are shown in logfile2020-06-27T14:10:46ZTracIPs are shown in logfileHi,
first: This bug occurs in 0.1.2.6-alpha.
The bug:
With the log option "notice" the following messages appear in the logfile often:
--snip--
... [warn] Other side (x.x.x.x:443) has a cert without a valid nickname. Closing.
... [warn...Hi,
first: This bug occurs in 0.1.2.6-alpha.
The bug:
With the log option "notice" the following messages appear in the logfile often:
--snip--
... [warn] Other side (x.x.x.x:443) has a cert without a valid nickname. Closing.
... [warn] Identity key not as expected for router at x.x.x.x:9001: wanted ....
---snap-
where x.x.x.x is a clearly visible IP which was masked by me in this note.
Regards,
Joerg
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: MaschiNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/381Leaking cached_resolve_t2020-06-27T14:10:46ZNick MathewsonLeaking cached_resolve_t
02:45 < phobos> 1169451822: 21908908: total-size count source
02:45 < phobos> 1169451822: 21908908: 73920 231 dns.c:685
02:45 < phobos> 1169451822: 21908908: 168 2 bn_lib.c:328
02:45 < phobos> 1169451822: 2...
02:45 < phobos> 1169451822: 21908908: total-size count source
02:45 < phobos> 1169451822: 21908908: 73920 231 dns.c:685
02:45 < phobos> 1169451822: 21908908: 168 2 bn_lib.c:328
02:45 < phobos> 1169451822: 21908908: 48 2 bn_lib.c:295
02:45 < phobos> 1169451822: 21908908: 74136 235 Total of 3
02:47 < nickm> huh.
02:47 < nickm> Okay, that's easy to fix, I think.
02:47 < nickm> Is that svn, or 0.1.2.6, or other?
02:47 < phobos> 0.1.2.6-alpha
02:48 < phobos> i'm testing svn now
02:49 < phobos> or i can wait for a fix
02:49 < phobos> either way
02:49 < nickm> hmm.
02:49 < phobos> err, either way i've already destroyed my tor server
uptime and
stability
02:49 < nickm> actually, less trivial.
02:49 < nickm> I'll have to think a touch.
02:49 < nickm> That's definitely lost?
02:50 < nickm> and not, say, "reachable"?
In 0.1.2.6, this line is:
resolve = tor_malloc_zero(sizeof(cached_resolve_t));
in dns_resolve().
So apparently we have some cached_resolve_t items that are never freed.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/380remote DoS in async DNS code2020-06-27T14:10:46ZTracremote DoS in async DNS codeGreetings,
A bug exists in the label pointer handling of Tor's async DNS code that
results in denial of service. A pointer loop, resulting from a pointer
that points to itself or pointers that pointer to each other, will cause
the pars...Greetings,
A bug exists in the label pointer handling of Tor's async DNS code that
results in denial of service. A pointer loop, resulting from a pointer
that points to itself or pointers that pointer to each other, will cause
the parsing code to enter an endless loop.
This bug is present in Adam Langley's implementation and also in the
version included in libevent.
Regards,
Jon Oberheide
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jonojono